Re: vr speed issues
- From: Sten Daniel Sørsdal <lists@xxxxxxxxxxxx>
- Date: Thu, 30 Nov 2006 16:06:18 +0100
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
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"
- References:
- vr speed issues
- From: Charles Sprickman
- Re: vr speed issues
- From: Philipp Ost
- vr speed issues
- Prev by Date: Re: The TCP display of systat overwrites the Load Average indicator
- Next by Date: Re: sshd. "UseDNS no" ignored?
- Previous by thread: Re: vr speed issues
- Next by thread: Re: vr speed issues
- Index(es):
Relevant Pages
|
|
