Does it start slowly then the conversion goes fine until any new port is opened, or is the slowness during the file transfer? Slowness opening a new socket will be a DNS issue most likely broken reverse tables. Slowness once a large file transfer has started, double check duplex settings on all host ans switch interfaces.
Do stuff between the smaller boxes to tell this.
Logs viewed with dmesg and logs that appear in /var/ad/messages
I mentioned the likely DNS issue above.
Second best is learning the switches on ping and sending flurries of large packets and then seeing your dropout rates.
Third best is spray on one end and sprayd on the other.
The wax is still only available in a paste the last time I saw it. Now it comes in squeeze tubes that roll up and also in standing tubes with a piston but it's all the same paste. ;^)
The spray is like shining a flashlight into smoke. It shows the smoke real nice but doesn't actually solve your smoke problem.
We have a Sun v1280 server, with users connecting via cheap Sun boxes over the ethernet.
ftp to and from the v1280 is very slow.
In addition, some users, but not all, report very slow loading of graphics. (They connect by XDMCP (I think that's the name) to the v1280, where they have accounts, and run the CDE desktop.)
How do I go about making a differential diagnosis between:
TIA,
SThanks for your thoughtful, detailed reply.
Slowness during file transfer.
I'll have to do more of that.
Is there a utility for checking network speed? Trying ftp transfers is a reasonable "experiment" but kind of klunky.
Anyway...one transfer that was really slow was from another department (say "X"). It was slow from v1280 to my PC, and between v1280 and X. But not X and my PC.
But as far as I can tell this could still be a network thing, since it's not all a single ethernet network; looks like there are different switches in various places.
The curious thing is that all the cheap Suns with *really* bad problems (i.e., graphics taking minutes to load, not just ftp slowness) show no intervening hosts/switches/whatever when I run traceroute. Hosts that show ftp slowness but graphics relatively unaffected show intermediate switches according to traceroute.
OK.
Thanks,
S
`ttcp`. Run it in both directions.
Could you have a cabling problem? Field-made cables often have a split pair that works OK in one direction but not well in the other. Yet still give good link lights.
-- Robert
In article , sinister wrote: :The curious thing is that all the cheap Suns with *really* bad problems :(i.e., graphics taking minutes to load, not just ftp slowness) show no :intervening hosts/switches/whatever when I run traceroute. Hosts that show :ftp slowness but graphics relatively unaffected show intermediate switches :according to traceroute.
switches don't show up in traceroute -- only layer 3 hops decrement the TTL field so only layer 3 hops can return icmp ttl exceeded messages.
Your v1280 server is unlikely to have more than a couple of ports, so you almost certainly have a layer 2 switch in the middle that is not showing up.
Anyhow, your description sounds very much like duplex problems to me. I would suggest that you should launch right in to forcing the speed and duplex on the v1280 server and the switchport it is connected to: instances in which forcing speed and duplex on both ends make things -worse- are quite uncommon (but not unknown :( )
The test after that would be to force speed and duplex on one of the cheap Suns you mention (and corresponding switchport).
There is no firm agreement about autonegotiation vs forced speed and duplex. The rule of thumb that seems to be most common is that speed and duplex should be fixed for critical infrastructure (switches, routers, key servers), but that autonegotiation should be used for desktops. (Opinions vary on this, though!!) The practical idea behind this particular rule of thumb is that you can't afford to have speed and duplex issues on the key infrastructure that does not change very often, but that desktops tend to change too often to make it -convenient- to lock speed and duplex for all of them... and if something does go wrong for the desktops, it isn't going to affect very many people.
In article , Doug Freyburger wrote: :Third best is spray on one end and sprayd on the other.
Ethernet wax comes in spray cans now? I thought it was strictly a paste that had to be rubbed in.
Where'd you find mii-tool? It doesn't seem to be part of the SuSE 9.3 distro and the first several google hits don't appear to include a download site.
In comp.unix.admin Walter Roberson :
Second that.
Yep, from my experience the only OS able to handle auto-negotiation perfectly is Linux. Most distro come with mii-tool or/and eth-tool, allowing to check/set settings on the system (all good NICs) on Solaris ndd can do this for you. But mii-tool allows in addition to see what the other side of the link is advertising:
# mii-tool -v eth2 eth2: negotiated 100baseTx-FD, link ok product info: vendor 00:aa:00, model 56 rev 0 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD ^^^^^^^^^^^^ flow-control
[..]
Looks like it was a switched that needed readjusting.
(Why didn't the network guys working for us think of that, say, 6 weeks ago? Got me...)
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.