[NUT-devel] Broadcasting nuts [PATCH]

Rich Felker dalias at aerifal.cx
Thu Feb 7 21:08:16 CET 2008


On Thu, Feb 07, 2008 at 07:51:53PM +0100, Michael Niedermayer wrote:
> On Thu, Feb 07, 2008 at 11:39:34AM -0500, Rich Felker wrote:
> > On Thu, Feb 07, 2008 at 02:45:22PM +0100, Michael Niedermayer wrote:
> > > > > "your design B." here was the case that the transmitter was not allowed to
> > > > > transmit the first 1000 99bte frames at 100byte/sec but was limited to 
> > > > > 99bytes/sec. This causes a larger preload requirement at the start. And
> > > > 
> > > > 2 issues here:
> > > > 
> > > > 1. I never said you're not allowed to transmit the first 1000 99-byte
> > > > frames at 100 bytes/sec, only that the average difference between dts
> > > > and transmit time over VERY LARGE windows needs to be constant. 
> > > 
> > > This just scales the numbers, whichever window size you use you cannot 
> > > transmit data ahead in it at average.
> > 
> > The average I'm talking about is over a window 100x larger than any
> > possible buffer. You've completely misunderstood what I've said all
> > along.
> 
> You claim that you can transmit the 1000 99 byte packets at 100bps
> at any choosen constant average buffer fullness (=transmit_ts - dts) if the
> window is sufficiently large. I claim you can ALWAYS scale this so it fails.
> try 10000 99byte packets at 99.1bps
> try 100000 99byte packets at 99.01bps

I choose the window after you choose the scaling. The client buffer
size depends on the scaling and I can choose the window based on the
client buffer size.

BTW the scaling is pretty meaningless because these 0.01% differences
are smaller than your clock precision anyway. In any actual real-world
_broadcast_ stream (where clients can begin receiving at any moment
and decode with guaranteed small preload delay), the average will be
constant over small windows, e.g. 10-60 seconds. Your hypothetical
example above has a HUGE preload delay for clients who begin receiving
right after the long string of faster-than-realtime transmission
suddenly goes slower-than-realtime.

Rich



More information about the NUT-devel mailing list