tcbw.net

In for the long haul

User Tools

Site Tools


ta:lag

Defining the term lag

Usually the term lag is used to describe all kinds of problems that may occur during an online multiplayer game. The original meaning of the term comes from the fact that network packets need time to travel from the sending computer to the receiving computer. Depending on the length of the route between the two endpoints and the connection speed between the so called hops along the route, the time needed to transfer a particular packet may be short or long. The more time a packet needs to to travel along a particular route the more lagged the route. So the term lag just decribes the time delay information needs to get from point A to B. Lag is often confused with the term packet loss, which means a network packet gets lost somewhere on the route between point A and B. While lag may have a negative impact on online gaming packet loss is worse. Lag means vital information may be delayed, packet loss means the information will never make it to the other endpoint without retransmission.

For example, lag causes the last damage information for a near dead TA unit to be applied much later on the remote computer. Imagine that you have a flash tank down to the last red health tick at computer B and a missle tower at computer A just fired a missle that would cause the flash tank to die. The damage information of this missle takes a while to travel along the route betwen system A and B, lets say like 600 milliseconds. Within the 600 milliseconds before the final damage information arrives at the computer B, the flash unit will keep sending its own damage information to computer A. While the flash should be already dead from the view point of system A, it still keeps dealing out damage until the final damage information arrives at system B and gets applied to the flash, causing it to die. In this case, an acknowledgement of the death of the unit is required to make the unit disappear from the game being proessed on system A, the time needed to send the acknowledgment information back from system B to A counts too. In such a scenario the unit would be out of the game on system B while it still deals out damage on system A. I don't know how this is implemented in TA, but in general it's easy to understand that the following factors determine how things can get worse:

  • Time needed to transport a network packet between system A and system B.
  • Fire rate of the unit's weapon while waiting for the final damage information.

A pretty good example of lag in TA is when you have 20 units at their last health tick, bypassing all of your defenses and see them die without being under fire 10 or 20 seconds later. Knowing these facts, you will agree that losing damage information due to packet loss along the route is even worse. TA is probably using some kind of acknowledgement mechanism for damage information, otherwise your units would just stop firing at a unit at the last health tick after sending the last damage data which would kill the unit. The problem is, the more often your system has to resend damage information because of lost packets, the longer the enemy unit survives and the longer it keeps sending its own 'deal out damage' requests.

Lag caused by network route issues

To complicate things even more. TA is a peer to peer game. So, if you entered a four player game, you have to have three good network routes - one to each player. The problems described so far explain why playing TA in a Local Area Network (LAN) differs so much from playing it on the Internet. The routes on the Internet are just longer and its more likely to lose network packets along a particular route.

The false 'I have cable thus can't lag' assumption

I'll take this opportunity to clear up another common misunderstanding. Cable modem or DSL does not guarantee a connection free of lag or packet loss. I like to compare the journey of a network packet along the route to its destination with a ride you take in your car: cable modem or DSL is like having a one mile wide driveway in front of your house. This will make pretty sure you have no problems to get on the road with your car. It doesn't save you from getting stuck in that small, one lane wide street beyond the next crossroad, though. In other words, cable modem and DSL should ensure the connection between you and your ISP is fast, but it has no impact to the route beyond the connection point of your ISP.

The difference between steady and fast connections

Besides problems on the route beyond the connection point to your ISP, your cable or DSL connection may not work properly. Some cable companies keep putting more and more subscribers on the same shared cable segment instead of adding a new segment (read: investing money in expensive hardware upgrades) as needed. Cable on an overloaded segment may still show the expected performance when it comes to overall data transfer rates. When you download a 100 MB file, it makes no difference if the transfer stops completely every 5 seconds for like 2 seconds as long as the transfer speed is high during the 5 second working interval. You will still get the file downloaded pretty fast. Now, in contrast to downloading a file, in an online game like TA you need a connection providing a steady and stable data stream. If 50 units clash together and your cable just falls into that 2 second hiccup gap your units will keep dealing out damage at your opponent's units while being invulnerable for 2 seconds.

