Slow transfers with from Server with SSH & FTP

Problem: Downloads from the server to a remote computer over ssh or
FTP have become extreamly slow. BITS per second instead of hundred
KILOBYTES per sec. Used to work fine, but now users are complaining
about speed and time outs...

THings I've tried:

1: Installed newest version of WinSCP on Windows client

2:Shut down Server & Rebooted.

3:Tried command line SCP through a putty session.... no difference.

4:Here is the wierd one... Sending files to the server is faster, not
fast, but faster.......

5:FTP is also the same ... VERY Slow download, slow upload.


NO slow down on the web pages, or any other noticable problems, no CPU
load while transfering ( .1% 1/10 percent )
not out of memory according to "top"....


However when we run Winscp internally over ETH1 there is no
problem.... 350 to 400K /sec transfer....

This is on a DELL 1600 with 512meg / 2ghz Xeon CPU.
ETH0 is a gigabyte onboard NIC
ETH1 is a 10/100 DLink


Any ideas where to go from here?????


Thanks

Greg
gvandergriffat<--replace at with @ec.rr.com

W.G Vandergriff wrote:

>
> This is on a DELL 1600 with 512meg / 2ghz Xeon CPU.
> ETH0 is a gigabyte onboard NIC
> ETH1 is a 10/100 DLink
>

Presume you mean gigabit onboard NIC. Somebody (I think in here) talked of a
similar problem with his RTL8169 gigabit ethernet and suspected the drivers
being the problem. Perhaps this is the same for you?

W.G Vandergriff <(E-Mail Removed)> wrote:

> Problem: Downloads from the server to a remote computer over ssh or
> FTP have become extreamly slow. BITS per second instead of hundred
> KILOBYTES per sec. Used to work fine, but now users are complaining
> about speed and time outs...
>
[...]
> NO slow down on the web pages, or any other noticable problems, no CPU
> load while transfering ( .1% 1/10 percent )
> not out of memory according to "top"....

Have you downloaded reasonable big files via HTTP (not just
a few KB)?


> However when we run Winscp internally over ETH1 there is no
> problem.... 350 to 400K /sec transfer....
>
> This is on a DELL 1600 with 512meg / 2ghz Xeon CPU.
> ETH0 is a gigabyte onboard NIC
> ETH1 is a 10/100 DLink

Are the users which are complaining also using eth1
to access the server?


> Any ideas where to go from here?????

Have you checked the error counters given in the output of
ifconfig?

Check also whether the ethernet interface with which you
have problems is operating in the right mode (half duplex,
full duplex, etc). Check cabling.

Use tcpdump on the server and windump on the Windows clients
to capture traffic. Check in the traces whether there is packet
loss or something fishy.

Ciao, Horst
--
»When pings go wrong (It hurts me too)« E.Clapton/E.James/P.Tscharn

Yep you were right It is a gigabit NIC, I'll try looking for some
posts on this and see what I can find. The Onboard NIC is a Intel
10/100/1000 onboard.

"Carl Farrington" <(E-Mail Removed)> wrote in message news:<br075c$iuc$1$(E-Mail Removed)>...
> W.G Vandergriff wrote:
>
> >
> > This is on a DELL 1600 with 512meg / 2ghz Xeon CPU.
> > ETH0 is a gigabyte onboard NIC
> > ETH1 is a 10/100 DLink
> >
>
> Presume you mean gigabit onboard NIC. Somebody (I think in here) talked of a
> similar problem with his RTL8169 gigabit ethernet and suspected the drivers
> being the problem. Perhaps this is the same for you?

Thanks for the response , I'll answear each question as they are
posted.

Horst Knobloch <(E-Mail Removed)> wrote in message news:<br0e3s$24to$(E-Mail Removed)>...
> W.G Vandergriff <(E-Mail Removed)> wrote:
>
> > Problem: Downloads from the server to a remote computer over ssh or
> > FTP have become extreamly slow. BITS per second instead of hundred
> > KILOBYTES per sec. Used to work fine, but now users are complaining
> > about speed and time outs...
> >
> [...]
> > NO slow down on the web pages, or any other noticable problems, no CPU
> > load while transfering ( .1% 1/10 percent )
> > not out of memory according to "top"....
>
> Have you downloaded reasonable big files via HTTP (not just
> a few KB)?


