Hosting races

Basic networking

Firewall settings

The above ports are the base ports used by the game. If one or more of them are already used by another program (not very likely, but possible), the game will try the next higher port. It will continue doing so until it has searched through 100 ports for an unused port (a port not already bound by another program). When hosting a race all other applications should be turned off on the server to maximize its performance. It is therefore highly unlikely any of the base ports are already occupied, but it doesn’t hurt to open a few extra ports when you are messing with the firewall settings. On my own firewall I have opened the base port plus two more, giving me the following table:

• 34297-34299 / UDP
• 34397-34399 / UDP
• 34447-34449 / TCP

NAT routers

NAT is short for Network Address Translation, and it is usually used to allow many computers on a local network to share one IP address on an Internet connection. The easiest way to find out if you are behind a NAT router is to check the IP address of your computer. The easiest way to do this is to start the command prompt and type the command “ipconfig”.

If your IP address begins with “192.168.” or “10.” then you are without a doubt behind a NAT router. However, even if your IP address starts with some other number you could be behind a NAT router. A quick way to verify this is to use the ShieldsUP! service from Gibson Research. It is a network scanner that checks to see if your computer is properly protected against Internet intruders. This is useful to run even if you already know if your computer is behind a NAT router or not. Point your browser at http://grc.com/default.htm and scroll down until you find the “ShieldsUP!” link (under the “Hot Spots” heading). Follow that link and click on the “Test My Shields !” button. At the top of the page you will see the IP number that other computers on the Internet think you are using. If this number is different from the number you got from the command prompt above then you are behind a NAT router.

Advanced networking

Connection types

Bandwidth, latency and traffic interchanges

The best measure of the latency of your connection would be the round trip delay to the nearest major traffic interchange. A traffic interchange is a place where many different Internet providers and backbone operators have equipment to route traffic between their networks and the rest of the world. Unless most of your players use the same Internet provider as you, the traffic interchange is where the bulk of your bandwidth will be coming from and going to. If your Internet provider is connected to a big traffic interchange, and has good agreements with other local providers and major backbone operators, chances are good that most users will experience very low latency to your server. However, if your Internet provider has an overloaded network, or if it does not have good traffic interchange with others then users will experience high latency and lots of packet loss (resulting in even more lag). Unfortunately the only way to find out how good an Internet provider is when it comes to traffic interchange is to try it out (or ask an unbiased user).

Hosting full grid races (22 cars) requires about 1.5Mbit of bandwidth both upstream and downstream if you want smooth movements of the cars. Having more than 1.5Mbit is of course nice, but in most cases you will not be able to take advantage of the additional bandwidth unless all your drivers have VERY good connections (512/512 DSL or better). For serious racing it is more important with low latency and good connections to all the drivers, than it is with high bandwidth. If you have a choice between a very low latency 2Mbit connection and a 10 or 100Mbit connection with 20ms more latency and higher rate of packet loss, then the 2Mbit connection would be the best choice for online gaming.

Measuring your network connection

Measuring basics

Unfortunately I cannot provide any information on how to find suitable measuring servers for any other country than Sweden. In Sweden the largest traffic interchange is located in Stockholm, and there is even dedicated test servers located at or very close to the interchange. This makes it trivial to get good measurements.

[add blurb about TPTest and Swedish providers]

In other countries a good strategy would be to test many different speed measurement services (that is not operated by your own Internet provider). When you run tests against test-servers in your own country you will hopefully get pretty similar results regardless of the server used. Use Google or some other search engine to locate speed tests. A large collection of online speed tests can be found here: http://home.cfl.rr.com/eaa/Bandwidth.htm

Upstream vs. downstream

The speed that your Internet provider puts in advertisements and flyers is in most cases the downstream speed (because it is the higher number, and the number that is most important to the majority of Internet users). However, when hosting online game servers it is very important to have good upstream speed. You should therefore ask your provider for information about your upstream speed.

Real-world values

Also, when running speed measurements, make sure you run a few of them to different testing servers outside your own network. Some of the testing servers are overloaded; others might be located on badly connected networks. If you only measure your bandwidth against one server you run the risk of getting a much lower value than you really should have, and if you use that value later on in the PLR file you will be limiting the potential of your server. It is quite safe to test your speed against as many servers as you want, and then assume that the number you are looking for is the highest one achieved during all the tests.

