Networking performance problem

Networking performance problem

Post by Jacco van Scha » Thu, 26 Oct 2000 04:00:00



Hi all,

I have a networking problem that's been bothering me for some time. I
have a Windows machine with a 100 Mbps Intel EtherPro card connected via
UTP to a Linux box with a 3com 3c905B. The problem is that traffic from
the Windows box to the Linux box goes as fast as 3 to 5 MBytes per
second but the other way around, from Linux to Windows, goes at a measly
7 kBytes per second.

The strange thing is, this is not a recent problem. It was the same when
I had two 10Base2 NE2000 clone cards, and since then I've tried
everything I can think of:

- Replacing the NE2000s by 100 Mbps UTP NICs
- Swapping the NICs
- Changing and reversing cables
- Using different drivers (3c509, 3c59x, 3c90x)
- Setting the card to half-duplex as some people suggested (it went from
  7kBps to a whopping 12 kBps, so yes, that did help some)
- I've even replaced the motherboard in the Linux box

But all to no avail. Some things I've already made sure of:

- The two boxes are connected using a cat. 5 crossover cable that seems
  to have all pins connected.
- The NIC is on its own interrupt.

And now I just don't know what to try anymore.

Can anyone help me?

Groeten,                                        - Jacco

--
Think about it:                 | IRL: Jacco van Schaik
                                |
If the wheel had never been     | Mail me:   jacco at nlr dot nl

driving on logs...              |
                                | See also http://www.nlr.nl/NARSIM.html

 
 
 

Networking performance problem

Post by Andrey Vlaso » Sat, 28 Oct 2000 08:47:49


Hi there,