I had them download a 5.4 Meg file off of a friends Web Site. It took
43 seconds to do the transfer. This seems reasonable.



>
>
> > However when we run Winscp internally over ETH1 there is no
> > problem.... 350 to 400K /sec transfer....
> >
> > This is on a DELL 1600 with 512meg / 2ghz Xeon CPU.
> > ETH0 is a gigabyte onboard NIC
> > ETH1 is a 10/100 DLink
>
> Are the users which are complaining also using eth1
> to access the server?


No the users are outside the local network.
ETH0 is connected to a cable modem,
ETH1 is connected to a local 4 port switch.

They are using WINSCP to transfer small files ( word documents of
less than 100K in size) off the server. We tried FTP to see if it
would be anty faster. ( It wasn't)

They reported today of recieving a error message
"server not responding in 15 sec; retry or cancel ?"



>
> > Any ideas where to go from here?????
>
> Have you checked the error counters given in the output of
> ifconfig?

eth0 Link encap:Ethernet HWaddr 00:C0:9F:29:0E:CA
inet addr:24.74.xxx.xxx Bcast:255.255.255.255
Mask:255.255.240.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:18098058 errors:0 dropped:0 overruns:0 frame:0
TX packets:71127 errors:0 dropped:0 overruns:0 carrier:0
collisions:600 txqueuelen:100
RX bytes:1201417141 (1145.7 Mb) TX bytes:13440293 (12.8 Mb)
Interrupt:11 Base address:0xecc0 Memory:fe100000-fe120000

No errors but I do see the 600 collisions. Is this too high for the
amount
of data thats went over the card ?

>
> Check also whether the ethernet interface with which you
> have problems is operating in the right mode (half duplex,
> full duplex, etc). Check cabling.

Cables tested fine on the cable tester. Will make up some new ones
just in
case. (can't hurt) Kinda of new to LINUX, how do you check what mode
the card
is operating in?


>
> Use tcpdump on the server and windump on the Windows clients
> to capture traffic. Check in the traces whether there is packet
> loss or something fishy.

Will do, I can him run tcpdump at the server, I'll log in here with
WINSCP
and run windump.

Thanks for your help!

Greg

>
> Ciao, Horst

W.G Vandergriff <(E-Mail Removed)> wrote:

> Thanks for the response , I'll answear each question as they are
> posted.
>
> Horst Knobloch <(E-Mail Removed)> wrote in message
> news:<br0e3s$24to$(E-Mail Removed)>...
>> W.G Vandergriff <(E-Mail Removed)> wrote:
>>
[...]
>> > This is on a DELL 1600 with 512meg / 2ghz Xeon CPU.
>> > ETH0 is a gigabyte onboard NIC
>> > ETH1 is a 10/100 DLink

You say above "gigabyte onboard NIC". Do you mean
a gigabit NIC onboard or a NIC onboard a Gigabyte
motherboard? Just being curious.


>> Are the users which are complaining also using eth1
>> to access the server?
>
>
> No the users are outside the local network.
> ETH0 is connected to a cable modem,
> ETH1 is connected to a local 4 port switch.

If you have another spare NIC, you could try to use
it for hooking-up the cable modem instead of the
onboard NIC (at least for checking).


> They are using WINSCP to transfer small files ( word documents of
> less than 100K in size) off the server. We tried FTP to see if it
> would be anty faster. ( It wasn't)
>
> They reported today of recieving a error message
> "server not responding in 15 sec; retry or cancel ?"

This indicates severe network problems. However you
know this already. ;-)


>> > Any ideas where to go from here?????
>>
>> Have you checked the error counters given in the output of
>> ifconfig?
>
> eth0 Link encap:Ethernet HWaddr 00:C0:9F:29:0E:CA
> inet addr:24.74.xxx.xxx Bcast:255.255.255.255
> Mask:255.255.240.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:18098058 errors:0 dropped:0 overruns:0 frame:0
> TX packets:71127 errors:0 dropped:0 overruns:0 carrier:0
> collisions:600 txqueuelen:100
> RX bytes:1201417141 (1145.7 Mb) TX bytes:13440293 (12.8 Mb)
> Interrupt:11 Base address:0xecc0 Memory:fe100000-fe120000
>
> No errors but I do see the 600 collisions. Is this too high for the
> amount of data thats went over the card ?

No, I think it's still ok. A little bit strange is the
*huge* difference between number of RX and TX packets.
You got 250 times more packets than you send. This is
unusual from my point of view.

However you are hooked-up via cable modem so you might
get lots of (broadcast) traffic for other boxes on the
same segment.


>> Check also whether the ethernet interface with which you
>> have problems is operating in the right mode (half duplex,
>> full duplex, etc). Check cabling.
>
> Cables tested fine on the cable tester. Will make up some new ones
> just in
> case. (can't hurt) Kinda of new to LINUX, how do you check what mode
> the card is operating in?

Use the mii-tool for this.


>> Use tcpdump on the server and windump on the Windows clients
>> to capture traffic. Check in the traces whether there is packet
>> loss or something fishy.
>
> Will do, I can him run tcpdump at the server, I'll log in here with
> WINSCP and run windump.

It would be helpful if you synchronize the clocks of both
computers. On Linux you could use ntpdate. For Windows boxes
there should be something similar.


> Thanks for your help!

You are welcome but nothing was really helpful yet. ;-)


Ciao, Horst
--
»When pings go wrong (It hurts me too)« E.Clapton/E.James/P.Tscharn

Horst Knobloch <(E-Mail Removed)> wrote in message news:<br5f34$> >> > This is on a DELL 1600 with 512meg / 2ghz Xeon CPU.
> >> > ETH0 is a gigabyte onboard NIC
> >> > ETH1 is a 10/100 DLink
>
> You say above "gigabyte onboard NIC". Do you mean
> a gigabit NIC onboard or a NIC onboard a Gigabyte
> motherboard? Just being curious.

It is a gigabit NIC on the standard Dell Server board.


> If you have another spare NIC, you could try to use
> it for hooking-up the cable modem instead of the
> onboard NIC (at least for checking).

Put a 3COM NIC in and still got the same results.

Removed 3COM NIC hooked laptop up to server with onboard NIC
& crossover cable, Everything works fine. This tells me it has to
be the cable service provider.



> > They reported today of recieving a error message
> > "server not responding in 15 sec; retry or cancel ?"
>
> This indicates severe network problems. However you
> know this already. ;-)

Yes


> >
> > eth0 Link encap:Ethernet HWaddr 00:C0:9F:29:0E:CA
> > inet addr:24.74.xxx.xxx Bcast:255.255.255.255

> No, I think it's still ok. A little bit strange is the
> *huge* difference between number of RX and TX packets.
> You got 250 times more packets than you send. This is
> unusual from my point of view.
>
> However you are hooked-up via cable modem so you might
> get lots of (broadcast) traffic for other boxes on the
> same segment.


This is true, the cable modems activity light blinks 24/7



>
> Use the mii-tool for this.

Will add this to the 2 do list, but Like I said above, it appears to be the
cable company.

>
> It would be helpful if you synchronize the clocks of both
> computers. On Linux you could use ntpdate. For Windows boxes
> there should be something similar.

OK will do.

>
>
> > Thanks for your help!
>
> You are welcome but nothing was really helpful yet. ;-)
>

Any help is appreciated! And as a teacher told me once:
"As long as you learn one thing a day; You can consider your day a success!"

And this is definitely a learning experience!!!

Going to call cable company in the morning.... wish me luck.


Greg