rec.autos.simulators

---------------------------------------(begin)----------------------
Paco Skiinoff writes regarding the suggestions for cable modem setup:

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.

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.

I use a program called I-speed which is freeware to control this. I
simply select 576MTU for net play at VROC and when I want to download
quickly I set it to 1500MTU. Just my opinion based on practical
experience.
------------------------------------(end snippet)----------------

Now, I've attempted to run a GPL server on my machine.  It's a fast

The cable modem is supposedly good for 768Kbps upstream, and 10MBps
downstream (both shared with my neighbors, of course).  

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!

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...

Thanks,  

--John Bradley

% ---------------------------------------(begin)----------------------
% Paco Skiinoff writes regarding the suggestions for cable modem setup:

% 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:
http://www.ultranet.com/~belleisl/mtu_mss_rwin.html

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.

<snip>
% ------------------------------------(end snippet)----------------

% Now, I've attempted to run a GPL server on my machine.  It's a fast

% 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...

% Thanks,  

% --John Bradley

--
**************************** Michael E. Carver *************************
     Upside out, or inside down...False alarm the only game in town.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<[ /./.  [-  < ]>=-=-=-=-=-=-=-=-=-=-=-=-=-=

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 E. Carver *************************
     Upside out, or inside down...False alarm the only game in town.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<[ /./.  [-  < ]>=-=-=-=-=-=-=-=-=-=-=-=-=-=

I suspect that RWIN only affects TCP/IP performance (streams), and not
UDP/IP performance (datagrams).  GPL uses only UDP/IP for its
communications (all datagrams, no streams).  I considered saying "UDP/IP"
in the game instead of "TCP/IP" so it would be technically correct, but
figured this would cause more confusion than it was worth.

Randy

% I suspect that RWIN only affects TCP/IP performance (streams), and not
% UDP/IP performance (datagrams).  GPL uses only UDP/IP for its
% communications (all datagrams, no streams).  I considered saying "UDP/IP"
% in the game instead of "TCP/IP" so it would be technically correct, but
% figured this would cause more confusion than it was worth.

Okay, now that the confusion cat is out of the bag, the following from
RFC 768 for UPD begs the question:  Why UPD over TCP?

"This protocol provides a procedure for application programs to send
messages to other programs with a minimum of protocol mechanism. The
protocol is transaction oriented, and delivery and duplicate protection
are not guaranteed. Applications requiring ordered reliable delivery of
streams of data should use the Transmission Control Protocol (TCP)."

I assume the overhead of TCP is greater than UDP and the trade off was
worth losing the "reliable delivery" TCP can provide.

--
**************************** Michael E. Carver *************************
     Upside out, or inside down...False alarm the only game in town.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<[ /./.  [-  < ]>=-=-=-=-=-=-=-=-=-=-=-=-=-=

There are a number of utilities out there to work with this...

-Larry