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
