@Chris I appreciate the offer to help.
I've been thinking about this problem a while and here are my thoughts... It seems to me that ntpd has the goal of keeping extremely accurate time - which is important for many obvious reasons. However there are those of us that don't need time accurate to the millisecond and / or don't need time to be perfectly in sync with the rest of the world. With that in mind, it would be nice if there was something out there that operated in a slightly different mode than ntpd does... It appears that the problem that ntpd has is that because the distance between ticks on the local machine are variable and therefore calculating the time between a transmission and receipt is 'impossible'. But why not have something that assumes that the local ticks simply can't be trusted? Keep track of how far off the local clock is from the ntp sources (averaged over numerous queries) and adjust the clock based on the average adjustment that is needed. Don't mess with trying to calculate the time taken for the round trip and all that, if the replies back from servers are within a certain amount of time of one another, then just average them out. If you do something similar to what I suggest, you will end up running further 'behind' than a ntpd server that has consistent ticks, but you ought to at least be able to have something that disciplines the clock into running fairly close to real time on average and stays within a handful of seconds within 'real' time. As I said, this probably is a completely different solution than ntpd, but it seems like it would be really useful for people that are more concerned with making time consistent / realistic than they are with making it ultra-accurate. And this could also be very useful for people that have hardware clocks that don't seem to run consistently enough for ntpd - the people whom I've seen been told to replace their motherboard in order to get a clock that can keep time. I'm no time expert, so feel free to explain where I've lost my mind if I'm not thinking through this all the way... _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions