<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">Yes, Chromium is expensive as it took 360 cores for 100 clients.</div><div class="gmail_default" style="font-family:monospace">We had to use a test application like the one you've shared </div><div class="gmail_default" style="font-family:monospace">to scale to thousands.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">At the time we started running these experiments I'm not sure<br></div><div class="gmail_default" style="font-family:monospace">your code was already available.</div><div class="gmail_default" style="font-family:monospace">We've also used jitsi hammer until it was discontinued.<br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">As long as you can send a video sample and as long as the </div><div class="gmail_default" style="font-family:monospace">test app includes rate adaptation, it's almost everything</div><div class="gmail_default" style="font-family:monospace">one could ask for.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Luca</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 4, 2021 at 8:09 PM Sean DuBois <<a href="mailto:sean@siobud.com" target="_blank">sean@siobud.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I would really love to build a general WebRTC tester. Spinning up lots of<br>
Chromium instances is super expensive. Even if you do the mock webcam<br>
you are doing way more then needed.<br>
<br>
I created[0] which spins up many PeerConnections to load test a server.<br>
I think this would be a great alternative to the testing that exists<br>
today.<br>
<br>
* You can send pre-encoded video or RTP packets directly.<br>
* You can receive RTP and not pay the costs of processing<br>
* You get direct access to Receiver Reports, Transport Wide Congestion<br>
  Control and Receiver Estimated Max Bandwidth.<br>
* Way easier to deploy. We can build a small static binary.<br>
<br>
If anyone is interested would love to help them kick off a project. We<br>
can make it general enough to test Galene, Janus, Jitsi, Ion etc... If<br>
it gets acceptance from the greater WebRTC community it could really<br>
grow!<br>
<br>
[0] <a href="https://github.com/pion/rtsp-bench/blob/master/client/main.go" rel="noreferrer" target="_blank">https://github.com/pion/rtsp-bench/blob/master/client/main.go</a><br>
<br>
On Tue, Mar 02, 2021 at 05:01:42PM +0100, Luca Muscariello wrote:<br>
> Dave,<br>
><br>
> we have done extensive WebRTC (and several other online meeting<br>
> apps) testing lately and this paper<br>
> <a href="https://ieeexplore.ieee.org/document/9153228" rel="noreferrer" target="_blank">https://ieeexplore.ieee.org/document/9153228</a> reports a<br>
> methodology for WebRTC based on Chromium and Selenium Grid and<br>
> as test orchestrator Jitsi Torture.<br>
><br>
> I would avoid feeding clients with BBB as video as it is not<br>
> representative of a meeting as encoders are optimized for<br>
> different kinds of video. There are several video samples<br>
> out there.<br>
><br>
> We have scaled up clients to hundreds with this methodology.<br>
> The paper is short so many details have been omitted but there<br>
> are not many other options to do this kind of test at scale.<br>
><br>
> Luca<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> describes the methodology<br>
><br>
><br>
><br>
> On Tue, Mar 2, 2021 at 2:15 AM Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>> wrote:<br>
><br>
> > Given that we have a worldwide network of flent servers...<br>
> ><br>
> > Given how easy galene is to hack on... and a 10 minute install...<br>
> ><br>
> > given some webrtc scripting... a few more stats... some javascript...<br>
> > skull sweat... funding...<br>
> ><br>
> > It seems plausible to be able to construct a suite of tests that could<br>
> > indeed track jitter<br>
> > delay and loss across the internet over webrtc. Perpetually uploading<br>
> > bigbuckbunny or some<br>
> > other suitable movie might be an option, but I have a fondness for<br>
> > extracting a sub 30 second segment from  "Max Headroom", which if<br>
> > those here have not seen it, predicted much of the fine mess we're all<br>
> > in now.<br>
> ><br>
> > I guess my question is mostly, is a "headless" test feasible? In the<br>
> > context of samknow's lack of webrtc test... lowpowered hw....<br>
> ><br>
> > --<br>
> > "For a successful technology, reality must take precedence over public<br>
> > relations, for Mother Nature cannot be fooled" - Richard Feynman<br>
> ><br>
> > <a href="mailto:dave@taht.net" target="_blank">dave@taht.net</a> <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729<br>
> > _______________________________________________<br>
> > Bloat mailing list<br>
> > <a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
> > <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
> ><br>
<br>
> _______________________________________________<br>
> Galene mailing list -- <a href="mailto:galene@lists.galene.org" target="_blank">galene@lists.galene.org</a><br>
> To unsubscribe send an email to <a href="mailto:galene-leave@lists.galene.org" target="_blank">galene-leave@lists.galene.org</a><br>
<br>
</blockquote></div>
</div>