Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 30 Nov 2001 11:00:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 30 Nov 2001 11:00:47 -0500 Received: from chaos.analogic.com ([204.178.40.224]:2944 "EHLO chaos.analogic.com") by vger.kernel.org with ESMTP id ; Fri, 30 Nov 2001 11:00:36 -0500 Date: Fri, 30 Nov 2001 11:00:24 -0500 (EST) From: "Richard B. Johnson" Reply-To: root@chaos.analogic.com To: Jessica Blank cc: linux-kernel@vger.kernel.org Subject: Re: Slow start -- Linux vs. NT -- it's time to acknowledge the problem! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/