copyright 1998-1999, Alison Hine
http://simracing.com/alison/gpl/faq-online.htm
Racing in GPL over the Internet presents a special set of challenges.
Because of GPL's bandwidth requirements and the high CPU resource
demands of its physics engine, we're pushing the envelope, running on
the ragged edge of what's possible with today's Internet technology.
When things are set up correctly, the experience of racing in GPL with
people hundreds or thousands of miles away is unparalleled. However,
to optimize the online racing experience, certain preparations must be
made, and familiarity with the issues surrounding Internet play is a
useful prerequisite for the would-be online racer.
To help GPL racers get the best possible online racing experience,
I've compiled an extensive discussion of issues and solutions involved
in online racing in GPL.
For still more information about GPL online racing issues and
solutions, see the VROC Technical Notes page.
1.1 Is racing in GPL over the Internet the same as racing over a LAN?
It's essentially the same, but with certain limitations. See the next
question.
1.2 What limitations and requirements does GPL have when racing over
the Internet that it doesn't have over a LAN?
The ancient serial port architecture places the most serious
limitations on online racing in GPL, although wildly variable latency
on the Internet also introduces difficulties. Cable modems, ADSL, or
ISDN (when not connected to the computer through a 16550-based serial
port) all avoid the serial port limitations, as do Universal Serial
Bus modems.
Here is a list of constraints you are likely to encounter in racing
GPL over the Internet:
* Fewer players. On a LAN, you can have up to 20 players. Over the
Internet, you're most likely going to find that you are limited to
four or five players when hosting over an analog line, fewer
unless you make adjustments to certain default settings in Windows
and GPL. If you try to connect too many players, one or more will
get booted from the game when the excessive player joins. This is
due to limitations of the serial port. Many more players are
possible when hosting over a digital connection. We've seen as
many as 20 players, with 10 to15 typical in games hosted via
digital connections, including cable modem, ADSL, T1, or ISDN
(that is, ISDN where no serial port is involved).
* DUN upgrade and tuning. If you're racing over a serial port, I
highly recommend that you upgrade your DUN to 1.2 or later unless
you have Windows 98. This is because DUN 1.2 is more efficient
than the DUN that came with Windows 95, and using it tends to
reduce the impact of the use of the serial port on gameplay. It
also can reduce ping times by as much as 50 to 80 ms, which is
highly desirable. Also, we've found that altering certain settings
in Windows' Dialup Networking Connection can yield great
improvements in certain aspects of online play, including a
significant increase in the number of players which can join a
game. See here for details on downloading and installing DUN 1.2
and tuning your DUN and serial port settings.
* Frame rate recommendation: solid 36 fps. For racing on the
Internet, you need more CPU power than you need to run solo or
over a LAN, again due to serial port limitations. Alternatively,
you can turn down graphic detail, but if everyone is not running
at a solid 36 fps, things can get very weird. (Randy Cassidy
disagrees with this; see below.) Note that you can sidestep this
issue and eliminate a lot of online racing's most common problems
by using a Universal Serial Bus modem instead of a serial port
modem (or better yet, a digital connection such as ADSL or cable
modem). If you already have an analog modem or external ISDN
device, you can use a USB to Serial Converter.
* Ping times. You want to have ping times below 500 ms from client
to host, and if there are multiple clients, you'd like it even
lower. Actually, the lower the better, and if it's under 280 ms or
so, it begins to look like you're on a LAN.
* Warping. In Internet play, you're likely to see warping, which is
the bane of online racing. However, if your ping times are low
enough and stable, this goes away. When it occurs, it's dealt with
as well as I've seen in any online racing game.
* Full install of GPL. It's important when racing online,
particularly when hosting, to do a full install of GPL. This
avoids certain anomolies such as missing green buttons on the
clients' race weekend screen, and clients getting booted when the
host saves a setup or reply file.
* Full-function modem. Many people have Winmodems or other modems
which offload some communications functions to the CPU, as a cost-
saving measure. This may work fine for Web surfing, but it's death
for online racing in GPL. You must have a real modem to
participate effectively in online races! Although a conventional
serial port modem will work, a Universal Serial Bus modem is
generally far superior to a serial port modem for GPL. Another
alternative is an external serial port modem connected through a
USB to Serial Converter.
* Assorted anomalies. There are several odd things that seem to
happen only during Internet-based multiplayer races. These are the
two most severe:
o Giant warps. Sometimes an opponent's car may disappear and then
reappear a great distance away, and then keep on going. If you
are running as a client, this may be accompanied by a screen
flash and/or a warble in the engine sound.
o Irregular frame flow. Sometimes the action on your screen may
seem to be moving jerkily, or speeding up momentarily, even if
you are seeing 36 fps on GPL's frame rate counter.
See the section on bizarre behaviors for details on how to
eliminate these anomalies.
There are also some less severe anomalies, none of which are
showstoppers. I mention them so if you see them you won't think
you're hallucinating. The most common:
o Missing green button. Sometimes a client may not get a green
button to proceed to the track after arriving at the weekend
screen. The workaround for this is to exit and rejoin the game.
If the connection quality is poor, it may take a couple of
tries. Note: this problem can be very common if the host is
running on a system which had a partial install of GPL, even if
a full install was done later. See below for details.
o Missing lap times. Sometimes your lap times don't get reported
right away. Sometimes you may not get any lap times for an
entire session; if this is the case, ask the player hosting the
game if they have done a full install of GPL. If they did a
partial install, even if they followed it with a full install,
you are likely to have this problem. See below for the fix.
o Remote cars don't fly. If your ping times are high, you will
find that remote players' cars never leave the track surface,
and don't move up and down on their suspensions, either. In a
crash, parts of a remote car may appear to go below the track
surface as it tumbles.
o Bogus DQ's. Occasionally, you may get disqualified for going
backwards on the track even if you know you didn't. If everyone
is getting 36 fps all the time, this is fairly unlikely.
o Replay anomalies. Replays may have periods in which some remote
cars disappear. Also the screen will appear jittery when viewing
a remote car if warping occurred while the replay was being
captured.
o Random disconnects. Sometimes, if the connection quality is poor
(high ping times or an intermittently busy router on the route)
you may find that one or more clients get disconnected from a
session. In a practice session, it's no big deal, because you
can simply rejoin, but in a race it can be frustrating because
if it happens, you're out.
Despite these issues, when you've got things set up right it works
great. Sometimes it's so good that it's hard to tell you're not on a
LAN.
1.3 What exactly do I need to do to prepare my machine for racing
online?
You don't necessarily need to do anything special to host or join a
two-player race.
However, for races hosted over a serial port, if you wish to have more
than two players, it's important to tune your DUN and serial port
settings. Click here for details, and review the Maximum Players
section for more information.
If you have a Winmodem, you must take special steps to prepare your
computer for serious online racing. Get a screwdriver, and open your
computer's case. Locate the Winmodem, and disconnect the phone line.
Remove the screw holding it into its slot, and carefully remove the
Winmodem.
Now, go over to the nearest window, or, better yet, climb up onto your
roof. Taking care to avoid innocent bystanders, grasp the Winmodem
firmly in your throwing hand, and heave it as far as you can. If
possible, ensure that the Winmodem strikes a solid object on the
descent portion of its trajectory, thereby destroying it and
preventing some hapless passerby from putting it in their computer and
potentially joining and ruining your future online races.
Now go buy a real modem.
By far the best analog modem solution for GPL is a Universal Serial
Bus modem rather than a conventional serial port modem. An alternative
is an external serial port modem connected through a USB to Serial
Converter. Note that there are some caveats with USB modems, mainly a
possible degradation in frame rate on slower machines running Voodoo 2
cards.
A digital connection such as ADSL, cable modem, or ISDN is much better
than any analog modem, if you have such a connection available. If you
go with ISDN, avoid an installation based on the serial port (i.e. an
external ISDN modem) in favor of an ISDN router and Ethernet card (the
best ISDN solution), a USB-based ISDN modem, or an internal ISDN
Terminal Adapter that uses a serial controller that is more
intelligent than a 16550 UART. An external ISDN modem connected
through a USB to Serial Converter might be another good alternative.
If you have a cable modem, check out PH Net's suggestions for cable
modem setup. You might also want to look at this page if you have an
ADSL or other DSL connection. Also read Paco Skiinoff's comments on
MTU value in the GPL Reader FAQ.
There are certain other steps that you may find will help avoid
certain strange behaviors in GPL multiplayer races, particularly those
hosted over the PC's standard 16550 UART-based serial port. You may
find it helpful to switch to the DirectInput joystick driver if you
are currently using the Generic driver for your controller. You'll
find this on your Options screen in GPL.
I've also found that reducing graphics options and/or upgrading
hardware to get 36 fps helps eliminate the bizarre behaviors which can
occur in GPL if the CPU is saturated and you are connecting to other
players through the serial port. See the section on bizarre behaviors
for more details.
1.4 Do I really need to get a frame rate of 36 fps?
The beta team's empirical testing suggests that 36 fps is important to
avoid certain strange behaviors in GPL multiplayer races hosted over
the PC's serial port.
However, Papyrus engineer Randy Cassidy, key developer for the
multiplayer components of GPL, comments:
"It really should not be the case that either the client or the server
must run at 36 fps for a multiplayer game to run smoothly. We have run
many a smooth multiplayer race here at the office with our P-200's
never seeing the light above 20 fps, never mind a constant 36 fps.
"Perhaps when the machine is saturated, it's not servicing the serial
port in a timely enough fashion. I suggest all players run with their
16550 sliders for the port settings of your dialup connections (and
modem connections if you ever run modem-to-modem races, and serial
port settings if you ever run null-modem cable races) at the second
click from the left. If you don't, this could have a profoundly
negative effect since incoming packets will be lost, and outgoing
packets will either be lost, or delayed. [See here for details on how
to make this important adjustment.]
"Also, I suggest all players use DirectInput, instead of the Generic
driver. We disable interrupts during the joystick read in the Generic
driver, which will more than likely cause bad things with the serial
port."
VROC went live in mid October 1998, providing a place for online
racers to connect with each other. As a result, now have fairly
extensive experience with online racing, with a wide variety of
hardware and connection quality.
This experience seems to confirm that, as Randy suggests, the serial
port is a serious bottleneck for online racing. When the CPU is
saturated, packets get lost. Re-send attempts quickly saturate the
available bandwidth, and people start dropping like flies, while
others get clock smashes or frame stuttering.
The involvement of the serial port and its special requirements for
frequent interrupts makes the online environment quite different in
this regard than a LAN environment such as the office LAN at Papyrus.
Experience shows that some people can participate in online races
fairly effectively with frame rates below 30 fps. However, if you are
getting disconnected, or are getting frequent screen flashes
accompanied by giant warps, get your frame rate to 36 fps.
For some reason, this seems to be even more important on fast
computers (P2-300's and above) than on slower ones. I suspect that
this is because on older machines, which are more likely to be running
older 3D cards, fill rate, rather than CPU occupancy, limits the frame
rate. In this case, there still may be CPU power left to properly
service the serial port.
The best solution is to elminate the serial port in favor of a
Universal Serial Bus modem. A digital connection such as ADSL, cable
modem, or ISDN is much better still, if you have such a connection
available. If you go with ISDN, avoid an installation based on the
serial port (i.e. an external ISDN modem) in favor of an ISDN router
and Ethernet card (the best ISDN solution) or an internal ISDN
Terminal Adapter that uses a serial controller that is more
intelligent than a 16550 UART.
2.1 Ok, how do I find other people who would like to race GPL online?
The place to go is the Virtual Racers' Online Connection. Here you'll
find lots of folks eager to race online, and during peak periods
(evenings and weekends) there are typically several people hosting
races on cable modems or other high speed connections. It's free, and
there's an integrated chat to help you get acquainted with other
racers. There are also pages with detailed help and technical
information about racing online.
You can also connect over the Interenet wth other people who you might
already know, or meet through ICQ, Kali, or some other method.
3.1 What do the players need to know in order to join an online race
that I'm hosting?
All they need to know is your IP address. Give this to them via a chat
or email, or even over the phone, and then run GPL and select
Multiplayer on the main menu. Once at the Multiplayer screen, click on
the Host button. Then choose the connection(s) you would like to host
over, and click the green button to proceed to the Track Selection
screen. Once you do this, other players can join your session.
At the Track Selection screen, click the Chat button or hit the tilde
(~) key to turn on the Chat Pad to see messages announcing when
players join or leave your race session. Type into the Chat Pad to
send other players messages.
When you've agreed on where to race, choose the track, set the race
type and practice length, choose the number of AI cars (I recommend
you try it without AI cars at first) and then click the green button
to proceed to the Weekend screen.
Randy Cassidy has made available a program which will ping a GPL
server and return a string containing all the essential information
about the current session. You can download the source and executable
for this program here.
3.2 How do I get my IP address? I think it changes every time I dial
in to my ISP.
Because of the shortage of IP addresses, most ISP's assign you a new
IP address dynamically, from a pool of available addresses, each time
you log in. This is a nuisance, but easy to deal with.
In your Windows folder, there is a program called Winipcfg.exe. I
recommend creating a shortcut to it on your desktop. Just run this and
it will tell your your IP address.
Alternatively, you can download a nifty little utility called
MyIPAddress from Outlandish. This does the same thing, but it's a
little more convenient.
Also, if you are logged into ICQ or Kali, you can find out your IP
address from them. See their documentation for details.
Also, once you're in GPL, you will find your IP address on the
Multiplayer screen, but this isn't very helpful for telling other
people who'd like to join you unless you have some external way of
communicating with them, such as via telephone.
3.3 Ok, I have the IP address of someone who is hosting a race. What
do I do?
Run GPL, select Multiplayer on the main menu, and then in the
Multiplayer, click on the Join button. Select the IP address for your
dialup connection from the Connect Via drop down list. Then enter the
address of the machine you're joining in the IP Address field. Now
click the green button to proceed to the Track Selection screen.
At the Track Selection screen, click the Chat button or hit the tilde
(~) key to turn on the Chat Pad to see messages announcing when
players join or leave the race session you've joined. Type into the
Chat Pad to send other players messages.
When the green button appears on the Track Selection screen, you can
click it and proceed to the weekend screen.
Note that you will not be able to join if the practice is over and the
race has begun.
Also note that if your ping time to the host is above 400 to 500 ms,
you are not likely to have very good game play. You'll probably see a
lot of warping, and you may also have trouble staying connected. You
may also experience a variety of bizarre behaviors.
3.4 What special keys are active and/or useful during a multiplayer
session?
~ (tilde) - while in the menus, toggles the Chat Pad off and on.
Alt-F - shows frame rate.
Alt-L - shows latency (ping time) to the server. Note that while in
the menus, the Chat Pad must be off to retrieve the ping time, but
on to display it. Simply hit the tilde key, Alt-L, and then tilde
again.
Enter - while in the car, this allows you to enter a line of chat
text. Press Enter again to send it.
V - while in the car and stopped, this allows you to jump to the
next car and view the action from its cockpit. Be careful; if your
car is stationary too long, it gets yanked from the world and
returned to the Weekend screen.
Shift-V - same as "V", but jumps to the the car behind.
Shift-R - repairs your car, if damaged, and sets it upright on the
track, with fresh (cold) tires and fuel tank refilled to the level
specified in your setup. This is not available in all sessions; see
the Damage and Repairs section of the general FAQ.
See the F1 key (Function Key 1) for a help menu with some other keys.
See my keys help page for a list of other useful keys. Also see the
readme.txt file in your GPL folder for information about the replay
keys; these are mostly alternatives to the buttons on the screen under
the replay window.
4.1 How do I measure ping time to the GPL host?
If you are in Windows, open a DOS prompt and type:
ping 123.123.123.123
where 123.123.123.123 is the IP address of the potential host.
If you are in GPL's menus, turn off the chat pad, type Alt-L, and then
turn on the chat pad. If you are in the car in GPL, just type Alt-L.
4.2 How do I measure ping time to my GPL clients?
If you are in Windows, open a DOS prompt and type:
ping 123.123.123.123
where 123.123.123.123 is the IP address of the potential client.
You can't measure ping time to clients within GPL, but you can ask
them to measure the ping time to you and then tell you via the Chat
Pad.
4.3 How can I improve my ping times?
Ping times are dependent on the quality of the route (i.e. the number
of hops) between you and the other machine, the efficiency of the DUN
software on your computer, the speed of your modem, and a vagary which
might be called "Internet Weather". This refers to the state of the
Internet backbone at any given moment. Factors affecting Internet
Weather include the density of traffic on the Internet at the moment,
how many important routers are overloaded or down, and probably the
phase of the moon.
Your best bet is to go to a digital connection, either ISDN, ADSL, or,
most preferably as far as I can tell, a cable modem. Unless, of
course, you are already on a T1 line, you lucky dog! A digital
connection typically knocks about 100 ms off ping times.
If you're stuck with an analog dialup connection (i.e. a 33.6 or 56 k
modem), I highly recommend that you consider a Universal Serial Port
modem. If this is not feasible, see Dun and Serial Port Settings for
complete details on optimizing your DUN connection, including
downloading and installing DUN 1.2. Read this if you have ISDN as
well.
4.4 What is this stuff about Internet routes, and how do I find out if
I have a good one?
The route refers to the series of nodes (called "routers") which
forward the packets of data from your machine to a remote machine, and
back again. The fewer the number of routers, or hops, between you and
the remote machine, the better your gameplay is likely to be. I've
found that we can play even with over 20 hops, but it's likely to be a
lot better with 11 or 12 hops.
If you want to check the number of hops in the route between your
machine and another machine somewhere else on the Internet, all you
need is the IP address. Open a DOS prompt, and type:
tracert 123.123.123.123
where 123.123.123.123 is the IP address of the other machine. This
will trace the route and display information about each node on the
route.
Note that this does not tell you if one or more of the routers on the
route is busy, which could seriously affect your game play. If you
want to find out more about how the routers are performing, try a
program called UOTrace, available at http://www.primenet.com/~simpson,
or PingPlotter, at http://www.nessoft.com/pingplotter/
Note that there is most likely a different route from the remote
computer to your computer than the route from yours to the remote. To
trace the route from the other computer to you, the person at the
other end will need your IP address, and will need to run tracert or
one of the other trace programs from that end.
5.1 We tried to run an online multiplayer race with three/four/nine
players, but everyone kept getting disconnected. Why is this?
Over the Internet, with the default Windows Dialup Networking
Connection and modem settings, you're limited to hosting one player
over an analog line, or two or three over an ISDN line. If you try to
connect too many players, one or more will get booted from the game
when the excessive player joins.
This is due to limitations of the serial port. It is possible to host
many more players over a digital connection, such as cable modem or
ADSL, since these don't involve the serial port.
Randy Cassidy comments:
"You can't shove a watermelon through a straw, either. By default, a
GPL server requires about 17,000 to 29,000 bits per second of
bandwidth to each client that connects to it. If you're running a GPL
server connected to the Internet with a 33.6 modem, you're pushing the
envelope even trying to get two clients connected to it."
5.2 Is there any way I can host more than one client over an analog
dialup connection?
Yes. You can host more players over a dialup connection if you adjust
the Windows Dialup Networking Connection and serial port FIFO settings
(see here for details) and reduce GPL's bandwidth from the default.
With GPL's default dialup bandwidth settings, we've found that you can
usually host only one client. If you over-ride GPL's default
bandwidth, you can most likely host two clients.
The same is true for hosting over an ISDN connection, except that it
seems to be possible to host two clients with the default bandwidth
and three with a smaller bandwidth.
The good news is that by tuning the DUN and FIFO settings and reducing
GPL's bandwidth, we have hosted as many as four players over a 33.6
connection!
5.3 What is the tradeoff when lowering GPL's bandwidth?
Reducing the bandwidth can increase warping, and can also aggravate
the strange things that can occur if you or the other players are
running at less than 36 fps.
Also, it is necessary that everyone be using bandwidth settings
compatible with those being used by the host, or else they will not be
able to connect to the host.
In practice, the beta team has run many races with reduced bandwidth,
and has found gameplay to be quite acceptable.
5.4 Ok, I want to try this. How do I tune my DUN and FIFO settings?
Simply click here and follow the instructions.
5.5 Ok, I did that. Now how do I reduce GPL's bandwidth?
Simply open the folder in which you installed GPL (by default,
C:\SIERRA\gpl). To make sure you have the right folder, check to see
that it contains the GPL executable, a file named gpl.exe.
In this folder create a file called core.ini. Using a text editor such
as Notepad, open this file and insert the following lines:
[ Communications ]
net_mdm_client_send_every = 3
net_mdm_client_send_size = 84
net_mdm_server_send_every = 3
net_mdm_server_send_size = 84
Send a copy of the same core.ini file to everyone who will be joining
the GPL session and have them put it in their GPL folder. Everyone
must have compatible settings, or they won't be able to connect to the
GPL server!
Remember to remove this core.ini file, or rename it, before you try to
connect with someone who is using the default settings.
5.6 What do the numbers in this core.ini file mean?
The net_mdm_*send_every parameter determines how frequently a packet
is sent across the connection to the remote player's GPL. The default
is every 2 ticks (1/18th of a second). By changing this value to 3
ticks, we send information less frequently, giving the CPU a chance to
empty the serial port's buffer before an error is generated.
A value of 3 seems to allow one additional player to join over a
dialup connection. I've tried a value of 4, but this generated
numerous clock smashes. However, it might work if everyone has a very
fast computer and ping times are very low. Let me know if you have
success with this.
The net_mdm_*send_size parameter determines the size of the packets
being sent. It is best to use a number calculated from the formula (16
* n) + 4. The default setting is 84 bytes.
I have tried reducing this value but it didn't seem to help. I'm
including it so ambitious people can experiment. If you find that
using smaller packets allows you to connect additional players, please
let me know!
Note that the client and server can use different values; for example,
theoretically the server could send 84 bytes every 3 ticks, while the
clients could send 68 bytes every 2 ticks. I'm not sure there is any
advantage to this, but again if you have success, please let me know.
5.7 Where can I get more information about GPL's bandwidth
requirements?
For a very detailed in-depth analysis of GPL's bandwidth requirements
and latency issues, see Bart Westra's "Tips, Links, and Files for
Grand Prix Legends". Go to the GPL Online Facts page and click on What
Really Happens.
Also see the Tech Notes, Troubleshooting, and Cool Stuff pages on
VROC, and the Other Sources section below.
5.8 I did a partial install initially, then a total install later on
top of it. Now if I host a multiplayer race, when I save a setup or
replay, all my clients get booted. Also, often they don't get a green
button on the weekend screen.
The problem is that when you've done a partial install, GPL goes to
the CD-ROM drive whenever you save a replay or setup, or when you load
a track. During the time when GPL is waiting for the CD-ROM drive to
respond, it can't service the communications, and critical packets get
lost.
Randy Cassidy says:
"If you've already done a full install over a partial install, you
don't need to reinstall the game, just open up the folder that
contains gpl.exe, and remove a file named lib.cfg (if you first look
at its contents, you'll see that it's pointing at your CD-ROM drive).
The presence of this file is what makes the game think that it's a
partial install, and is thus causing it to mess with the CD-ROM."
I believe some of these issues might also occur if you have a very
slow hard drive and your clients have faster drives and can load their
tracks before you can. Adding a second hard drive and arranging for
Windows' swap space to be on a different drive (physical drive, not
partition) from GPL might help with this.
6.1 Bizarre stuff happens on my screen when I try to race over the
Internet. My frame rate is really choppy, or the screen flashes and
then the other players' cars jump huge distances and keep going.
This is most likely due to either the clients or the server's CPU
being saturated; in other words, someone is not getting a solid 36
fps, as measured by GPL's frame rate meter (Alt-F).
When the CPU is saturated while racing online, there are two major
anomalies that occur:
* Frame stuttering. This occurs only on the clients. You will appear
to be getting poor frame rate, but if you turn on the frame rate
meter (just hit Alt-F) you will see that you are getting 36 fps.
You may also find that the action suddenly speeds up. If you watch
closely, you will see that it is not poor frame rate, but rather a
kind of erratic hesitation, or stuttering in the flow of painting
the frames.
* Clock smashes. These show up as screen flashes followed
immediately by major warps; your opponent's car may suddenly
disappear and reappear some distance ahead of or behind where it
was. This can occur on both client and server.
There are several other less significant things which occur, such as
not getting a green button, or not getting your correct lap time right
away, or getting disqualified for going backwards on the track.
Randy Cassidy comments:
"Clock smashes can only occur on clients. A server will never adjust
its clock for any reason. During the period when a client's clock is
smashing, the server may see anomalous gunk from that client, and that
client's car may jump around on the server (and, in turn, all other
client machines as well), but this is not (in our parlance) a clock
smash. If the server begins paging, this will throw timing off, and
cause clock adjustment on all clients."
6.2 Why do these strange things happen?
Both issues have to do with the way GPL keeps its clients' internal
clock in synch with the internal clock in the server, who is hosting
the game. Randy Cassidy explains:
"In order to accurately reflect the movement of the cars in the game
world, all machines participating in a game must have the same notion
of time. The timer chips on PC's can vary by a few percent, so a game
can actually run a bit faster, or a bit slower from one machine to the
next. If two machines whose timer chips tick at different speeds are
connected in a multiplayer game, this must somehow be reconciled, or
the two machines will very quickly diverge.
"If a GPL client believes it is running at a different speed than the
GPL server to which it is connected, it will either speed up or slow
down slightly to compensate. When the latency (ping time) between a
GPL client and a GPL server varies wildly (which can happen if a
router suddenly becomes busy), or if a lot of transmitted data is lost
(which can happen if a router's packet loss spikes up), this can fool
the GPL client into thinking it's not running at the right speed, and
cause it to speed up and slow down continuously, causing frame
stuttering.
"If a GPL client ever thinks its clock is way out of synch with its
server, the client will reset its clock, causing a clock smash. When
the latency between the client and server is both very high, and
varying wildly, clock smashes are more likely to occur."
See the ping section for more details on measuring and improving ping
times.
I have also observed that taking measures to reduce CPU occupancy,
such as by reducing graphic display options, can also help reduce or
eliminate these problems. I've found that when all GPL clients and the
GPL server are running at a solid 36 fps, clock smashes and frame
stuttering occur infrequently or not at all.
6.3 Am I going to have to live with this stuff whenever I race online?
Absolutely not!
If you can, switch to a digital connection (cable modem, ADSL, T1, or
ISDN). If none of these connection types are available in your area, I
strongly recommend you get a Universal Serial Bus modem.
Failing all of the above, and you're stuck with a serial port modem,
make sure you have "tuned up" your DUN and serial port settings. Also
try switching to the DirectInput driver for your controller. The
Generic driver for the controller disables interrupts, which can play
havoc with the serial port.
If you are still experiencing clock smashes when running as a client,
you can make GPL resynchronize with the remote GPL server more
frequently. To do this, simply open the folder in which you installed
GPL (by default, C:\SIERRA\gpl). To make sure you have the right
folder, check to see that it contains the GPL executable, a file named
gpl.exe.
In this folder, if you haven't already, create a file called core.ini.
Using a text editor such as Notepad, open this file and insert the
following lines:
[ Communications ]
clock_adj_delay = 10
This will make your machine resynchronize its clock with the server's
clock a little more often, which should help it stay in step and avoid
clock smashes. The default value is 12; if you still get clock smashes
with a value of 10, try reducing it further. If you go too far, you
may begin to experience frame stuttering.
The next measure to take is to ensure that all players' machines (or
at least those connected to the Internet through a serial port) are
running at a steady 36 fps, as measured by the frame rate meter (Alt-
F). If you are a client, and are experiencing frame stuttering, ask
the host to cut graphics detail till he or she is getting a solid 36
fps. If you are a host, and see clock smashes, ask your client(s) to
cut graphics detail till they see a solid 36 fps.
Note that a steady 36 fps gives the most benefit; if it's dropping to,
say, 32 fps at a certain corner on the circuit, or when there are a
lot of cars around, then you or your clients may still experience the
bizarre happenings.
6.4 Which graphics details should I cut back first?
On a Rendition card, I always turn off anti-aliasing; I just don't
like what it does to stuff on the horizon.
When running online, I turn the mirrors down to Cars Only, and
eliminate car textures in the mirrors.
If I need more CPU power (i.e. my frame rate is still below 36 fps, or
I'm a client and am getting clock smashes, or I'm hosting and the
clients complain of frame stuttering) then I eliminate beveled tires,
everything in the cockpit, all lighting effects, and all special
effects. I also cut detail bias to 50% or less if necessary.
That usually does it, but if not, I can also eliminate terrain
textures, tire textures, and then start cutting other textures.
6.5 Ok, I reduced my graphics detail, but now things are really ugly.
What are my alternatives?
Assuming you've installed DUN 1.2, tuned your DUN and serial port
settings, and are using the DirectInput driver for your controller,
your remaining option is to upgrade your hardware. See my GPL Hardware
FAQ for details. Also see Universal Serial Port modems.
7.1 Can I host players simultaneously over a LAN and over a dial-up
connection?
Yes. GPL allows you to designate any or all of the available
connections for hosting players in a multiplayer game. For example, I
have a LAN at home, and I have the usual dialup connection to the
Internet, via a 56 kb modem. My LAN is set up for both IPX and TCP/IP.
I can dial into the Internet, and then run GPL. When I get to the
multiplayer screen, I can choose to host over the Internet TCP/IP
connection, the LAN TCP/IP connection, and the LAN IPX connection, all
at the same time.
7.2 If I'm on a LAN, does it matter if I use IPX or TCP/IP?
Yes. To accommodate hosting dialup-based clients when the host is on a
high speed TCP/IP connection such as a cable modem, GPL's default
bandwidth for all TCP/IP connections is the same as that for analog
dialup connections.
The default bandwidth for IPX in GPL is higher than that for TCP/IP,
to allow for greater efficiency over LANs. If you use TCP/IP on a LAN,
and there are a lot of players in the race, some of the players may
wink out, especially in replays. It's best to choose IPX if you have
the option.
Note that you can over-ride the default bandwidth for any connection
type, and also over-ride the default behavior of having ethernet
TCP/IP connections use dialup bandwidth. Instructions for doing the
latter are in the readme file that comes with GPL. I will post more
complete instructions for adjusting bandwidth in the near future.
7.3 I'm running GPL on a Windows 95/98 LAN workstation, using a Linux
gateway machine to allow access to the internet. How do I host/join
races?
I don't have any experience operating GPL behind a Linux gateway.
However, John Simmons and Andrew Lavigne have figured out how to both
host and join races in GPL from behind a Linux gateway. The 2.2 Linux
kernel is required to join from behind the Linux gateway.
John has documented documented their findings here.
This is the essence of their recommendations:
From John Simmons:
Hosting A Remote Race Behind a Linux Gateway
If you want to host GPL races through a Linux gateway, you must be
using a recent kernel, you must have IP masquerading and IP forwarding
enabled, and you must download and compile a program called ipautofw.
First, get the latest stable version of the kernel that is currently
available. You'll need 2.0.33 or later; the latest version at the time
of this writing is 2.2.0.
Next, turn on the necessary features and re-compile your kernel (if
you updated it or need to turn on features).
Things you may have to reconfigure:
* Enable experimental features (you need to do this to enable IP
forwarding)
* Enable IP forwarding
* Enable IP masquerading
I've enabled anyhing having to do with IP forwarding, masquerading or
aliasing. It may not have been needed but I hate compiling the kernel
over and over again.
Download and compile the ipautofw program. To find it, do an Alta
Vista search for "ipautofw" and you'll get several hundred references.
Lastly (and don't forget, we're assuming IP masquerade is already
properly enabled/configured/implemented), add this lines to your
rc.local file AFTER the ipfwadm lines:
ipautofw -A -r udp 32766 32766 -h X.X.X.X -v -u
ipautofw -A -r udp 6971 6971 -h X.X.X.X -v -u
Replace the X.X.X.X with the internal IP address of the machine you're
running GPL on. For instance MY machine's internal IP is 10.10.0.1, so
I would change the line to read like so:
ipautofw -A -r udp 32766 32766 -h 10.10.0.1 -v -u
ipautofw -A -r udp 6971 6971 -h 10.10.10.1 -v -u
You can now host GPL races, even on VROC.
Joining A Remote Race Behind a Linux Gateway
This section was added on 04/23/99
Update your kernel to 2.2.x. Discussing downloading, updating, and
compiling the kernel is beyond the scope of this web page. I also
assume that while updating your kernel, you will already know how to
setup a Linux gateway and all of the basic configuration stuff will
already be performed by you.
Use ipchains for your basic masquerading duties (this won't work
otherwise). Include this line before your first ipchains statement:
echo 1 > /proc/sys/net/ipv4/ip_forward
Download and compile the ipmasqadm tool.
Add these lines to your rc.local file:
# Flush the ruleset /usr/sbin/ipmasqadm autofw -F
# Be a GPL server
/usr/sbin/ipmasqadm autofw -A -r udp 32766 32766 -h X.X.X.X -v -u
# Be a GPL server for VROC too
/usr/sbin/ipmasqadm autofw -A -r udp 6971 6971 -h X.X.X.X -v -u
The GPL 1.1.0.0 patch is about to hit the streets. When it does,
replace the lines above with the following:
# Flush the ruleset
/usr/sbin/ipmasqadm autofw -F
# Be a GPL server
/usr/sbin/ipmasqadm autofw -A -r udp 32766 32786 -h X.X.X.X -v -u
# Be a GPL server for VROC too
/usr/sbin/ipmasqadm autofw -A -r udp 6970 6971 -h X.X.X.X -v -u
For all of the lines above, substitute your workstations IP internal
address wherever you see "X.X.X.X".
Please check John's Web page for more details and the latest
information: http://members.home.net/jms1/gplmultiplayer.html
Prior to John and Andrew's research, Eric Busch noted:
By default, a GPL server will listen for UDP connections on port
32766, though it opens a new socket with a host-assigned port number
over which it actually communicates with the client (this may hamper
what you're trying to do). You can change the listening port number by
placing a file named core.ini in the same directory as gpl.exe that
contains these two lines:
[ Communications ]
net_server_port = <whatever>
Or, you can define a service in the services file
(c:\windows\services, generally) as such:
papy_mpy_ip <whatever>/udp # Papyrus multiplayer games
I believe John and Andrew's suggestions supercede Eric's comments, but
I include these here anyway in case they might be of use to someone.
7.4 I'm running GPL on a Windows 95/98/NT machine on a LAN, using a
Windows 95/98/NT gateway machine running Sygate to allow access to the
Internet. How do I host/join races?
Using GPL 1.0, I believe it is possible to join races from behind a
Sygate gateway without making any changes to Sygate's configuration. I
don't believe it's possible to host using GPL 1.0 and Sygate.
GPL 1.1 (the patch) allows both hosting and joining races from behind
a
Sygate gateway. I have tested this on my LAN, using Sygate to provide
access to the Internet through a cable modem and MediaOne cable
service. The gateway machine has two Ethernet cards, one connected to
MediaOne's NetGear cable modem and the other to the LAN. Sygate is
installed only on the gateway machine.
If you have a similar configuration, you should be able to do the
same. First, disable DHCP in Sygate and manually assign each machine
its own IP address. I suggest you use addresses from the range
192.168.0.1 through 192.168.0.255. Reboot each machine after making
the address assignment.
Now you need to tell Sygate to allow connections through the ports
used
by GPL and to forward communications from the outside to the machine
which will be running GPL. To do this, add the appropriate rules to
the Apprule.cfg file (typically in
C:\Program Files\SyberGen\SyGate\Apprule.cfg) and restart the Sygate
service.
For example, to run GPL as a server on machine 192.168.0.14, I have
added the following lines:
# GPL Server definitions
# For running GPL on Local Machine 192.168.0.14
:INIT "GPL Client/Server connections"
IN UDP 32766 32766 192.168.0.14 0 0 -
:SUB
OUT UDP 32766 32786 0.0.0.0 0 0 -
IN UDP 32766 32786 0.0.0.0 0 0 -
:END
Substitute the IP address of the machine which will be running GPL on
your LAN for the address "192.169.0.14" in the lines above.
The following lines are not necessary but document the port on which
GPL will broadcast its status reports when requested to do so by VROC.
:INIT "GPL Server Status Broadcast"
OUT UDP 6970 6970 192.168.0.14 0 0 -
:SUB
:END
If you're not hosting via VROC/GPL Spy Boy, you may wish to add these
lines to enable requests for GPL status reports by a remote machine.
:INIT "GPL Server Status Report"
IN UDP 6971 6971 192.168.0.14 0 0 -
:SUB
OUT UDP 6971 6971 0.0.0.0 0 0 -
:END
If you will be hosting GPL on multiple machines behind the gateway,
use GPL Spy Boy's Server properties sheet or GPL's core.ini (see the
GPL 1.1 readme file) to assign a different port to each machine. For
example, to host on another machine on my LAN (say, 192.168.0.11), I
would specify to GPL on the second machine that it will listen for
clients on port 32787, and I'd add these lines to Sygate's
Apprule.cfg:
# GPL Server definitions
# For running GPL on Local Machine 192.168.0.11
:INIT "GPL Client/Server connections"
IN UDP 32787 32787 192.168.0.11 0 0 -:SUB
OUT UDP 32787 32807 0.0.0.0 0 0 -
IN UDP 32787 32807 0.0.0.0 0 0 -
:END
Note that you must leave 19 ports free between each GPL server's
client listening port (thus the gap between 32766 and 32787). GPL will
use these ports for communications with its clients.
10 Where can I learn more about the nitty gritty of racing GPL online?
Here are some other sources:
* The online section of my GPL Reader FAQ
* Michael Carver's comments on MTU/RWIN and related issues
* The VROC Technical Notes
* The VROC Tech Support Page
* Bart Westra's detailed analysis of online issues in GPL