In contrast to cable, DSL implements a steady stream at the hardware protocol level (there is no such thing as a retransmit of a network packet due to a collision with other packets like on a cable segment since the copper wire is not shared with other subscribers) but this raises other issues: DSL uses the previously installed, copper phone wire to connect the customers' DSL modem to the DSL endpoint at the ISP. DSL uses a technique squeezing the the maximum possible bandwidth out of those old, rotten copper wires, pushing things close to the physical limits of the wire. As far I can tell from my own DSL experiences and the problems I had during the first subscription year, DSL either works or does not. There is no such thing as hidden hiccups such as those with cable which may make it much harder to figure out if you have a connection problem. If you have cable or DSL, you should test for stability of the link between you and your ISP by doing a trace route to a close site over a few minutes. If the trace route shows too many failures, you should call your provider and make them fix it or you won't have much fun with your jerky 'high bandwidth' connection when it comes to playing online games.

Lag caused by CPU overload

Beside the network route quality, there is another factor to consider: your computer's CPU, its system settings, and the type of device used to connect to your ISP. A slow CPU will result in the situation where your computer will not be able to keep up with the incoming information from the other players' computers. The higher you set the resolution for the TA main screen, the more units and effects have to be displayed at once. TA doesn't support 3D cards so it's all up to your poor CPU to provide the animation. The best thing to do is to switch off all eye candy effects like shadows in the TA visual settings in order to keep the workload of the CPU as low as possible. Think about reducing the resolution for the in game main screen, too.

Possible impact of MTU size on CPU workload

Last, but not least, the setting for the Maximum Transmission Unit (MTU) size advertised to the Internet Protocol (IP) layer affects the amount of time your CPU (and the CPUs on the remote computer(s)) may have to spend to process the network traffic. IP packets can be broken into smaller parts by any hop (any node involved into transporting IP packets along a route) when the advertised MTU size of the following hop is smaller than the current IP packet size. This process is called IP fragmentation and usually only occurs when there is a transition from a hardware layer infrastructure with a larger MTU size to another one with a smaller MTU size.

Superfluous IP packet fragmentation may occur on the sending computer already when the Internet is accessed via an analog modem: In this case the MTU size is not determined by the underlying hardware protocol (Ethernet, FDDI, Token Ring etc.) but configurable in the modem driver. The driver usually offers the options small, medium and large. After installing the modem driver it often defaults to the small MTU setting thus, compared to the MTU sizes used by the following hops on the route, it's way smaller advertised to the IP protocol layer. The consequence is that the sending computer already creates IP fragments because the packets TA sends are normally larger than the small MTU size. Using the large option in the modem driver which is closer to nowadays avarage hardware layer MTU size (standard Ethernet uses a MTU of 1500 bytes) will avoid the unnecessary fragmentation of the IP packets.

If broadband devices like cable or DSL modems are integrated into the LAN by using them as a router in the LAN network - in other words by assigning them an own LAN IP address and using this address for the gateway option in the TCP settings of the LAN computers - then you don't need to worry about the MTU size used on the sending computer: It will just put the TA packets on the interface of the installed network card, which should be a Ethernet interface with a sufficient MTU size of at least 1500 bytes. From there the packet will travel to the broadband router's inner LAN interface which will also work with the Ethernet specifications so the MTU sizes between the network card on the sending computer and the router don't differ at all, thus the IP packet won't be split into smaller parts.

Older broadband solutions may require to connect the modem to a single computer by using a USB connection or network card. The broadband modem is then directly connected to that specific computer rather than to a network hub. The consequence is, device drivers need to be installed on that computer and those drivers will usually cause a 'virtual' network card interface appear on the computer. This virtual network interface then works with the Internet IP assigned by your ISP rather than having two IP addresses (an inner LAN IP address and an outer IP address assigned by the ISP) as in the router solution for newer broadband routers described above. Actually this approach is pretty much similar to the way an analog modem is integrated into a computer. If the broadband modem comes with a 10Base-T connector then you'll need to install a real network card and that virtual interface isn't all that virtual anymore. On the other hand, if the broadband modem comes with an USB connector then things look quite different because the device driver will just act as if there was a real network card behind it while data between the computer and the modem is actually exchanged via the USB bus. With virtual interfaces there may always by the possibility to set MTU sizes in their driver options so I suggest you check that with your ISP and set it, if required, to something close to the standard Ethernet MTU size.

