Re: NTP daemon - fixed offset against real time

On 26 Led, 23:16, Unruh <unruh-s...@xxxxxxxxxxxxxx> wrote:
David Woolley <da...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
msm...@xxxxxxxxx wrote:

i would like to ask you for help or ideas with one ntp related task.
I need to setup one ntp server to serve its sntp clients
with time, which is specific amount of time (several seconds) in
You would need to modify the source code to do that. If you do so,
please also overwrite the stratum, reported to clients, with 15, so that
if anyone else does try to use you as a server, they won't be able to
further distribute broken time. (It may also be possible to set a silly
root dispersion, if the SNTP clients are not too fussy about it, to
completely stop NTP clients using the server adding your time offset to
root dispersion would be reasonably honest, as long as it is more then
one second.)

I would think it would be both easier and much less prone to introducing
bugs if theprogram running TV stuff added on the offset. Come two years
from now you will forget that the time on the machines is munged time, and
use it as real time.

\on \Linux you could probably define a special timezone which was x seconds
off UTC.
The refclocks off course have the offset option on some of them-- I do not
think it limits you as to how big that could be-- ie get a GPS source, use
the NMEA as a clock, and put in the appropriate offset.

advance against correct real time taken from another ntp server in
network. I did some search in documentation from both ntpd and
openntpd, but i didn't find any configuraition option related to this.
One wouldn't expect the facility to deliberately break them in this way.
I need this quirky thing due to time syncing of several broadcast
graphics servers which also generates clocks to TV picture and it is
necessary to compensate delay caused by MPEG coding and transmission
of TV signal.

Situation changed a little bit, because there is possibility to use
standalone GPS synced video timecode generator with NTP server card,
which has possibility of setting fixed offset in msec. So this is
probably best solution mentioned by Mr. Unruh.

I tried also fudge directive in ntp.conf, but it works only with local
hw clocks as my server isn't equiped with any GPS or some radio
reciever.
Tips with compiling of custom timezone file with zic for clients or
writing patch to ntp daemon are also interesting solutions and
although i won't use for this project, it guided me to explore another
unix tools and reading ntp daemon sources.. So thanks to all for their
tips.

Kind regards

Michal Smucr
.

Relevant Pages

  • Re: Windows Time with NTPv4
    ... in which case the w32time clients were unable to ... synchronize to the NTP server, unless they were reconfigured correctly to ... server, ... mode 3 req -> mode 4 resp ...
    (comp.protocols.time.ntp)
  • Re: syncing two machines, microsecond precision?
    ... increase in offset, but what I'm doing requires the two machines to be ... I've gone through the NTP debug routine ... restrict 127.0.0.1 ... You have not provided your server with a stable timebase. ...
    (comp.protocols.time.ntp)
  • Re: NTP stratum problem
    ... We have solris stations with ntp 4.2, act as a server and clients. ... Vxworks machines polling these Solaris clients using VxWorks ...
    (comp.protocols.time.ntp)
  • Re: Sugestion for accuracy value on TSP
    ... the reported offset is the true error - that suggests that people feel ... NB all these error bound calculations assume that every server in the ... Whilst NTP estimates R, it doesn't estimate T, but rather UTC + T, i.e. ...
    (comp.protocols.time.ntp)
  • Re: very slow convergence of ntp to correct time.
    ... ntp started up and the offset steadily climbed until it ... was 60msec offset. ... Since the client and server are only about 50usec apart (round trip time is ... I am also getting weird behaviour of the round trip time. ...
    (comp.protocols.time.ntp)