[Galene] Re: fq-codel trashing

["Michael Ströder" <michael@stroeder.com>]

On 1/12/21 10:22 PM, Juliusz Chroboczek wrote:
>>> We just had a meeting with 70 people and at around 40 cameras switched on,
> 
>> Which send quality were they all using? "normal"?
> 
> The quality selected in the menu is the maximum allowable quality; Galène
> will rather eagerly drop down beneath it, all the way down to 200kbit/s
> (it will drop quality even more aggressively in the future).  So we were
> running at "normal", but the resulting bitrate was somewhere between "low"
> and "lowest".

But if users are thrown out of sessions and reconnect the browser will
again try a higher send rate. Right? If that happens to several sending
users within a short time-frame you will get some peaks affecting all
the receiving users. Well, I'm speculating here.
(This reminds me of tuning of feedback control systems.)

>> We had one hearing impaired user who hears a little bit with in-ear
>> devices. Normally the user also follows spoken text by lip-reading to
>> get more context. But this is nearly impossible for her in a video
>> session because audio and video are not sufficiently synchronised with
>> our setup.
> 
> Hmm... was that with Galène?  Which browser?

Yes, with Galène. I don't know which browser was used though.

> In principle, Galène generates all the bits of protocol to perform
> accurate lipsynch on the receiving side.  I have veryfied that it works
> well with Chrome.

I'm not really capable of lip-reading, so I can't tell which quality a
lip-reading user would need. But there was some visible jitter even
within my LAN with just a one-to-one test.

Maybe I can contact this user to do dome specific tests...

>> Not sure whether that's really a fairness issue within Galène. I
>> can see differing latencies in /stats for different connections.
>> The connection with higher latency, most times on all "Down"
>> streams, has the higher latency consistently throughout whole
>> session. I suspect the receiver side is the issue.>
> You might be mis-reading the statistics.

Yes, maybe.

>  For an up stream, Galène only
> keeps track of the amount of jitter.  For a down stream, Galène keeps
> track of both average delay and jitter.
> 
> Up:   ±3ms     means 3ms average jitter;
> Down: 30ms±3ms means 30ms average delay with 3ms average jitter.

This matches my interpretation. As said the average down-stream delay
was consistently higher for users having issues.

Most users here are using the usual VDSL or cable-TV connections within
Germany. I have no knowledge whether some users are still using slower
DSL lines.

For connections/users without issues I see average down-stream delays of
40..60 ms with jitter 10..40 ms.

Users reported no problems even with down-stream delays of 100..150 ms.

Real problems start when average down-stream delays is 150+ ms most of
the time.

Ciao, Michael.