In the following section, comments by Paco Skiinoff are in red, comments by John Bradley are in blue, and comments by Micheal Carver are in the default color.
Regarding Paco Skiinoff's comments about cable modem setup, Michael says this:
I just wanted to tell you that at the VROC site which claims that these patches will speed up cable modem proformance. I found these patches 10 months ago; to me they're old news but carry a price. Most cable modems run on a network whose MTU is 1500, such as mine. These patches in effect maximize this value so download speeds are higher. Reason is, larger packets. Playing with other cable modem players whose MTU is 1500 (Cable patch installed) when you have one as well is a treat.
Now here's why it's bad news. Most people are on dial up and the MTU is restricted to 576 or less, smaller packets. When trying to connect to a cable modem that is running a 1500 MTU, the dialup cannot keep up to the larger packets from the server. This causes major warping and lots of disappearing cars.
Hmmmm... I am not sure that this is true. It's a nice theory, but, if this were the case, your ISP would configure all of it's network MTU's to match lowly modem dial-up accounts. But, they don't, they maximize their settings for the best network optimization. MTU should be set to match one's throughput. If this is <= 128k, then the 576 setting is the proper choice. However, if the throughput is greater than 128k, the MTU can be raised to a higher value.
For a full and complete tutorial on this subject head to:
Now to add the monkey wrench (or spanner) into the works. MTU should also be scaled to match (or at least not exceed) the packet size one's ISP will handle. But this applies to things other than GPL on-line performance. Which may explain why some people may experience better hosting performance by lowering MTU size (then again maybe not). While I am gumming up the works, there are still some (let's hope the number is extremely low) routers out there on the net that can only handle MTU's of 576.
Okay, now back to GPL. . . As long as the MTU is set to at least a value greater than 126, things should work just fine with GPL (in theory). As GPL sends (by default) 84 bytes of data + 40 bytes (at most) of IP header per packet. Just because one has set the MTU (Maximum Transmission Unit) to a value of 576 or even 1500, this doesn't mean that GPL creates/sends/receives packets of this size.
The reason for DUN (Dial-Up Networks) settings with packet sizes of 576 or less as the "rule of thumb", is due to the limited bandwidth capable of 28.8/36.6/56k modems and also limitations imposed by SLIP/PPP protocols.
As to people are getting disconnected, it should have nothing to do with the host's MTU settings (unless it is set to an exremely low figure). There are a number of things which influence this, most are beyond the host's control. For the best discussion of these factors as they relate to GPL please re-read Alison's FAQ at http://nh.ultranet.com/~alison/gpl/faq-online.htm
Other than low ping rates, I believe the biggest culprits to be busy or poorly configured routers between the host and the client. If one is continuously getting disco'ed (even with good solid ping/latency rates), one should do numerous traceroute's to the host (use the DOS tracert.exe command) to determine if the problem is with routers along the path. If the "flakey" router appears to be on your side of the path, you should send the results of the traceroute to your ISP asking them to look into the matter. If they appear on the side of your host's connection, please forward this information to them and ask that they contact their ISP.
Here is a tid bit from my home page about the patch. These settings are aggressive and will help in speeding up download rates. The patch is based on a MTU setting of 1500. To improve gameplay on the net you will need to set the MTU to 576. Set MTU to 1500 for fast downloads and 576 for better gameplay with others, like dial-ups.
All cable modem players should set their MTU value to 576 to accommodate the smaller packets that most people are using. Telling people to use this patch will only make things worse.
Again, just because the MTU box can handle 1500 or 576 bytes of doesn't mean the "box" must be filled before a packet is sent. It just means that the maximum the box can hold is either 1500 or 576.
Now, I've attempted to run a GPL server on my machine. It's a fast machine (Celeron @ 450, 128MB, V2 SLI, etc), and I've got a cable modem. The cable modem is supposedly good for 768Kbps upstream, and 10MBps downstream (both shared with my neighbors, of course).
NOTE: While the cable modem may be capable of such transfer speeds, I would seriously consider that your ISP may limit or cap these speeds to a much (and in some cases extremely) lower speeds.
Anyway, whenever I try to do the GPL server thing, I'm plagued by disconnecting players. (I don't think they're disconnecting on purpose!) I'm tired of races being decided by whomever can stay connected longest!
Try limiting the number of clients allowed. If you are allowing up to 12, try lowering it to 10. If you still get alot of disco's, lower it again and see if the number and frequency of disco's improves. With my ADLS connection (tested to have solid 256 both up and down with my ISP), I can usually handle 11 other drivers with no real problems. However, as soon as I allow 2 more drivers, the number of disco's and frequency tends to rise dramatically.
So, I thought I'd try this guys suggestion (MTU=576 instead of 1500). I can measure the decreased throughput (1/3rd the speed) when downloading files, but I have no idea if it'll actually help GPL.
The QUESTION: Should the MTU setting even matter? I was under the impression that GPL was emitting tons of tiny little 84-byte packets, which would seem to make the MTU setting irrelevant. But perhaps I just don't understand what's really going on down there...
I've been doing some more research on this "black magic" topic of MTU/MSS/RWIN settings. Aside from my observations of setting the MTU & MSS to match one's connection speed to their ISP, there are some other settings that may actually apply more to our quest for solid hosting and connection for online GPL racing.
The first one to look at is RWIN. This setting controls how much data the receiving computer is prepared to receive. If this setting is too high it will take longer to retrieve lost or damaged packets. If I understand this correctly, RWIN specifies how many packets it is will to accept at one time. If it is set to 6x's the MSS, there are 4-5 packets floating around that can easily be lost. Lost packets usually result in disco's or major warping. (Theory: This may have more affect than setting the MTU to 576. As setting MTU to 576 implies a MSS of 546, a RWIN of 4xMSS specifies lower expected packets, therefore fewer lost packets.)
"RWIN (Receive WINdow) is the limit set by the TCP receiver on the amount of data (hence, the number of TCP segments) the TCP sender is allowed to have outstanding on the Internet, pending his receipt of ACK(nowledgement of receipt) signals from the TCP receiver. An announcement of the available data window is the basic method of flow control used by TCP. Each time the TCP receiver ACKs the receipt of all bytes up to a particular sequence number, it also announces the available data window to the TCP sender . The value you specify for RWIN is the maximum value you will permit for the available window announcement. (The available window is reduced from the RWIN value by the number of bytes received but not yet processed).
NOTE: RWIN also corresponds to the size (in bytes) of the buffer your machine waits to fill with data segments before it attends to whatever other TCP transactions (like newsreading, or EMail) are occurring on other threads through the multiple logical sockets your WinSock has open while your download is in progress. This can affect the response delay you experience in mouse-clicking a URL on your web browser while an FTP file download is running in the background." [from Al's WinSock Tuning FAQ http://www.ultranet.com/~belleisl/tune_faq/settings.htm]
"RWIN determines how much data the receiving computer is prepared to recieve. An RWIN value that is set too high will result in greater data loss if the packet is lost or damaged in transit. An RWIN value that is set too low will produce very poor throughput. Typically, an RWIN value should be set that is 3 or 4 times the size of the Maximum Segment Size (MSS)." [from iSpeed's help file]
TTL (Time To Live): For some clients this could make our break their connection (especially for those trying to connect across the globe). The TTL setting determines the number of hops allowed to reach other systems on the network.
MTU Auto Discover: I haven't experimented with this yet, but it maybe helpful for those hosting. The theory is that this may automatically set the host's MTU to match the client with the lowest MTU capabilities.
"Setting this option causes TCP to attempt to discover the Maximum MTU (largest packet size) over the path to the remote host. By discovering the Path MTU and limiting TCP segments to this size, TCP can eliminate fragmentation at routers along the path that connect networks with different MTU's. Fragmentation adversely affects TCP througput and network congestion." [from iSpeed's help file.]
NDI Cache Size: May or may not help at all, but hey it's all black magic, right?
"I've not been able to locate any information from Microsoft regarding this value. However, due to popular request, I've included support for adjusting it when running under Windows 95/98. The option is disabled when running under Windows NT.
The Microsoft default for this value is 0. The supported values are 0, 16, 32 and 64. Many users have reported improvements when setting this value to 16, especially with the MaxMTU set to 576 and RWIN set to 2144. If you are using higher MTU and RWIN values, you may want to adjust the NDI cachesize to 32." [from iSpeed's help file.]
- Michael Carver
For another interesting page with information about related topics, see Bart Westra's detailed analysis of online issues. Bart discusses GPL's bandwidth requirements in detail and suggests some new settings for GPL's core.ini file.
For more information about racing over the Internet, see my GPL Online FAQ.