BBB mit 142 Teilnehmern

Hallo zusammen,

ich wollte mal meine Heutige Beobachtung mit euch teilen.
Mein Setup: Server Core i7 4770 mit 4 Kernen (8 mit HT) 32GB RAM und zwei 2 TB HDDs dediziert bei hetzner.de.

Die Seminarleitung wollte einem gesammten Kurs von Referendaren etwas kund tun: also ca. 160 Leute hab ich erwartet.
Meinem Server habe ich zwischen 80 und 120 Teilnehmer zugetraut, also hab ich vorher folgende Regeln aufgestellt:

  1. nur eine Webcam an: Teilnehmern sind die Webcams verboten (-> Einstellungen).
  2. Micro aus: Teilnehmern sind die Micros verboten

Was ist passiert?
Es waren „nur“ 142 Teilnehmer da (mit Präsentator).

… und der Server hat sich die ganze Zeit gelangweilt. Load in htop war um die 4.

Ich denke gerade das Microabschalten hat viel gebracht.

LG

Holger

1 „Gefällt mir“

Sehr schön.
Soviele hatte ich noch nicht…
Dein htop sieht so aus als würde trotzdem freeswitch viel leisten.
Ich denke eher, dass die Webcams aus waren hat den load nicht hochschnellen lassen?

Grüßle
Ralf

Hallo zusammen,
habe das Forum gerade entdeckt. Habe auch nen BBB Server seit ein paar Tagen am Laufen ( * Intel® Xeon® * 6 x 3,7 GHz) . Mittwoch hatten wir erste Dienstbesprechung mit 33TN, 1 Cam und 1 Mikro, und der Server hat sich total gelangweilt. Seit Donnerstag sind die Kollegen schon ran, hatte heute auch an die 50 TN am Start in unterschiedlichen Räumen, wenn alle sich diszipliniert verhalten ist das auch kein Problem und würde jetzt auch ohne Probleme mit 200TN im nächsten Schritt das testen.
Größere Probleme gibt es wenn viele Webcams oder Bildschirme parallel übertragen werden. Das große Problem ist aber nicht der Server, sondern die dünne Leitungen bei vielen bzw. dass die CPU die VideoStreams verarbeiten muss. Bei Audio mixt ja Freeswitch auf dem Server und überträgt eine Audiofile an die Nutzer, bei Video ist das ja anders.

Holger (hoffe du Ansparache ist heir in Ordnung?), wie war denn die Netzwerkauslastung? Ich prüfe das parralel zu htop mit nload, das wäre auf jeden Fall auch Interesant zu wissen bei so vielen TN.

Liebe Grüße aus Karlsruhe,
Sebastian

Hallo Sebastian,

Holger (hoffe du Ansparache ist heir in Ordnung?)

ja: so machen wir das in aller Regel.

, wie war denn die
Netzwerkauslastung? Ich prüfe das parralel zu htop mit nload, das wäre
auf jeden Fall auch Interesant zu wissen bei so vielen TN.

habe ich nicht beobachtet, da ich 1 GBit/s symmetrisch für „eher nicht den Flaschenhals“ hielt.

Das wird auch erst mit vielen WebCams anschalgen: aber lange zuvor, wie
du ja schreibst, bei den Clients zum Problem werden.

Liebe Grüße aus Karlsruhe,

Viele Grüße
(ebenfalls aus Karlsruhe)

Holger

Hej Holger,
mit „Mikro aus“ meinst Du „Mikros stumm“ oder wirklich nur „als Zuhörer verbunden“. Weiß jemand, ob das einen Unterschied macht…?
Die Restriktionen hast Du vermutlich über „Zuschauerrechte einschränken“ umgesetzt…?
Grüße
Michael

Mikro ausschalten ist ausreichend, der freeswitch berechnet nur laufende streams…

Ich hab jetzt einige Sprechstunden mit BBB durch und ich komme immer mehr zum Ergebnis, dass der Server nicht das Nadeloehr werden wird, es sei denn, es laufen sehr (!) viele Konferenzen mit Video.

Wenn es bisher miese Audioergebnisse (und die sind mit Abstand am Schlimmsten) gab, dann war das immer die Folge eines ueberlasteten Clients, der es nicht geschissen bekommt > 3 Videostroeme im Hintergrund zu dekodieren und dann nur noch kaputte Audiodaten sendet und dieses Problem laesst sich serverseitig nur schwer mit Geld bewerfen.

Einzigste Loesung ist Kameras aus, ich vermute, dass es sogar beim Ueberlasteten reicht, die Praesentation auf Vollbild zu stellen. Das Feature, dass man im Browser die Ansicht der Cams der Gegenueber einzeln oder alle abstellen kann, erwarte ich sehnlichst - soll ja kommen.

