Re: [ntp:questions] Reg: NTP accuracy
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (linux newbie) writes: >HI, >Need following clarification. > >Our Application needs to have two individual hardware (with DSP processor) >to have same crystal clock freqency. Though individual boards are alike, due >to environmental factors there might be drift after long run. > >As the two boards are connected to local LAN through ethernet, we feel by >comparing time at regular intervals can determine any drift in clock. >(assuming one board as server and another as client). >We run 'ntpd' in server and ntpdate in the client and after every 5 seconds, >if we query the client (ntpdate -q) we find there is millisecond difference. >As both of them are connected through the same LAN and both are running the >same time( ofcourse same clock freq) we are suppose to get 'zero' time >difference. >Can anyone explain why there is millisecond delay and how to reduce it? 1 ms is a small number. Try waiting longer. ntpd tries to keep your local clock in sync with UTC. One of the important things it does is figure out how far off your local crystal is. Look in your drift file. If you run ntpd (rather than ntpdate) on the client side, it will also figure out the drift on that machine. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Reg: NTP accuracy
linux newbie wrote: > HI, > Need following clarification. > > Our Application needs to have two individual hardware (with DSP processor) > to have same crystal clock freqency. Though individual boards are alike, due > to environmental factors there might be drift after long run. This suggests that you need frequency synchronisation, not time-of-day synchronisation. Frequency synchronisation is used a lot in telecommunications networks (e.g. SDH/SONET). > As the two boards are connected to local LAN through ethernet, we feel by > comparing time at regular intervals can determine any drift in clock. > (assuming one board as server and another as client). As telecommunications networks evolve from TDM to packet, there is also an increased need to transport synchronisation information across packet networks. Work is ongoing in the IETF (e.g. TICTOC) and elsewhere (e.g. IEEE 1588). But before choosing a solution, you need to be clear on what problem you are trying to solve. Cheers, Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Reg: NTP accuracy
>>> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (linux newbie) writes: linux> We run 'ntpd' in server and ntpdate in the client and after every 5 linux> seconds, if we query the client (ntpdate -q) we find there is linux> millisecond difference. As both of them are connected through the linux> same LAN and both are running the same time( ofcourse same clock linux> freq) we are suppose to get 'zero' time difference. Run ntpd on both systems for a bit, then take a look. As others have said, you may be using the wrong tool for this job. If you want better sync, you may want to run a PPS signal to both boxes and let them each sync to that as well as to each other. H -- http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Reg: NTP accuracy
>>> In article <[EMAIL PROTECTED]>, Jan Ceuleers <[EMAIL PROTECTED]> writes: Jan> Work is ongoing in the IETF (e.g. TICTOC) and elsewhere (e.g. IEEE Jan> 1588). But before choosing a solution, you need to be clear on what Jan> problem you are trying to solve. I gather TICTOC is only a BOF at this time. And I have heard it is heavily slanted toward IEEE 1588 (and its problem/solution space), and I would love to know if folks who are familiar with NTP's problem/solution space are doing anything at the TICTOC BOF. H -- http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions