vr speed issues

Sten Daniel Sørsdal lists at wm-access.no
Thu Nov 30 07:06:58 PST 2006


Philipp Ost wrote:
> Charles Sprickman wrote:
> [snipped]
>> Performace with scp was around 200KB/s, ftp wavered between
>> 300-500KB/s.  This did not appear to be a duplex mismatch - unmanaged
>> switch showed them all at 100/Full, put some other hosts on the same
>> ports/cabling and got near wire speed.  
> 
> I just checked with the boxes I have here. One is an Athon XP on a Asus
> board with a VIA Rhine II on board; the other is a `old' Celeron 500 on
> a MSI board with a Intel ``Pro 100/S Desktop Adapter''.
> I transfered a 538MiB file (some old CURRENT snapshot) via sftp. My
> result: from box one to box two (vr to fxp) I get 2.3MB/s; from box two
> to box one (fxp to vr) I get 3.1MB/s.
> 
> The first box is running 6.2-PRERELEASE from 11/18, the Intel box is
> running 7.0-CURRENT from 11/24.
> 
> Output of
> 
> $ dmesg | grep vr
> vr0: <VIA VT6102 Rhine II 10/100BaseTX> port 0x8000-0x80ff mem
> 0xd6000000-0xd60000ff at device 18.0 on pci0
> miibus0: <MII bus> on vr0
> 
> and
> 
> $ dmesg | grep fxp
> fxp0: <Intel 82550 Pro/100 Ethernet> port 0xc000-0xc03f mem
> 0xdd020000-0xdd020fff,0xdd000000-0xdd01ffff irq 11 at device 1.0 on pci1
> miibus0: <MII bus> on fxp0
> [...]
> fxp0: Microcode loaded, int_delay: 1000 usec  bundle_max: 6
> fxp0: Microcode loaded, int_delay: 1000 usec  bundle_max: 6
> 

That sounds awfully lot like a bad cable/connector aside from duplex
mismatch. Especially the part about "larger packets has more packet
loss", which can be indicative of both.
Duplex mismatch because a larger packet has a higher probability of
getting junked by the part that believes the link is full duplex.
Cable/Connector because a larger packet has a higher probability of
getting junked by interference/lack of signal.

Obtw: SFTP requires alot more due to encryption and is less likely to
exhaust the 100mbit connection before exhausting other local resources.

Many is surprised to learn that something around 9 out of 10 network
failures is due to improper cabling.
If in doubt get a good store made cat6 cable to verify and don't buy
cheap for the cat5e's there really is a *big* difference. The cheapest
is almost always the hardest to get right on the first try.

Some cards can be suddenly reset when there are too many errors of one
sort or another and the drivers do not reprogram the cards into the
previously selected mode (if non autonegotiate settings are used).
Drivers for VIA nic's on linux tends to be notorious that way.

And NEVER set speed/duplex on any side unless you can set them on both
(autoselect will default to half duplex when other end is
non-autonegotiate)

Try setting the mode to 10mbit/half duplex (and verify on switch) to see
if the packet loss goes away. If it does then it's the cable, if it
doesn't then it's still possible but less likely to be the cable.

Please let us know what you find out.

-- 
Sten Daniel Sørsdal



More information about the freebsd-stable mailing list