[IRC-DEV] RV: [Undernet-Admins] Time
nikolas at undernet.org
Tue Apr 27 07:52:52 CEST 2004
Curiosamente, el tema del SETTIME también ha estado hablandose
en la lista de admins de Undernet, e Isomer ha enviado un mail muy
muy interesante sobre el tema. Creo que merece la pena que se conozca
asi que me ha dado permiso para reenviarlo aquí.
De: owner-undernet-admins at undernet.org
[mailto:owner-undernet-admins at undernet.org] En nombre de Perry Lorier
Enviado el: martes, 27 de abril de 2004 4:25
Para: undernet-admins at undernet.org
Asunto: [Undernet-Admins] Time
Time on Undernet is one of those issues that requires a philosophy
degree to understand, so I'm going to try and explain it nice and
The first, most important thing is that undernet has the wrong time.
It's true. Undernet has it's own concept of time, and it's almost
The second thing to note, is that mIRC lies. if you do /time the server
sends something like:
:Amsterdam2.NL.EU.undernet.org 391 Remosi Amsterdam2.NL.EU.undernet.org
1083028737 81 :Tuesday April 27 2004 -- 03:17 +02:00
However mIRC will show this as
*** Tuesday April 27 2004 -- 03:17 +02:00
missing the very important 1083028737 81.
The first number is "undernet time", and is in theory number of seconds
past 1970-01-01. When doing a /time on a remote server, *THIS* is the
important number and the one that MUST be the same on all servers.
Remember, mIRC hides this number from you! I don't know why.
The second number is how much this server thinks undernet's clock is off
(the offset). It varies from server to server. So amsterdam2 thinks
that Undernet's clock is 81 seconds off. This is why I made my earlier
statement of "Undernet's time is wrong", if you do some queries around
undernet, you'll see that most servers have an offset, and some of those
offsets are huge (over 5 minutes!). The time displayed in "human
readable" format is the system time of the machine, and can be wrong
with no ill effects, so long as the "offset" accounts for it.
ircu keeps track of that offset, and applies it as a correction to what
the servers clock is. When a server links, it sends a "SETTIME" message
which updates this offset, so that all servers connected to the network
should all agree on "Undernet Time" (even if the servers don't agree on
what the "real" time is).
Make sense so far? No? Tough. It gets worse from here on in. Skip
until "HERE" if you want.
Now, if a server runs ntpd then it's clock should be correct right? So
if this is true, it should always ignore SETTIME's and issue it's own
ones, and it's offset should always be 0. This is called
"RELIABLE_CLOCK", and according to the CFV, it should be set by hubs.
This is so that a server with a broken clock will have it's hub tell it
that it's wrong and won't "infect" other servers with it's mistake.
If you have two servers that have the wrong "Undernet Time" (say ServerA
and ServerB) then one of them will be fast with respect to the other
(say ServerA is 70 seconds fast compared to ServerB). ServerB will get
messages (like nick change and channel create messages) that as far as
it knows are 70 seconds in the future. ServerB then sends a SETTIME
back to ServerA to hopefully fix the clock. These are the snotices that
you see. Theses snotices can arrive several thousand times a second
(esp during a burst), so ircu only sends one of these messages every 30s
to avoid flooding opers off. If serverB detects a clock is off by far
too much (20 minutes?), it *WILL* squit the server as being horribly
There's a fly in the ointment. Standard PC hardware has stupidly bad
time keeping. They vary their speed based on temperature, and some of
them are just bad and go fast (or slow) all the time. ircu can't deal
with a clock who's not wrong by a fixed amount, but changes how much
it's wrong regularly. So a CFV was passed and all servers now must run
NTP. The idea here is that NTP keeps the server from drifting. as an
aside, ntp will also keep it's clock correct, but ircu doesn't require
>>> HERE <<<
Right, so brief summary. Undernet has it's own time. A host can have
the wrong time, ircu will deal. ircu can't deal with a host who's time
is changing (ie, it's clock is drifting/skewing), but thats ok; NTP will
handle this. ircu will try and deal with a server that has the wrong
time automatically. ircu cannot correct the time of a server that has
"reliable_clock" set. mIRC is lying to you.
More information about the IRC-Dev