[NUT-devel] Broadcasting nuts [PATCH]

[Rich Felker]

On Wed, Feb 06, 2008 at 05:44:16PM +0100, Michael Niedermayer wrote:
> > Mark the buffer with actual receive times, according to the local
> > clock, and correlate them with the timestamps in the NUT stream,
> > smoothing out any timing adjustments over a long interval that's still
> > an order of magnitude away from the length needed for drift to become
> > a problem. 
> 
> Ill try again with an even simpler example to make it harder to miss the
> problem. Eventually you will have a problem to ignore it and pretent
> some disconnected solution might work
> 
> lets assume 1 frame/sec video, and 100byte/sec channel rate
> Frame 0   dts   0 99byte received at 0
> Frame 1   dts   1 99byte received at 0.99
> Frame 2   dts   2 99byte received at 1.98
> ...
> Frame 1000 dts 1000 99bytereceived at 990
> 
> vs.
> 
> 99byte/sec channel rate
> Frame 0   dts   0 99byte received at 1
> Frame 1   dts   1 99byte received at 2
> Frame 2   dts   2 99byte received at 3
> ...
> Frame 1000 dts 1000 99byte received at 1000
> 
> The above 2 are with atomic clock based transmitters and receivers. 
> Now assume the clocks drift how are you going to detect let alone compensate
> for this? Either of the 2 outputs could have come from the other stream if the
> clock drifts in the right direction.

A clock this bad would drift by 1/4 an hour per day. I doubt anyone
would buy such a clock...

With that said, let's analyze the situation. In your 100 byte/sec
scenario, the data is being transmitted too fast by the sender. If
clocks are in perfect sync, the buffer will grow unboundedly on the
receiving side. On the other hand, if the sender is doing the correct
thing and only sending at 99 bytes/sec, but the receiver sees it as
100 bytes/sec due to clock drift, there is no problem. The measured
mean difference between dts and receipt_time will be 0.45 for the
first 10 frame window, 1.45 for the second 10 frame window, etc. This
drift in mean serves to adjust the receiver's clock.

In the example here it seems like very small windows and very quick
adjustments would be necessary, but that's only because of the
ridiculousness of the magnitude of the clock's error in your example.
Normal clocks do not drift by 15 minutes per day.

Rich