Re: Slow start -- Linux vs. NT -- it's time to acknowledge the problem!

[Richard B. Johnson]

On Fri, 30 Nov 2001, Jessica Blank wrote:

> Hello esteemed kernel hackers:
> 
> 	As you doubtless know, NT and BSD both have a broken slow-start
> implementation. As you may not know, when you try having a Linux box
> co-exist on a network with a Windows box, this seems to cause the Windows
> box to CROWD OUT the Linux box on the network.
> 
> 	There is a fix to Solaris for this-- or a "workaround", I should
> say:
> 
> http://www.sun.com/sun-on-net/performance/tcp.slowstart.html
> 

> 	THERE IS NO FIX TO LINUX FOR THIS. At least, not as far as I could
> find-- and I just got done Web-searching for a solid 15 minutes, finding
> MULTIPLE references to the Solaris workaround in the process.

I seriouly doubt that your problem has anything to do with Linux, but
rather that the NT machines are set up to use Netbeui which puts
NETBIOS packets into broadcast packets. This means that all the data
to/from the M$ file-servers ends up being handled by your Ethernet board
and driver, then dumped onto the floor.

A properly implimented IP Network minimizes the amount of broadcast
traffic. M$ tends to maximize it. Such a typical mess looks like
this:

# tcpdump -n
10:47:03.349550 10.110.128.209.138 > 10.111.255.255.138: udp 215
10:47:03.349607 10.110.1.173.138 > 10.111.255.255.138: udp 216
10:47:03.350618 10.110.129.85.138 > 10.111.255.255.138: udp 221
10:47:03.351338 10.110.129.95.138 > 10.111.255.255.138: udp 213
10:47:03.352340 10.110.1.152.138 > 10.111.255.255.138: udp 211
10:47:03.352973 10.110.130.143.138 > 10.111.255.255.138: udp 212
10:47:03.356839 10.110.130.53.138 > 10.111.255.255.138: udp 215
10:47:03.359190 10.110.129.11.138 > 10.111.255.255.138: udp 217
10:47:03.360571 10.110.129.47.138 > 10.111.255.255.138: udp 208
10:47:03.361669 10.110.128.96.138 > 10.111.255.255.138: udp 215
10:47:03.361938 10.110.129.51.138 > 10.111.255.255.138: udp 214
10:47:03.363611 10.110.129.182.138 > 10.111.255.255.138: udp 213
^C
#

Here, data is being sent from a server 10.110.129.182, port 138
to a broadcast address, 10.111.255.255, port 138. Port 138 is
NETBIOS Datagram. So, all this data gets sent to every machine
on the LAN. It generates an interrupt, the driver gets the data
and passes it on. The IP stack looks at it and says "It ain't for
me...", and throws it away. This all takes CPU cycles that
Microsoft is stealing from you. The solution is to fire your
M$ administrator. Failing that, you need to get the fastest
Ethernet card, with a good fast driver. This allows the M$ data
to be thrown away without using too much of your CPU time.

IP filtering in your machine doesn't do any good. It just adds
CPU cycles. The broadcast packets aren't for your machine anyway
so they are being rejected without any additional filter.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.