On 21 Jan 2010, at 22:45, Mick wrote:
On Tuesday 19 January 2010 01:28:07 Keith Dart wrote:
=== On Mon, 01/18, Stroller wrote: ===
I'm not ruling out the cable, because it's pretty beat up (but the
switch *is* lighting up as 1000), but how do I determine, please,
that the Linux server at the other end is recognising the NIC and
negotiating as gigabit speeds?
===
ethtool eth0
emerge ethtool if you don't have it.
Not all chips/drivers support the ioctls necessary to report that,
but
most recent ones do.
You can also run good ol' lshw. It'll show you what it has
negotiated with
the switch:
configuration: autonegotiation=on broadcast=yes driver= [snip ...]
multicast=yes port=MII speed=100MB/s
Thanks to you both.
Either of those are exactly what I was originally looking for. Both
show the interface at 1000Mb/s.
I must have overlooked Keith's reply amongst all the others - some of
those mention other ways to diagnose the problem, and I haven't
replied to them yet because I haven't had a chance to try the things
they suggest. I've been really busy this week.
What I did find time to do was try copying the same files between my
laptop & my desktop. The files were 23gig and took about 2 hours 40
minutes, I think, when I copied them from the server to my laptop.
Testing between my laptop & my desktop they went in about 25 minutes.
This was using Samba for both tests. Ironically, using the native
Apple AFP protocol was slower (about 40 minutes) but still nowhere
near as slow as the original copy from the server.
I'm pretty sure now that the bottleneck is my Linux Samba server or
the 2' of cable from it to the network switch in the server cupboard.
I'll double check this as soon as I can and then start proper
diagnostics. Some of the suggestions made (e.g. netcat) look really
useful - I'll let y'all know how I get on.
Stroller.
