[IRC-DEV] RV: [Undernet-Admins] Time

[NiKoLaS]

Hola,

  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í.

  Un saludo,

NiKoLaS

-----Mensaje original-----
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
easily.

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 
certainly wrong.

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
wrong.

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
this.

 >>> 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.