[NUT-devel] Broadcasting nuts [PATCH]

[Rich Felker]

On Thu, Feb 07, 2008 at 09:37:02PM +0100, Michael Niedermayer wrote:
> > 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.
> 
> You are very deeply confused.
> The client buffer has never changed, what has changed is the channel

Indeed, sorry, both the buffer size and preload requirement are
parameters on which the window size must be based.

> I have the feeling you base your emails on the assumtation that your system
> is as good as mpeg. Maybe you should not blindly assume this.

Good and MPEG do not belong in the same sentence, but I'll try to
pardon that...

> > BTW the scaling is pretty meaningless because these 0.01% differences
> > are smaller than your clock precision anyway. In any actual real-world
> 
> You got the scales wrong. The example got longer and you increas the window
> and its VERY MUCH harder to synchronize the clocks in your system. BUT the

Indeed it did. If the preload requirement is allowed to grow without
bound, then you will eventually hit a point where the window exceeds
the clock precision. My point was simply that no one would care if the
presentation were 0.01% too slow or too fast as long as the buffer did
not deplete; this was what I meant by clock precision.

> > 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.
> 
> Have you lost all sense of logic?

Not last I checked... But if this topic keeps up too much longer maybe
we all will.

> 100000 99byte packets at 99.01bps  will fill the buffer at
> 0.01bps, it will contain 1000 byte after the 100000 packets
> 
> 10000 99byte packets at 99.1bps  will fill the buffer at
> 0.1bps, it will contain 1000 byte after the 10000 packets
> 
> 1000 99byte packets at 100bps  will fill the buffer at
> 1bps, it will contain 1000 byte after the 1000 packets

I'm talking about what happens AFTER the switch from
faster-than-realtime to slower-than-realtime. If there never is a
switch then the buffer requirements grow without bounds, which is not
a workable system.

> To preload these 1000 bytes the time needed is 10second for all these
> examples. if thats too long just stop 90% sooner, that is

It's 9.5-9.9 seconds too long.

> Nothing changed, you can continue this series in many directions
> Pick your buffer size, pick your averaging window size, pick your max preload
> all 3 freely chooseable, the examples still applies.

No, as long as max preload is tiny, a small averaging window works
fine. Work out the formal definition of max preload and it becomes
clear..

Rich