Eine Loesung waere auf dem Server die Videostroeme „zusammenzuplexen“ und als ein Datenstrom zu senden, ich denke das machen die kommerziellen Systeme auch und dann noch H.264 anstatt dem freien VP8 als Codec. H.264 decodiert die Grafikkarte auf der linken Arschbacke und die CPU kann sich mit dem anderen Kram beschaeftigen. Wenn ich das richtig verstanden habe, haengen an H.264 noch Patente, die gerade bei den Enocdern auf dem Server zum Tragen kommen.
Falls ich da falsch liege, bitte berichtigen, ich grabe mich da gerade durch.

Gruss Harry
Edith: Wieder zuviel geschwafelt, hab die Essenz mal fett gemacht.

1 „Gefällt mir“

Hallo zusammen,

auch von mir mal eine Rückmeldung. Wir haben ja dank des Grafana-Monitorings eine ganz gute Übersicht.

Auf unserem 8-Kerner mit 64GB haben wir letzte Woche am Mittwoch 388 (!) Konferenzteilnehmer mit 322 Audiostreams und 27 aktiven Webcams hinter uns gebracht.
Die CPU-Auslastung lag kurzzeitig mal bei 80% - meist pendelte sie sich bei 60% ein.
Die Netzlast lag zu diesen Zeitpunkten zwischen 80 und 120 MBit/sec ausgehend (eingehend ca. 1/3) - das ist ein Bruchteil dessen, was bei Hetzner möglich wäre.
Was aber auffiel - und das ist ja mit Blick auf die bisherigen Erfahrungen auch erklärbar: an dieser „Grenze“ fingen vereinzelt Dienste an, nicht mehr 100% zuverlässig zu funktionieren. Die Bildschirmübertragung wurde in einzelnen Fällen wackelig, Folien wurden plötzlich geschlossen, einige wenige Kolleginnen und Kollegen berichteten von ausgegrauten Knöpfen in der Konferenz.

Dennoch ist die Belastungsgrenze offensichtlich ziemlich hoch - ich finde das beeindruckend. Ich habe zu dieser Zeit BBB noch normal nutzen können - nutze aber im Normalfall auch max. 2 Audioströme.

Dennoch wird es Zeit für einen Scalelite-Server. Dazu in einem anderen Post mehr :slight_smile:

Viele Grüße
Thomas

1 „Gefällt mir“

Hallo Harry, ich finde dein Geschwafel sehr interessant. Die Angaben nehme ich inzwischen auch aus Grafana. Vermute hier aber noch einen Fehler, ich bekomme nicht den ganzen Traffic angezeigt, den ich wiederum bei net plan einsehen kann. (Ziehe nachts ein Backup von der Cloud auf den Server via ftp, das fehlt beim Traffic). Das Videoplexing fände ich auch ein interessantesFeature, dass sich viele Lehrkräfte wünschen. Alternativ wären auch alternative Codes sowie Anwenderprogramme / Apps interessant, die zum Berechnen von Video bestimmt die GPU nutzen könnten.

BBB ROCKT!!!

Heutiger Praxistest hat bewiesen, dass BBB absolut tauglich für Videoconferencing ist.

Heute führten wir eine Mischveranstaltung durch, in der Fragen an die Schulleitung gestellt werden konnten, die den Unterricht nach Pfingsten betrafen.

Wir führten eine Mischveranstaltung aus Präsenz- und virtuelle Teilnahme durch. Rahmenbedingungen waren w-LAN der Schule (Ruckus-Lösung der Stadt Karlsruhe), Lenovo Laptop der neuesten Generation mit Aktivboxenanschluss.

Wir hatten also folgende unsichere Variablen:

  • w-LAN der Schule
  • kein TURN-Server (da mir @baumhof noch keine Zugangsdaten via PM geschickt hat :stuck_out_tongue_winking_eye:)
  • Clients der KollegInnen außerhalb der Schule
  • sehr lahmars…ger T@School-Anschluss der vorletzten Generation.

Und siehe da, wir sind nur einmal aus der Konferenz geflogen. Als alle externen Kolleginnen und Kollegen ihre Webcams und ihre Mikrofone ausgeschalten hatten und die meiste Konversation über den Chat ging, lief BBB sowas von stabil.

Daher Zoom, Teams und Co mögen das besser gelöst haben, jedoch reicht in meinen Augen BBB völlig für den Schulgebrauch aus.

Wie wir schon öfter gelesen hatten, liegt der Fehler meist auf der Seite der Teilnehmer und nicht am Server. Auch die günstigsten Hätzner-Server liefern genügend Leistung, um BBB an der Schule zu starten. BBB funktioniert mit vielen Teilnehmern gut, wenn die Webcams und Mikrofone ausgeschalten sind.

Für mich ist BBB genau das Instrument, dass wir nach Corona und Co weiter nutzen und mit unseren Erfahrungen im Schulalltag unterstützen sollten.

Herzliche Grüße
Marcus

2 „Gefällt mir“

Hallo Marcus,

ich stimme dir zu 100% zu.
Allerdings hatte ich gestern doch ein seltsames Phänomen, bei dem ich die restliche Konferenz schon etwas Schweiß auf der Stirn hatte, dass das gut geht:

Viele Grüße
Steffen