do you use samba? If so somewhere in its documentation exists description
of the problem and it's solution. As I do not use Samba I can not help more
;-(

Andrey


> Hi all,

> I have a networking problem that's been bothering me for some time. I
> have a Windows machine with a 100 Mbps Intel EtherPro card connected via
> UTP to a Linux box with a 3com 3c905B. The problem is that traffic from
> the Windows box to the Linux box goes as fast as 3 to 5 MBytes per
> second but the other way around, from Linux to Windows, goes at a measly
> 7 kBytes per second.

> The strange thing is, this is not a recent problem. It was the same when
> I had two 10Base2 NE2000 clone cards, and since then I've tried
> everything I can think of:

> - Replacing the NE2000s by 100 Mbps UTP NICs
> - Swapping the NICs
> - Changing and reversing cables
> - Using different drivers (3c509, 3c59x, 3c90x)
> - Setting the card to half-duplex as some people suggested (it went from
>   7kBps to a whopping 12 kBps, so yes, that did help some)
> - I've even replaced the motherboard in the Linux box

> But all to no avail. Some things I've already made sure of:

> - The two boxes are connected using a cat. 5 crossover cable that seems
>   to have all pins connected.
> - The NIC is on its own interrupt.

> And now I just don't know what to try anymore.

> Can anyone help me?

> Groeten,                                        - Jacco

> --
> Think about it:                 | IRL: Jacco van Schaik
>                                 |
> If the wheel had never been     | Mail me:   jacco at nlr dot nl

> driving on logs...              |
>                                 | See also http://www.nlr.nl/NARSIM.html


 
 
 

Networking performance problem

Post by karl_he.. » Sat, 28 Oct 2000 11:14:24



> Hi all,

> I have a networking problem that's been bothering me for some time. I have a
> Windows machine with a 100 Mbps Intel EtherPro card connected via UTP to a
> Linux box with a 3com 3c905B. The problem is that traffic from the Windows
> box to the Linux box goes as fast as 3 to 5 MBytes per second but the other
> way around, from Linux to Windows, goes at a measly
> 7 kBytes per second.

clarify what you mean by traffic.  windows networking, FTP etc.  If it windows
shares etc then your runninf samba on linux, correct. and the transfers from
winX to linux are fine, so samba is ok.

Transferring the other way is slow,  how are you transferring the data?

karl.

 
 
 

Networking performance problem

Post by Jacco van Schai » Sun, 29 Oct 2000 07:21:05




>> Hi all,

>> I have a networking problem that's been bothering me for some time. I have a
>> Windows machine with a 100 Mbps Intel EtherPro card connected via UTP to a
>> Linux box with a 3com 3c905B. The problem is that traffic from the Windows
>> box to the Linux box goes as fast as 3 to 5 MBytes per second but the other
>> way around, from Linux to Windows, goes at a measly
>> 7 kBytes per second.

> clarify what you mean by traffic.  windows networking, FTP etc.  If it windows
> shares etc then your runninf samba on linux, correct. and the transfers from
> winX to linux are fine, so samba is ok.
> Transferring the other way is slow,  how are you transferring the data?

FTP, always FTP. I start FTP from the windows machine to the Linux
machine. A "put" transfers at 3 to 5 MB/sec, a "get" transfers at 7 kB/sec.  

Groeten,                                        - Jacco

--
Think about it:                 | IRL: Jacco van Schaik
                                |
If the wheel had never been     | Mail me:   jacco at nlr dot nl

driving on logs...              |
                                | See also http://www.nlr.nl/NARSIM.html

 
 
 

Networking performance problem

Post by karl_he.. » Sun, 29 Oct 2000 09:23:19



.....

Quote:>> Transferring the other way is slow,  how are you transferring the data?

> FTP, always FTP. I start FTP from the windows machine to the Linux machine. A
> "put" transfers at 3 to 5 MB/sec, a "get" transfers at 7 kB/sec.  

ok. doing a local ftp copy (linux<->linux) would test the ftp daemon speed.
After that you could look at a tcpdump and check the traffic being generated.
I know the ftp client on windows is crude but that should not be a problem.

If you have apache running you could try transferring via http to check as
well.

karl.

 
 
 

Networking performance problem

Post by Les Mikesel » Sun, 29 Oct 2000 14:20:47






> >> Hi all,

> >> I have a networking problem that's been bothering me for some time. I
have a
> >> Windows machine with a 100 Mbps Intel EtherPro card connected via UTP
to a
> >> Linux box with a 3com 3c905B. The problem is that traffic from the
Windows
> >> box to the Linux box goes as fast as 3 to 5 MBytes per second but the
other
> >> way around, from Linux to Windows, goes at a measly
> >> 7 kBytes per second.

> > clarify what you mean by traffic.  windows networking, FTP etc.  If it
windows
> > shares etc then your runninf samba on linux, correct. and the transfers
from
> > winX to linux are fine, so samba is ok.

> > Transferring the other way is slow,  how are you transferring the data?

> FTP, always FTP. I start FTP from the windows machine to the Linux
> machine. A "put" transfers at 3 to 5 MB/sec, a "get" transfers at 7

kB/sec.

The most likely problem is a full/half duplex mismatch on some network
connection between the boxes.  If you have switches with management,
check for errors on the ports involved.

  Les Mikesell

 
 
 

Networking performance problem

Post by Jacco van Schai » Sun, 29 Oct 2000 17:08:44





> .....
>>> Transferring the other way is slow,  how are you transferring the data?

>> FTP, always FTP. I start FTP from the windows machine to the Linux machine. A
>> "put" transfers at 3 to 5 MB/sec, a "get" transfers at 7 kB/sec.  

> ok. doing a local ftp copy (linux<->linux) would test the ftp daemon speed.
> After that you could look at a tcpdump and check the traffic being generated.
> I know the ftp client on windows is crude but that should not be a problem.
> If you have apache running you could try transferring via http to check as
> well.

Okay, some new info. I did exactly what you were suggesting with a
buddy's laptop, and to my surprise that went very well. His laptop had a
10 Mbps NIC, bu even then we had a transferspeed (FTP, from my Linux box
to his windows laptop) of around 300 kbps for a 70k file.

After some more testing it appeared that there's something wrong with
the way that my windows box handles TCP traffic (which makes it OT for
this newsgroup, but I'll press on regardless :-) because when we flooded
it with pings it handled them easily, giving a (calculated) bandwidth of
around 8 Mbps.

So it's not the bandwidth per se that's the problem, it's the way that
the windows box handles FTP (or TCP).

Does anybody have any more info about this?

Groeten,                                        - Jacco

--
Think about it:                 | IRL: Jacco van Schaik
                                |
If the wheel had never been     | Mail me:   jacco at nlr dot nl

driving on logs...              |
                                | See also http://www.nlr.nl/NARSIM.html

 
 
 

Networking performance problem

Post by Les Mikesel » Mon, 30 Oct 2000 09:03:38






Schaik"

> > .....
> >>> Transferring the other way is slow,  how are you transferring the
data?

> >> FTP, always FTP. I start FTP from the windows machine to the Linux
machine. A
> >> "put" transfers at 3 to 5 MB/sec, a "get" transfers at 7 kB/sec.

> > ok. doing a local ftp copy (linux<->linux) would test the ftp daemon
speed.
> > After that you could look at a tcpdump and check the traffic being
generated.
> > I know the ftp client on windows is crude but that should not be a
problem.

> > If you have apache running you could try transferring via http to check
as
> > well.

> Okay, some new info. I did exactly what you were suggesting with a
> buddy's laptop, and to my surprise that went very well. His laptop had a
> 10 Mbps NIC, bu even then we had a transferspeed (FTP, from my Linux box
> to his windows laptop) of around 300 kbps for a 70k file.

> After some more testing it appeared that there's something wrong with
> the way that my windows box handles TCP traffic (which makes it OT for
> this newsgroup, but I'll press on regardless :-) because when we flooded
> it with pings it handled them easily, giving a (calculated) bandwidth of
> around 8 Mbps.

> So it's not the bandwidth per se that's the problem, it's the way that
> the windows box handles FTP (or TCP).

There are no windows problems so bad that you get 7kb/s throughput
on a 100 Mb link.  You have a physical problem somewhere.

   Les Mikesell

 
 
 

Networking performance problem

Post by karl_he.. » Mon, 30 Oct 2000 10:22:32



....

Quote:

> So it's not the bandwidth per se that's the problem, it's the way that the
> windows box handles FTP (or TCP).

As someone else posted, check the duplex setting of the cards. A friend of
mine came across a mixed-duplex setup which was causing horrid performance.

karl.

 
 
 

Networking performance problem

Post by Jacco van Schai » Tue, 31 Oct 2000 01:56:09





> ....

>> So it's not the bandwidth per se that's the problem, it's the way that the
>> windows box handles FTP (or TCP).

> As someone else posted, check the duplex setting of the cards. A friend of
> mine came across a mixed-duplex setup which was causing horrid performance.

I don't think that's it. I can set either full or half-duplex on both
boxes and it doesn't make any difference.

Since my first post I've reversed the cable, swapped the cards and today
I've even replaced the MSI motherboard in the Windows box with an Asus I
had lying around. No change. As Les Mikesell said in another reply,
there's probably a physical problem somewhere, but I sure as hell can't
find it.

Groeten,                                        - Jacco

--
Think about it:                 | IRL: Jacco van Schaik
                                |
If the wheel had never been     | Mail me:   jacco at nlr dot nl

driving on logs...              |
                                | See also http://www.nlr.nl/NARSIM.html

 
 
 

Networking performance problem

Post by Joe Schaefe » Tue, 31 Oct 2000 02:24:15




> Okay, some new info. I did exactly what you were suggesting with a
> buddy's laptop, and to my surprise that went very well. His laptop had a
> 10 Mbps NIC, bu even then we had a transferspeed (FTP, from my Linux box
> to his windows laptop) of around 300 kbps for a 70k file.

> After some more testing it appeared that there's something wrong with
> the way that my windows box handles TCP traffic (which makes it OT for
> this newsgroup, but I'll press on regardless :-) because when we flooded
> it with pings it handled them easily, giving a (calculated) bandwidth of
> around 8 Mbps.

> So it's not the bandwidth per se that's the problem, it's the way that
> the windows box handles FTP (or TCP).

> Does anybody have any more info about this?

It sounds as if you may have entered that warm and fuzzy place known as
dll hell.  Many Windows software/driver vendors feel their own code is
better than MS's, so they dutifully overwrite your dll's in
C:\windows\system .

You may have recently installed software from such a considerate vendor,
and are now paying the price.  Check the info on your winsock.dll and
wsock32.dll; you probably should upgrade it to the latest version from
MS.

HTH.
--
Joe Schaefer

 
 
 

Networking performance problem

Post by Jacco van Schai » Tue, 31 Oct 2000 07:52:01



Quote:

> There are no windows problems so bad that you get 7kb/s throughput
> on a 100 Mb link.  You have a physical problem somewhere.

That's what I would think as well. But I've just now looked at a tcpdump
of a Samba-transfer from the Linux- to the Windows-box. Samba uses TCP
here. The Linux machine is called yosemite, the Windows box is manhattan:

23:33:03.780076 yosemite.netbios-ssn > manhattan.1050: tcp 1460 (DF)
23:33:03.979961 manhattan.1050 > yosemite.netbios-ssn: tcp 0 (DF)
23:33:03.980044 yosemite.netbios-ssn > manhattan.1050: tcp 1460 (DF)
23:33:04.179931 manhattan.1050 > yosemite.netbios-ssn: tcp 0 (DF)
23:33:04.180029 yosemite.netbios-ssn > manhattan.1050: tcp 1460 (DF)
23:33:04.379897 manhattan.1050 > yosemite.netbios-ssn: tcp 0 (DF)
23:33:04.379983 yosemite.netbios-ssn > manhattan.1050: tcp 1460 (DF)
23:33:04.579885 manhattan.1050 > yosemite.netbios-ssn: tcp 0 (DF)
23:33:04.579971 yosemite.netbios-ssn > manhattan.1050: tcp 1460 (DF)
23:33:04.779836 manhattan.1050 > yosemite.netbios-ssn: tcp 0 (DF)
23:33:04.779924 yosemite.netbios-ssn > manhattan.1050: tcp 1460 (DF)
23:33:04.979808 manhattan.1050 > yosemite.netbios-ssn: tcp 0 (DF)

So it seems that the Windows box takes *exactly* 0.2 seconds to reply.
To me, that's too much of a coincidence for *just* a physical problem.

Groeten,                                        - Jacco

--
Think about it:                 | IRL: Jacco van Schaik
                                |
If the wheel had never been     | Mail me:   jacco at frontier dot nl

driving on logs...              |

 
 
 

Networking performance problem

Post by karl_he.. » Tue, 31 Oct 2000 08:41:50




> 23:33:03.780076 yosemite.netbios-ssn > manhattan.1050: tcp 1460 (DF)
> 23:33:03.979961 manhattan.1050 > yosemite.netbios-ssn: tcp 0 (DF)
> 23:33:03.980044 yosemite.netbios-ssn > manhattan.1050: tcp 1460 (DF)
> 23:33:04.179931 manhattan.1050 > yosemite.netbios-ssn: tcp 0 (DF)
> 23:33:04.180029 yosemite.netbios-ssn > manhattan.1050: tcp 1460 (DF)
> 23:33:04.379897 manhattan.1050 > yosemite.netbios-ssn: tcp 0 (DF)
> 23:33:04.379983 yosemite.netbios-ssn > manhattan.1050: tcp 1460 (DF)
> 23:33:04.579885 manhattan.1050 > yosemite.netbios-ssn: tcp 0 (DF)
> 23:33:04.579971 yosemite.netbios-ssn > manhattan.1050: tcp 1460 (DF)
> 23:33:04.779836 manhattan.1050 > yosemite.netbios-ssn: tcp 0 (DF)
> 23:33:04.779924 yosemite.netbios-ssn > manhattan.1050: tcp 1460 (DF)
> 23:33:04.979808 manhattan.1050 > yosemite.netbios-ssn: tcp 0 (DF)

> So it seems that the Windows box takes *exactly* 0.2 seconds to reply. To me,
> that's too much of a coincidence for *just* a physical problem.

Are you running anything on the windows box, it doesn't multitask well. 0.2
second difference seems pretty bad.   Do you get the same with pings.

karl.

 
 
 

Networking performance problem

Post by Les Mikesel » Tue, 31 Oct 2000 16:05:20





> > There are no windows problems so bad that you get 7kb/s throughput
> > on a 100 Mb link.  You have a physical problem somewhere.

> That's what I would think as well. But I've just now looked at a tcpdump
> of a Samba-transfer from the Linux- to the Windows-box. Samba uses TCP
> here. The Linux machine is called yosemite, the Windows box is manhattan:

> 23:33:04.579971 yosemite.netbios-ssn > manhattan.1050: tcp 1460 (DF)
> 23:33:04.779836 manhattan.1050 > yosemite.netbios-ssn: tcp 0 (DF)
> 23:33:04.779924 yosemite.netbios-ssn > manhattan.1050: tcp 1460 (DF)
> 23:33:04.979808 manhattan.1050 > yosemite.netbios-ssn: tcp 0 (DF)

> So it seems that the Windows box takes *exactly* 0.2 seconds to reply.
> To me, that's too much of a coincidence for *just* a physical problem.

That number sounds familiar, but in my old age I can't remember which
thing causes it.   But back to the physical link: what is between the
two boxes, and if there is a switch can you check the port stats?

  Les Mikesell

 
 
 

Networking performance problem

Post by ja.. » Tue, 31 Oct 2000 21:17:38




>> So it seems that the Windows box takes *exactly* 0.2 seconds to reply.
>> To me, that's too much of a coincidence for *just* a physical problem.

> That number sounds familiar, but in my old age I can't remember which
> thing causes it.

As far as I can tell it's because the Windows box polls its input buffer
(or whatever) 5 times a second. It then replys to the Linux box, which
replys (almost) instantly and then has to wait for 0.2 seconds before the
Windows box replys again. That's why the delay is actually slightly less
than 0.2 seconds.

Quote:> But back to the physical link: what is between the
> two boxes, and if there is a switch can you check the port stats?

No switch, just a crossover cable directly between the two boxes.

Some additional info: this morning I put a bootable Slackware CD in the
Windows box, booted Linux, modprobe'd 3c59x, ifconfig'ed eth0 and again
tried an FTP from the Linux box. The result: 2400 kBytes/second.

So I'm pretty sure there isn't a physical problem anywhere (at least
none that would prevent Linux-to-Linux FTP from working).

And the really weird thing is that it only affects TCP traffic. Look at
this (we're back to Linux-to-Windows here):

root:root:yosemite:/root # time ping -f -s 1000 -c 100000 manhattan
PING manhattan (192.168.1.1): 1000 data bytes
--- manhattan ping statistics ---
100004 packets transmitted, 100000 packets received, 0% packet loss
round-trip min/avg/max = 0.3/0.8/43.0 ms
ping -f -s 1000 -c 100000 manhattan  1.55s user 8.39s system 39% cpu 24.891 total

So that's 1000*100000 bytes in 24.891 seconds = 4 MByte/second, and
that's not even counting the return traffic!

I'm, like, SO confused.

Groeten,                                        - Jacco

--
Think about it:                 | IRL: Jacco van Schaik
                                |
If the wheel had never been     | Mail me:   jacco at frontier dot nl

driving on logs...              |

 
 
 

1. network performance problem

Hello all,

I was running a ipmasquerade network, with two machines I will call them
insideA, and insideB from inside accessing one internet connection on
machine I will call gatewayC.  For some reason everything is sooo slow
lately.  I mean from the two machines insideA/insideB accessing gatewayC
as well as machine gatewayC accessing the Internet.  Trying to access the
web from insideA/insideB via gatewayC is just extremely slow.  I tried
disabling most services on gatewayC and still things has not speed up.
I just moved to ipchains in hope of solving this problem, it didn't work.

The only other thing I am concerned of is that the machine has been
hacked into before while I left it on for a few days.  ie last log showed
someone ftp'ed into it from an unknown location.  Also log showed that
they tried to access start imapd2 repeatedly. They also attempted SYN packet
attacked at around the same time.  Hopefully he didn't leave any running
funny program that bog down the system.  :-)

I also suspect the hub that I am using maybe defective but have no extra
hub to test out this theory.

Are there any tools out there that will show me where the bottle neck might
be?  like whether it is the hub? or the linux box itself?

I appreciate any help in resolving this mess.  Please email if possible.

INFOS:  I am now running kernel 2.2.9, basic linux installation, with
        apache server. CPU: AMD 200, 16MB RAM  (before you say RAM!, I
        have to say it worked just fine before with a swap space).

2. Linux Software

3. Network performance Problem

4. How do you change the cursor color in a color_xterm?

5. RS6000 network performance problem

6. RedHat: how do we get the RPM extractor out of the RPM file?

7. Network Performance Problems?

8. NT's C2 and decent file transfer: A FARCE.

9. Network performance problems under Linux, but not Windows

10. network performance problems...

11. 3COM network performance problems with Redhat 5.0

12. One Way Network Performance Problem

13. PPP Networking Performance Problems