Tuning your server

Server FPS

The only way to “fix” this is to turn down your graphical details on the server so that it never drops below 30FPS even during the start. However, many server operators will notice that even when they turn down the graphical details a LOT, the FPS drop is still significant during the start. A possible solution to this is to limit the number of visible cars on the server. By reducing the number of visible cars from 18 (default) to 8, I went from 36 FPS from the back of the grid to 44 FPS. No other settings changed, and from a racing perspective you will be quite busy keeping track of the 8 cars that are closest to you. Most people will never even notice that there are 10 cars that they cannot see.

The setting in the PLR file looks like this:
Max Visible Vehicles="8"

More PLR tuning

Net Data Rate
This is the data rate (frequency of car position updates) that the client will request to use when connecting to the server. Each client can request an individual data rate from the server as long as the rate is lower than the max data rate (see below). Through testing I have found that a data rate of 14 works very well for my server and the clients that connect to it (all which have 128kbit connections or better).

Net Data Rate Max
This is the maximum data rate allowed by the server. If a client requests a data rate higher than this it will not be allowed, and this value will be used instead. A too high value here might allow a single client to use up much of the available bandwidth. Because I have found a data rate of 14 to work well (smooth car movements without too much bandwidth usage), that is the value I use on my server.

Throttling
The default value is “1” which means the new netcode bandwidth optimization algorithm is being used. Leave this on!

Throttle Upstream Override
The default value is “-1” which means it will use the default setting associated with the selected Net Connection Type. This is probably the most important value to get right when optimizing your network settings. The value is in kilobits per second, so if your measurement result (above) is of any other type you will have to convert it into kilobits per second. I have suggested to everyone that has asked to use the real-world value and subtract 5-10% from it. I suggest this because I suspect packet loss might occur if the connection is fully saturated. Also, it is not uncommon for the maximum available bandwidth to fluctuate a little, so a 5-10% safety margin might be a good idea. I do not have any facts to support my suggestion other than common sense. The fact is that the network code might already have a safety margin built-in, in which case this would be redundant. I am waiting for an answer from ISI on this issue (and a few other issues). It is important to never use a value higher than the real-world value achieved when testing the connection. For example, if your testing shows that you have 240 kilobit per second in upstream bandwidth you should use a Throttle Upstream Override value of “240” or lower. I would suggest using “225” or “230”, as that would leave a ~5% safety margin. On my own server I use a value of “1800” for a connection with a real-world speed of 1900 kilobits per second upstream.

Collision Threshold
This value decides how much latency there must be between two cars before they cannot collide with each other anymore. The default value is “0.30000” which means that when the latency between car A and B is more than 0.3 seconds, they will no longer be able to collide even if they occupy the same space on the track. They become sort of ghost cars. As a server it is important to make sure this value is forced onto all the clients (see Force Physics below), otherwise a client can set this threshold very low and never have to worry about other cars. It is also important to understand the nature of the latency. All drivers are connected directly to the server, and have no direct connections with each other. So the latency between two cars is the sum of the latency for each of those cars to the server. So even if the server never sees any ghost cars it does not mean there are no ghost cars on the track. What cars are uncollidable is determined by the individual clients, based on their latency to the cars and the value of this setting. For example, two neighbors in Australia playing on my server in Sweden will most likely not be able to collide with each other because each of them has 200-250ms latency to the server, for a total of 400-500ms latency between each other. That is well above the 300ms default value.

Half Rate
This setting determines the sampling rate of the physics engine in F1 Challenge. The default value is “1”, which means half rate physics is enabled. By changing the value to “0” the frequency of physics engine calculations are doubled. Using full rate physics does eat some additional CPU power, so it might impact clients with slow computers. The car handling is also slightly different (more realistic according to most people), so it is wise to ensure this setting is the same for all drivers (see Force Physics below).

Force Physics
This setting is often misunderstood. This value determines which of 5 possible settings on the server will be forced onto every client that connects. The server still needs to set all those 5 values to whatever is suitable. So for example if the server would like to force all the clients to use a collision threshold of 400ms and full rate physics, then the server would have to first set Half Rate to “0” and Collision Threshold to “0.40000”, and then set Force Physics to “20”.

Tuning your client

[add more text here]