This FAQ is aimed at answering questions that are asked about lag and netsplits as part of the Undernet User Committee's Document Project. If you have any queries or comments, please email documents@undernet.org. 

1. Lag
The first thing to look at is server structure. Consider a basic series of IRC servers:
A - B - C - D
This network is extremely basic. A large network such as the Undernet would look like the diagram below.

G H     I       J K - L   M    N
 \|     |      /   \      /    |
  A  -  B  -  C  -  D  - E  -  F
   \         / \    \           \
    O       P   Q    R           S - T
                |               /     \
                U              V       W

For the purposes of this explanation, however, we will remain with the original four servers in the series to make things easier. By looking at the diagram, we can see that for data to get anywhere there is only one route of travel. So if someone sends data from server A to server D, it can only go from A to B, to C, and then on to its destination at D. The point is that it has to travel and travel takes time. If there is a bad connection between B and C, it would slow the data down, and as a result, the whole journey would take longer.

Now, let's look at lag itself. Say you ping someone (/ctcp nickname PING) and it returns with the following:
[SweetNes PING reply]: 37 secs....
We would assume that SweetNes is lagging by 37 seconds; that is, it takes 37 seconds for data to reach SweetNes and return. Let's also assume that on a day where lag is particularly bad, the time difference between the servers may look like this:
A ------- B -------- C -------- D
9 sec 6 sec 10 sec
Since lag is only proportional, someone pinging someone on server D from server A would get a ping reply of 50 seconds. This is the total of all the time differences multiplied by 2. So it would take 50 seconds for data (the ping) sent to server D to reach its destination and return, and someone pinging someone on server B from server D would get a reply of 32 seconds. The point is that lag is proportional, and therefore no one really lags, except to each other.
Let's look at this in an example:
A ------- B -------- C -------- D
1 2 3 4
If we have one person on each of our servers, and you, on server A, ping them all, the ping replies would look like this:
[1 PING reply]: 0 seconds
[2 PING reply]: 18 seconds
[3 PING reply]: 30 seconds
[4 PING reply]: 50 seconds
This would all be concluded from the example set by the first diagram and its explanation therein.
So basically, the time-lag is caused simply by the fact that the communication lines are having to send information to several different places at once, sharing its lines over several connections/servers. Also, small imperfections on the line, like crackle or faintness on a telephone line, can cause bursts of information to lose data, requiring a repeat send.
This all slows down the transmission of information, and thus slows down the service to each of the other connections to the servers queued up waiting for their burst of information to be sent or be ready for receipt.

Go to Top 

 2. Netsplits

A netsplit occurs when two servers lose contact with each other. Usually the servers have a noticeable time difference between them, which grows to a point where they can't exchange data quickly enough, so the servers physically split. But other than that, very little happens. Using the 4 simple servers as an example, let's assume that servers A and B split.
A -------- B ------- C ------- D before
A --- --- B ------- C ------- D after

From the point of view of the people on servers B, C, and D, the people on server A have left IRC, and vice versa for the people on server A. A typical quit message during a netsplit will look something like this:
[18:40] *** Quits: WHIZZARD *netsplit
This illustrates that the 2 servers have split apart. But remember: it's all relative. To the rest of the network, it looks as if everyone on server A and server B have quit, and to those users on server A and server B everyone else has quit.
The IRC Operators (IRCops) whose function is to deal with routing and server administration will usually attempt to reconnect the server or servers to the other side of the network; that is, if the cause of the split has been solved or if it is worth making the reconnection. It may be that the lag times are so poor that it is not worth re-connecting until the problem is completely solved.
Many of the "lesser informed" users try to look for netsplits when they occur. They move to the side with the fewest people and join a channel, which is possibly empty on one side of the netsplit but very busy on the other. This way they think they automatically gain ops.
However, this is now impossible. They will be de-oped as soon as the servers rejoin.
When the servers do join after a split, the servers they connect to will not necessarily be the ones they were connected to before the split. Looking at the example again, they might now look like this:
B ---- C ---- D ---- A
Now all the tables are turned, because the people that were lagging to you are not any longer and vice versa. That's the nature of lag: sometimes it's bad, but usually you never have to worry about it.
On the Undernet for the most part, lag times are usually insignificant except when there are global problems such as routers crashing or segments of the Internet is experiencing problems which no one can do anything about.

Go to Top 

3. DCC (Direct Client To Client)

Since lag involves servers, to eliminate lag you must eliminate the server, and DCC does exactly that. When you start a DCC Chat session with someone, what happens is you send a bit of data to them saying you want to chat. The IRC clients select a port and deal with connecting, and all you have to do is acknowledge the DCC Chat request.
Then all the data during the conversation will be passed from client to client directly. Usually when you request a session, it takes time to set up, since the initial correspondence goes through the server. However once a DCC Chat session has been initiated, you can immediately see the benefits.
It is not very wise, however, to start up DCCs with people you don’t know. Most people will reject them, since on some clients they are hard to manage. When you send a file by DCC, it follows the same method as the above to reduce server workload and make the whole operation more efficient.