View Issue Details

IDProjectCategoryView StatusLast Update
0002863unrealircdpublic2006-05-20 19:41
Reportersyzop Assigned Tosyzop  
Status resolvedResolutionfixed 
Product Version3.2.4 
Fixed in Version3.2.5 
Summary0002863: Weird buildin-IRCd time synching idea
DescriptionOk, this is a weird idea...
I see so many people having their clock way off, now we could either just say "admins should get their clock right" (which is a very respectable point).. But another alternative would be to do something about it (less respectable, I agree).

My idea would be an automatic-clock-synch thing on-startup that will adjust TSOffset accordingly. I suggest to use the most simplest time synching protocol there is, such as RFC868 (think: 'rdate') via TCP, since anything else would be "too advanced".
We should also not block too long, say, only a 5 seconds timeout, too bad if synching fails.. just warn that we could not reach the time server and let the ircd boot.

This feature would be enabled by default, would not be in a module, and would be possible to set off via - for example - set::synch-time no.
Why? Because we want - at least! - all idiots to have it enabled by default.

NOTE: We only need time in semi-second precision, not millisec or nanosec, so ntp is not really needed.

NOTE2: Even for the medium sized (~1-2K) networks this would still be useful, since aparently even them have problems with having their time synched. OR in any case, it's just much more convenient for everyone.
TagsNo tags attached.
3rd party modules


related to 0002919 closedsyzop Extend time synchronization: daily synch 
child of 0002748 closedsyzop 3.2.5 Release 



2006-03-23 16:16

reporter   ~0011426

I have to agree this would be useful. There are quite a significant number of people (too many imo :( ) that run ircds on shells where they don't have root and thus can't synch the system clocks. Ideally, shell servers would have some kind of ntpd running but you can't always be sure, now can you? The alternate solution of such service modules as os_tssync (of which I still have yet to find the unrealircd version) and manual /tsctl to adjust the TSOffset (which might be needed once or many times depending on how clocks drift) introduce the "freeze" issue usually associated with ircd time travel :) .

One question though: one-shot synch at boot (which still leaves drifting clocks SOL), or constant synchronizing as the ircd runs (once every 10 minutes is probably more than good enough to keep any clock in line).


2006-03-23 18:40

reporter   ~0011429

I think it should be more configurable. I also think it should support ntp, and convert whatever ntp returns to seconds as needed. This would allow people to use popular time servers. A whole block dedicated to time synch:

tsynch {
  synch-time <yes/no>;
  timeserver <server>; [optional]
  timeout <seconds>; [required]
  interval <minutes>; [optional]

If there is an interval specified, Unreal should synch the time at that interval, if not specified, just once on boot.


2006-04-09 08:09

reporter   ~0011490

This would be really a nice addition. As aquanight already pointed out the ntpd stuff can be complicated on shells and virtual root servers.
We currently use the os_tssync for Anope which works pretty well. You can find it for Unreal on

As not the absolute time but the relative time between servers is important another idea might be to add a "master time server" to the config and all leafs/hub sync their internal clock to this master server from the own network.




2006-04-09 23:58

reporter   ~0011505

Monk: good idea @ master time server
Bugz: i like that line of thinking
aquanight: NeoStats does this automatically (the TSCTL) (Unreal supported too!)

syzop: great idea. i for one would support having a time server capability in Unreal. (could this cause problems at Windows?)


2006-04-10 11:39

reporter   ~0011516

i really like this idea, but i think that NTP support is a must


2006-04-10 12:17

reporter   ~0011517

NTP isn't the only time-synching protocol. I can agree it's good if you need to-the-nanosec accuracy, but in the ircd world, everything's in seconds and that's all that matters. At the very least you only need to be accurate within ~ .1 sec, and for that low precision, NTP is overkill. When only seconds matter, a difference of ±100ms isn't going to make your glines expire 30 minutes ahead of schedule, or make channels disappear off the network, or any of the nasty things that normally take a ±30second difference to happen.

And really, I have to wonder how WOULD the ircd store that .X second offset - TSoffset is an int, not a double ;) .


2006-04-10 14:05

reporter   ~0011523

that wasn't my point, it NEEDS to support NTP or it won't be used much, i didn't say it needed to be dead acurate, i'm just saying if u want it to be used, your gonna need ntp support, because its the most common time sync protocol


2006-04-10 14:40

administrator   ~0011525

We are not going to use NTP since it's not doable (it's crazy to implement that, unless that can be written in <50 lines within a few hours.. when looking at the RFC it looks far too advanced), and indeed we do not need it for accuracy (glad some people understand and have some perspective ;p).

I'm also going to make the initial version as simple as possible, and then maybe it can be enhanced later on ;p

I intend to simply use by default, or a SMALL list of known reliable servers (hint: it's better to have 3 reliable ones than to have 10 of which 3 are unreliable), I will of course investigate this...

So, I guess this means: don't get too excited ;p, we will get an initial version that will only synch on boot, and then we'll see what happens after that.. (indeed.. drafting clocks are a problem if you only do this at boot, but on the other hand synching the time while running and doing all kinds of work between send and receive of timestamp can cause incorrect time by a few seconds, though we could stall the entire ircd for max 2 seconds and wait for a response or something [we cannot stall longer, that's for sure])

Basically, my primary objective is to at least get rid of those huge incorrect timestamps at first, we'll see after that.


2006-05-20 19:41

administrator   ~0011743

Time synch support added.

NTP ended up easier than I thought, or actually technically we are using SNTP (Simple Network Time Protocol) now. Anyway, it can deal with NTP servers :P.

I'm closing this main bugid since it's now implemented, would have to create a new bugid for like every-24h-timesynch support which would be in 3.2.6.

- Added MINIMAL time synchronization support. This is enabled by default and will try to
  synchronize the IRCd clock (TSOffset) with a few good time servers. It currently only does
  this on-boot, but it will hopefully help a lot of people with most of their time differences.
  I still keep recommending anyone who can to run proper time-synchronization software such as
  ntpd/ntpdate on their servers.
  To disable time synchronization (eg: because you are already running ntp), you can simply
  set set::timesynch::enabled to no.
  The boot timeout for the timeserver response (=causes boot delay) can be configured via
  set::timesynch::timeout and is set to 3 seconds by default (range is 1s-5s), there should
  be no reason to change this.
  The time server can be configured by setting set::timesynch::server, the default is to
  use 3 time servers on 3 continents (US, EU, AU) which should be sufficient for anyone but
  if you got a good one near you you can use that one instead.
  The time protocol we use is (S)NTP v4.

Issue History

Date Modified Username Field Change
2006-03-23 15:24 syzop New Issue
2006-03-23 16:16 aquanight Note Added: 0011426
2006-03-23 18:40 Stealth Note Added: 0011429
2006-04-02 16:51 syzop Relationship added child of 0002748
2006-04-09 08:09 Monk Note Added: 0011490
2006-04-09 23:58 Zell Note Added: 0011505
2006-04-10 11:39 djGrrr Note Added: 0011516
2006-04-10 12:17 aquanight Note Added: 0011517
2006-04-10 14:05 djGrrr Note Added: 0011523
2006-04-10 14:40 syzop Note Added: 0011525
2006-05-20 19:41 syzop Status new => resolved
2006-05-20 19:41 syzop Fixed in Version => 3.2.5
2006-05-20 19:41 syzop Resolution open => fixed
2006-05-20 19:41 syzop Assigned To => syzop
2006-05-20 19:41 syzop Note Added: 0011743
2006-05-20 19:45 syzop Relationship added related to 0002919