This _might_ be OT... certainly I'm not entirely ready to lay this at the feet
of the kernel just yet. Any pointers to troubleshooting documents would be _greatly_
appreciated.
Box 1: P1-233 Vanilla 2.4.19. Generic PCI ne2000 card based on a RealTek 8029(?
- can confirm later)
Box 2: Athlon 2100+ Vanilla 2.4.20rc4 + Broadcom-provided driver module. Asus
A7V8X w/onboard Broadcom 10/100
Boxes are connected with 10BaseT and a NetGear 10Mbs 4-port hub. Hub is further
connected to a Samsung cable modem.
FTP from either box to a decent server via the cable modem may go as high as
250-ish k/sec. FTP transfers from box to box start out at ~ 100k/sec and very
quickly (3sec) drop to a stable 42 k/sec which persists for the rest of the
transfer, independant of which box is server or client.
Both boxes are using vsftpd behind xinetd, vsftpd manual was RTFMed and I'm
pretty sure this isn't a userspace-daemon-throttling thing (although some form
of verification that this is the case would be nice)
Diagnostics located from a link in the Ethernet-HOWTO show both cards in a 10Mbs,
half-duplex state with no reported errors.
ifconfig/proc reports show no collisions or other errors to speak of. CPU remains
near-idle on both boxes during transfers. The TX/RX lights on the hub are "leisurely"
- the transfers don't look like a constrant stream, but rather more like regular
bursts of activity.
I can find no evidence of errors or of anything wrong anywhere, aside from the
transfers being slow, and that telnet sessions from one box to the other get
choppy and laggy during large transfers. Once the transfer is completed, responsiveness
returns to normal.
Pointers to trobleshooting documents would be greatly appreciated. I have had
little luck finding anything on my own.
DG
> This _might_ be OT... certainly I'm not entirely ready to lay this
> at the feet of the kernel just yet. Any pointers to troubleshooting
> documents would be _greatly_ appreciated.
linux-net _might_ be more appropriate.
> Boxes are connected with 10BaseT and a NetGear 10Mbs 4-port hub. Hub
> is further connected to a Samsung cable modem.
> FTP from either box to a decent server via the cable modem may go as high as
> 250-ish k/sec. FTP transfers from box to box start out at ~ 100k/sec and very
> quickly (3sec) drop to a stable 42 k/sec which persists for the rest of the
> transfer, independant of which box is server or client.
Just a few thoughts:
Have you tried connecting them directly via a crossover cable?
Are they definitely connected via a hub, and not a switch?
Maybe one of the cards is jabbering, causing a lot of packet loss,
which is only noticable when transfering between local machines?
What happens when both machines make an ftp connection to a host on
the internet?
John.
> This _might_ be OT... certainly I'm not entirely ready to lay this at the feet
> of the kernel just yet. Any pointers to troubleshooting documents would be _greatly_
> appreciated.
[email protected] would be a more appropriate mailing list..
> FTP from either box to a decent server via the cable modem may go as high as
> 250-ish k/sec. FTP transfers from box to box start out at ~ 100k/sec and very
> quickly (3sec) drop to a stable 42 k/sec which persists for the rest of the
> transfer, independant of which box is server or client.
>
> Both boxes are using vsftpd behind xinetd, vsftpd manual was RTFMed and I'm
> pretty sure this isn't a userspace-daemon-throttling thing (although some form
> of verification that this is the case would be nice)
what are your sysctl settings, especially your buffer sizes? Increasing
your default tcp buffer size is the single most useful thing you can do
to improve performance if your app doesnt set buffer sizes using
setsockopt (and I dont believe it does). does it use TCP_NODELAY? are
you using ipsec?
are you sure you have path mtu turned on? is fragmentation occuring?
netstat -s would show you the snmp and tcp extended stats - that would
be the first place to look for problems..
> ifconfig/proc reports show no collisions or other errors to speak of. CPU remains
> near-idle on both boxes during transfers. The TX/RX lights on the hub are "leisurely"
> - the transfers don't look like a constrant stream, but rather more like regular
> bursts of activity.
>
> I can find no evidence of errors or of anything wrong anywhere, aside from the
> transfers being slow, and that telnet sessions from one box to the other get
> choppy and laggy during large transfers. Once the transfer is completed, responsiveness
> returns to normal.
>
> Pointers to trobleshooting documents would be greatly appreciated. I have had
> little luck finding anything on my own.
a tcpdump trace would be the next thing to look at - that should tell you
whats happening (although perhaps not why :))
thanks,
Nivedita
Dennis:
I had the EXACT same problem with slow ftp transfers between boxes on my
home lan. I also had a RealTek 8029 card. Please take this card out of the
machine, walk it over to the trash receptical and drop none too gently.
I will guarantee you that once you replace that crappy excuse for a network
card with something better (Intel EEPro100, 3Com, or Tulip based card) your
slow ftp transfer problem will completely disappear.
--
Steven A. DuChene [email protected]
[email protected]