View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002863 | unreal | ircd | public | 2006-03-23 15:24 | 2006-05-20 19:41 |
| Reporter | syzop | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Platform | ALL | OS | ALL | OS Version | ALL |
| Product Version | 3.2.4 | ||||
| Fixed in Version | 3.2.5 | ||||
| Summary | 0002863: Weird buildin-IRCd time synching idea | ||||
| Description | Ok, 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. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
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). |
|
|
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. |
|
|
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 http://www.nomadinc.net/mymods/mods.html 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. Regards, Monk |
|
|
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?) |
|
|
i really like this idea, but i think that NTP support is a must |
|
|
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 ;) . |
|
|
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 |
|
|
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 time.nist.gov 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. |
|
|
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. Changelog: - 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. |
| 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 |
