Have you seen this? http://cr.yp.to/clockspeed.html
Spoon wrote: > Maarten Wiltink wrote: > > >> Spoon wrote: >> >> >>> B is supposed to re-send the packets it receives at the rate they >>> were originally sent by A. >>> >>> If the clocks on A and B do not tick at the same rate, the buffer >>> used by B will either overflow or underflow. >>> >>> This is why I need A's clock and B's clock to tick at the same rate. >>> >>> But it is not important to me that A and B's clock give the same >>> absolute time. ... >>> >> But nothing will break if they do, either. Right? >> > > Right. Of course :-) > > >> The simplest solution >> would be to have both synchronized to UTC, or either one to the other, >> and accept that they will keep better time or at least closer time. >> From the sound of it, you do not care about what time A keeps _at all_, >> so if you simply slave it to B, your problem goes away. >> >> The fact that you are concerned with reproducing timing but not with >> good time is, frankly, suspect and leads me to propose a different >> 'solution': could you monitor the buffer length and adjust frequency >> on system B from that? If it's slowly draining, slow down B a little; >> if it's growing, speed it up ever so slightly. Just like NTP does, >> really. >> > > The very hard part (for me) is seeing that B's buffer is in fact slowly > draining when there is a lot of jitter on the link between A and B. > > I've tried using an exponentially-weighted moving average to filter the > jitter out, but it didn't work as well as I had hoped. That is when I > turned to NTP. I'm trying not to reinvent the wheel. > > Are you saying I should use the theory in NTP but not the daemon? > > Regards. > > _______________________________________________ > questions mailing list > [email protected] > https://lists.ntp.isc.org/mailman/listinfo/questions > _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
