From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by mail.toke.dk (Postfix) with ESMTPS id 30F967CAC85 for ; Wed, 13 Jan 2021 20:09:28 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (1536-bit key) header.d=stroeder.com header.i=@stroeder.com header.b=YUyk3WcO DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=stroeder.com; s=stroeder-com-20201114; t=1610564966; bh=56aBVSxSBrVh3oQG0Wxju/Xl7m+n174E2EYyVMAW07w=; h=To:References:From:Subject:Date:In-Reply-To:From; b=YUyk3WcOViaA989uXd8UKE/5lR3TS9tlekyx0zqmz9UzSFJB4X8u5y8C2Oua2ENv+ ALpR/TVfJoXm1oa2Pc+xvEV3SJex0B+ugZKgm8tKbJ4Yts1v/7MBmIOIBGq+eR4mSW ggIha/OD7qcKrwHpRr91UUhiQ7SxBHdCJ9CUAqleoTbk25vZ1y8inKg9TSbshf7Dmx L85K6zpPdJP9l6tqNjIpHiZYUcG3/c3IX3nyOcbdr1lQCfUdp4j9/Uq3mFB To: galene@lists.galene.org References: <87k0siqndj.wl-jch@irif.fr> <87pn2aup3o.fsf@toke.dk> <878s8yqcmh.wl-jch@irif.fr> <871reqqb52.wl-jch@irif.fr> <37ca33b3-e31a-db9c-8ca8-f4d438a1d284@stroeder.com> <87h7nlq29o.wl-jch@irif.fr> From: =?UTF-8?Q?Michael_Str=c3=b6der?= Message-ID: Date: Wed, 13 Jan 2021 20:09:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <87h7nlq29o.wl-jch@irif.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Message-ID-Hash: N7E6HRFFWVTAITXCIS43TECFZAPCRT4M X-Message-ID-Hash: N7E6HRFFWVTAITXCIS43TECFZAPCRT4M X-MailFrom: michael@stroeder.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.3.2 Precedence: list Subject: [Galene] Re: fq-codel trashing List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: On 1/12/21 10:22 PM, Juliusz Chroboczek wrote: >>> We just had a meeting with 70 people and at around 40 cameras switche= d on, >=20 >> Which send quality were they all using? "normal"? >=20 > The quality selected in the menu is the maximum allowable quality; Gal=C3= =A8ne > 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 wer= e > running at "normal", but the resulting bitrate was somewhere between "l= ow" > 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. >=20 > Hmm... was that with Gal=C3=A8ne? Which browser? Yes, with Gal=C3=A8ne. I don't know which browser was used though. > In principle, Gal=C3=A8ne 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=C3=A8ne. 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=C3=A8ne only > keeps track of the amount of jitter. For a down stream, Gal=C3=A8ne ke= eps > track of both average delay and jitter. >=20 > Up: =C2=B13ms means 3ms average jitter; > Down: 30ms=C2=B13ms 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.