From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass (mailfrom) smtp.mailfrom=irif.fr (client-ip=2001:660:3301:8000::1:2; helo=korolev.univ-paris7.fr; envelope-from=jch@irif.fr; receiver=) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by mail.toke.dk (Postfix) with ESMTPS id BFEF47CA3E4 for ; Tue, 12 Jan 2021 22:22:14 +0100 (CET) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 10CLMDdV005508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Jan 2021 22:22:13 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 10CLMDkn010148; Tue, 12 Jan 2021 22:22:13 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A83AD24529; Tue, 12 Jan 2021 22:22:13 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id RGyg-PAfT2cO; Tue, 12 Jan 2021 22:22:11 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C18C024526; Tue, 12 Jan 2021 22:22:11 +0100 (CET) Date: Tue, 12 Jan 2021 22:22:11 +0100 Message-ID: <87h7nlq29o.wl-jch@irif.fr> From: Juliusz Chroboczek To: Michael =?ISO-8859-1?Q?Str=F6der?= In-Reply-To: <37ca33b3-e31a-db9c-8ca8-f4d438a1d284@stroeder.com> 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> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 12 Jan 2021 22:22:13 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 12 Jan 2021 22:22:13 +0100 (CET) X-Miltered: at korolev with ID 5FFE1305.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5FFE1305.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5FFE1305.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5FFE1305.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5FFE1305.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5FFE1305.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Content-Transfer-Encoding: quoted-printable Message-ID-Hash: G3VYQRSYR434VZSZJGUDBB5CZ4RKQG4R X-Message-ID-Hash: G3VYQRSYR434VZSZJGUDBB5CZ4RKQG4R X-MailFrom: jch@irif.fr 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 CC: galene@lists.galene.org 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: >> 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=E8= 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". > Frankly I understand only ~5% of what you're talking about in this thre= ad. Yeah, that's also our case. This doesn't prevent us from speaking, thoug= h ;-) > But do you really expect all users' end devices to decode 40 video stre= ams? [...] > In my local tests with slow and ancient 10+ years old laptops I even ge= t > video drop-outs within my LAN with only 3 video streams. At lab meetings, everyone has got rather nice laptops, and Gal=E8ne works reasonably well up to 25 videos or so, except for the elegant people with the fancy fanless MacBooks. The situation is different at lectures, of course, but then the students are not too keen on switching their cameras on. (Back in December, a student who wasn't reacting to a question admitted to being busy with frying eggs. I naturally accepted his excuse as perfectly legitimate.) > Not to speak of all the crappy Internet connections, already over-loade= d > while other family members are watching Netflix or similar situations i= n > shared flats. Gal=E8ne should in principle drop the quality down when a link is congese= d. We're currently dropping down to the lowest rate that everyone can tolera= te (but not beneath 200kbit/s), with simulcast or SVC, as discussed in a previous mail, we'll be able to send different qualities to different users. > 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=E8ne? Which browser? In principle, Gal=E8ne generates all the bits of protocol to perform accurate lipsynch on the receiving side. I have veryfied that it works well with Chrome. > Not sure whether that's really a fairness issue within Gal=E8ne. 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. For an up stream, Gal=E8ne only keeps track of the amount of jitter. For a down stream, Gal=E8ne keeps track of both average delay and jitter. Up: =B13ms means 3ms average jitter; Down: 30ms=B13ms means 30ms average delay with 3ms average jitter. >> At the highest point, Gal=E8ne was at 270% CPU, and the TURN server wa= s >> using another 50%. That's on a four-core VM. > I'm far away from such a setup. So I wonder whether my response is > useful at all. It's very useful. We want Gal=E8ne to scale all the way from a single co= re ARMv7 (thanks for the Beaglebone, Dave) to a 16-core, 32-thread server. -- Juliusz