Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com From: Charles Henrich Newsgroups: scea.yaroze.freetalk Subject: Re: Audio breakup in the auditorium Date: Sun, 31 Aug 1997 13:43:25 -0400 Organization: SCEA News Server Lines: 57 Message-ID: <3409AD3D.7960145D@msu.edu> References: <01bcb55b$48b98360$6cbf43ce@wkwerner> <340850DD.92B0A366@msu.edu> <01bcb5e0$2da633e0$9bbf43ce@wkwerner> NNTP-Posting-Host: crh.cl.msu.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.02b7 [en] (X11; I; FreeBSD 2.2.2-RELEASE i386) Wayne K. Werner wrote: > You are incorrect there. The packet size used in the internet, and by > internet routers is indeed 576 bytes. When you use larger packets, they > must be disassembled into smaller packets on send and reassembled on > receive. The size of the receive window, also to prevent fragmentation, > must be a multiple of the data size, which is 576 - 40. Yes, you are > adding "extra" bytes up front. But the extra bytes are added anyhow when a > 1500 byte packet is fragmented, with the further inconvience of not > dividing up neatly, causing the system to wait for a second 1500 byte > packet to fill up the space after any leftover data from the first packet. Wayne go pick up any book on the subject (Computer Networks by A.S. Tannenbaum is a good start). You arent correct. MTU is purely a factor of the underlying transport, (e.g. PPP, Ethernet, FDDI, CDDI). In any case it hardly matters, because your packets are being encapsilated by some other protocol before being sent along on the internet. It is *that* protocol which is doing the fragmenting and reassembly, and any additional overhead you add in the data stream that protocol has to deal with gains you nothing. Hell, a large percentage of the high bandwidth links are running ATM, where we're talking a 48 byte packet size, of which 5 bytes are header! > > > Im curious as to how you measure this, downloads should be *slower* with > > Don't take my word for it, try it! FTP down a file from a nearby site, > time it, make the fix, and download the same file. Everyone I know who has > made the change has experienced a great increase in speed, all claiming at > least 2 times, some claiming as much as 3 or 4. I myself have experienced > an increase of at least 2 times. Sounds like there is definatly software bugs in the TCP/IP core of windows 95, but thats not all that unexpected. > Also, don't forget... just setting the MTU is insufficeint to realize the > improvements. The receive window must also be set at n * (576 - 40). > experiments with different values for n, but 4 appears to be optimal for > most people. (40 is the number of bytes in the packets header). The IP Header is 20 bytes plus a variable length options field. The minimum IP header is defined to be 5 32-bit words (or 20 bytes). Then you have your TCP data. Of course all this is only true for PPP links, which themselves have some packet overhead, which then in most places is turned into an ethernet packet which has even more overhead. From there out to 100mbps, or FDDI, or maybe even directly to a internet link, which could be running all sorts of funky protocols. The point here is, there is no internet standard transport. TCP/IP is the highest level protocol defined as the standard, but the underlying transport can change 100 times before ever reaching its destination, and during that entire mess, your adding TCP/IP overhead. -Crh -- Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich