On Fri, 30 Nov 2001, Holzrichter, Bruce wrote:
> Well that may help with your situation, but having the Windows-type person
> remove Windows may help more... ;o)
God how I wish.
>
> Seriously though, I would look at what Alan suggested, as if you are really
> flooding your network, you'd see problems on the other machines as well. I
> would think, a duplex/network issue over what your seeing. Does your Net
> admin see any errors on your switch if your using one?
>
There were some errors-- but they were on the upstream side, not the
downstream. Oddly, when one of the T1s upstream went south, our link
turned to mud-- but the Windows guys were fine. :/
> B.
>
> -----Original Message-----
> From: Jessica Blank [mailto:jessica@twu.net]
> Sent: Friday, November 30, 2001 11:03 AM
> To: Richard B. Johnson
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: Slow start -- Linux vs. NT -- it's time to acknowledge the
> problem!
>
>
> Sooo... having the Windows-type person remove NetBEUI and Windows
> filesharing (SMB) would fix this if this is indeed the cause of problems?
>
> On Fri, 30 Nov 2001, Richard B. Johnson wrote:
>
> > 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.
> >
> >
>
>
> =========================================
> J e s s i c a L e a h B l a n k
> -----------------------------------------
> Programmer * Unix Sysadmin * Web Geek
> jessica@jessl.org -- cell@jessl.org
> -`-,-{@ http://www.jessl.org/ @}-,-`-
> =========================================
>
>
> -
> 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/
>
=========================================
J e s s i c a L e a h B l a n k
-----------------------------------------
Programmer * Unix Sysadmin * Web Geek
jessica@jessl.org -- cell@jessl.org
-`-,-{@ http://www.jessl.org/ @}-,-`-
=========================================
-
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/
This archive was generated by hypermail 2b29 : Fri Nov 30 2001 - 21:00:39 EST