Why is IP fragmentation a problem at all? Well, the network interface on the sending computer has to spend CPU time to break the IP packet into smaller IP packets so they fit into the MTU and the receiving computer has to spend CPU time to reassemble the fragments. The reassembling process itself can get very time consuming since the IP protocoll doesn't guarantee that fragments arrive in the same order as they have been sent. If an IP packet has been split into five parts then the IP network interface on the receiving computer can't forward the original IP packet to the higer protocol layers as TCP and UDP until all five fragments arrived so the orignal IP packet can be restored. The IP protocol layer on the receiving computer (and depending on their configuration settings maybe even on routers along that specific Internet network route) won't wait forever for all IP fragments belonging to the same originally unsplit IP packet to arrive. After a certain timeout elapsed the receiver will just discard any fragments of a still incomplete IP packet he received so far an will give up on the packet. If the original IP packet was part of an TCP segment the whole TCP segment will be retransmitted by the sending computer after the TCP segement acknowledgement timeout in the TCP protocol layer elapsed. If the IP fragment was part of an UDP packet the whole UDP packet data gets lost since the UDP protocol implements no checks for failed transmissions of packets for whatsoever It's no suprise some firewall systems offer an option to reject fragmented IP packets because they are considered as an attack attempt when encountered in huge numbers, with the goal to slow your CPU down to the point it actually spends most of the time processing fragmented IP packets. No matter what kind of link type you are using you should check for fragmentation of outgoing IP packets to make sure everything is configured correctly.

How to check for IP fragmentation

The netstat -t -p ip command issued in Command Prompt window works with all Windows operating system versions starting with with Windows9x. The output looks like this:

D:\>netstat -s -p ip

IP Statistics

  Packets Received                   = 4073
  Received Header Errors             = 0
  Received Address Errors            = 0
  Datagrams Forwarded                = 0
  Unknown Protocols Received         = 0
  Received Packets Discarded         = 0
  Received Packets Delivered         = 4073
  Output Requests                    = 3611
  Routing Discards                   = 0
  Discarded Output Packets           = 0
  Output Packet No Route             = 0
  Reassembly Required                = 0
  Reassembly Successful              = 0
  Reassembly Failures                = 0
  Datagrams Successfully Fragmented  = 0
  Datagrams Failing Fragmentation    = 0
  Fragments Created                  = 0

D:\>

The interesting lines are Reassembly Required and Datagrams Successfully Fragmented. The first one indicates the number of IP packet fragments which arrived at your system and your network interface had to reassembele before the contents could be processed by higher protocol levels (like TCP and UDP). The latter shows how many IP packets have been fragmented by your network interface before they were put on the link. If you have a value not equal to zero here you better check your network interface settings and look for an option to increase the IP packet size. If you check the IP statistics after a TA game as described above and notice the number of Reassembly Required has quite increased during the game then there are two possible reasons for this:

  • The packets have been split on one of the computers involved into the game. Talk to the other players after the game and let them check their device settings for IP packet size which is set too small.
  • One of the hops on one of the routes for the systems involved in the game has fragmented the IP packets. In this case it would be difficult to figure out on which route and which hop the fragmentation actully happened. Even if you are able to break it down to a single hop you can't do much about that, since the hop is under control of an ISP or carrier. In other words: You have to live with the fact that playing TA by using this route is not optimal - at least at this point in time. Since the route is usally determined by the people you play, you can either avoid playing them or you can try to use another ISP which usually results in a different route between you and the other player - a route which is hopefully performing better. The problem may be just a temporary one, too. For example a failing router which is being replaced the next day.

To get back to the original topic the CPU being a possible bottleneck: The more CPU time that is spent displaying graphic effects and processing network data at operating system level (IP fragmentation) the less CPU time is available to process the actual game like picking damage data out of the queue of incoming network packets and applying them or sending acknowledgement packets back. The effects of such an overworked CPU are similar to network route lag, everything will get processed with delay.

Conclusions

Although lag, packet loss and the CPU issues described above are different things I'll just use the term lag from now since this is normally the way it's done in the TA community. Lag, even mildly, can put you back, especially early in the game when defenses are still weak and you have to deal with raiding units. In such a situation every lost or delayed damage packet counts. Whether you loose another metal extraxtor to a raiding unit or not may depend on a single network packet. I came to the conclusion that it's not worth the time trying to assess a severly lagged game. To debate about such a game in the chat room after it has ended is pointless because the players actually played two completely different games from their point of view. The cross computer game data was just inconsistent during the game. In my opinion, lag is not so much of a problem if you play someone below your own skill level. You are usually able to compensate for lag effects by producing more units than normally needed to defeat theirs. If skill levels of the players are equal, lag will have a major impact on the game.

ta/lag.txt · Last modified: UTC 2014-10-03 20:00 by tcbw