[olug] Time

[PS]

Daniel Linder wrote:

>
>patricks at digitalrom.com (PS) wrote:
>  
>
>>|Also,  you mentioned not
>>|to use 1st tier ntp servers, why not? Just learning.
>>    
>>
>
>To which, Brian Wiese replied:
>[snip]
>  
>
>>With network latency over the internet, and going by atomic time, you
>>might only be off by a fraction of a second to the atomic clocks.  Not
>>really a big deal for me. =)
>>    
>>
>
>If I remember the NTP RFC correctly, the NTP protocol will do some
>computational magic and achieve a highly accurate "skew" for each server
>your system contacts.  Thus, if you server at work uses NTP to
>clock.redhat.com and clock2.redhat.com with a network round-trip-time
>(rtt) of 1.1ms, it knows that it will have to adjust the time it is told
>by these servers by 1.1ms.  Similarialy if your home system is connected
>via a PPP connection and the rtt to these servers is 23.4ms it will adjust
>your home clock by 23.4ms.
>
>NTP will "just work" (tm) as long as it can get packets to/from the clock
>server(s).  For the vast marjoity of us mere mortals doing things on a
>crude level of 1/100th of a second resolution, NTP is way more accuracy
>than required.  If you are using NTP to keep clocks synchronized in a
>fusion reactor, then you might want to "tweak" it a bit... :)
>
>  
>
What we are trying to do is use ntpd to actually dial out to a time 
server using the ntpd modem clock driver.  This part we have working, 
what we can't seem to get is to have ntpd update the local clock based 
on the time it receives from the server it dialed into.  The ntpd modem 
clock driver dials into a time server in Colorado. 
We have been at this for several weeks and we might have to throw in the 
towel and have by some software and have a M$ box  do this. Urgh!
Thanks for your time,
(no pun intended... ;) )
Patrick