Tutto quello che vorresti sapere su bbb...

Tests effettuati, features, misurazioni e feedback degli utenti...

Il nome BigBlueButton deriva dal concetto iniziale secondo cui l'avvio di una conferenza Web dovrebbe essere semplice come premere un grande pulsante blu metaforico

[wikipedia]

Un po' di riferimenti

per conoscere a fondo, poter valutare, costificare e scegliere consapevolmente

L'obiettivo di questa pagina è di dare informazioni relativamente a BigBlueButton. Può essere molto utile per le scuole che vogliano conoscere come funziona questo strumento, quanto importante sia configurarlo correttamente per ottenere un'eccellente accessibilità o per capire quanto potrebbe costare per la propria scuola.

Features

Nella home e nella pagina deidcata potrai trovare una lista di alcune features. Altre potrai trovarle nei sondaggi sotto (diverse domande di fatto sono relative alle features presenti)

Vuoi vedere un esempio di come registra questo strumento? Qui la registrazione di un evento andato molto bene con più di 200 partecipanti.

Help Me!

Bisogno di aiuto sull' utilizzo di Big Blue Button? Abbiamo creato un forum dedicato con diverse guide ed istruzioni che spiegano come usarlo al meglio al fine di garantire l'accessibilità.

Quanto importante è conoscerlo e configurarlo correttamente? Molto!

Qui abbiamo parlato di quanto fare le corrette valutazioni ,quando si pensa ad una strategia per la didattica a distanza, influenzi l'accessibilità. Big Blue Button permette molte impostazioni granulari che altri strumenti non consentono (vedi sezione features sotto). 

Questo non lo dico io, lo dite voi! Si evince infatti da due sondaggi (vedi sotto). Il primo rivolto a persone molto competenti in materia informatico/multimediale (hackers and friends) invitati ad un evento  quando ancora ignoravamo il fatto che le corrette impostazioni modificassero la qualità della teleconferenza.

Il secondo invece, rivolto ad insegnanti che abbiamo invitato ad un altro evento in cui abbiamo esposto alcuni concetti relativi a questo tipo di strumenti ed alla didattica on line in generale (spiegati anche in questo articolo del blog) per poi far provare con mano l'efficacia di Big Blue Button. L'evento è andato talmente bene che invece che durare 2 ore è durato 4 ore. Abbiamo provveduto anche a creare un forum dedicato per guide e domande.

Tornando al sondaggio, che potete vedere sotto, noterete come le stesse domande nel primo evento abbiano ricevuto una valutazione più bassa (nonostante le persone fossero tutte informatizzate )rispetto al secondo evento, composto soprattutto da insegnanti.

Per confrontare le domande e risposte tra un sondaggio e l'altro è sufficiente cliccare sull'immagine, questo vi porterà alla stessa domanda e risposte dell'altro sondaggio.

 

Che server mi serve?

Dopo i sondaggi  potrete vedere dei grafici ed un'analisi fatta assieme a Marco Marinello e a Paolo Dongilli, del progetto Fuss e dell'intendenza scolastica di Bolzano con l'obiettivo di avere dei dati oggettivi per dimensionare correttamente le istanze da installare .

Survey party 

Hackers and friends...

cliccando sulle immagini potrai andare alla stessa domanda/risposta dell'altro sondaggio per confrontare come delle corrette configurazioni facciano la differenza

Questo sondaggio è stato fatto durante il party di cui parliamo in questo articolo









 





Dopo questo sondaggio abbiamo imparato che se si vuole veramente essere inclusivi vanno valutate diverse opzioni ed una corretta strategia implementativa. Viceversa si rischia di rendere la lezione o il meeting inaccessibile per molti.

Survey Insegnanti

Quando hai la possibilità di impostare molte opzioni per migliorare la qualità... ;-)

cliccando sulle immagini potrai andare alla stessa domanda/risposta dell'altro sondaggio per confrontare come delle corrette configurazioni facciano la differenza

 
 Questo sondaggio è stato fatto durante questo evento 
 in collaborazione con il PNLUGe con gli insegnanti, ne abbiamo parlato in questo articolo








Che Server mi serve?

Misurazioni e grafici per incrociare i dati:

In collaborazione con 


Demo Logo
progetto Fuss
 
Demo Logo
Lug BZ

Demo Logo
Marco Marinello
 
Demo Logo

Caratteristiche del server

Di seguito le caratteristiche del server che abbiamo monitorato

Abbiamo monitorato con Zabbix i vari server messi a disposizione, dal Lug di Bolzano alle scuole, per capire quanto vengano utilizzati, in modo da avere dei dati oggettivi, che siano di riferimento anche per le altre scuole o realtà che vogliono dimensionare le soluzioni adeguate per loro.

Il server ha le seguenti caratteristiche: 16 core - 32Gb di Ram


Flectra image and text block

Big BlueButton

Da questo grafico vediamo i valori minimi, la media ed i picchi relativi a:

  • Meetings totali (stanze)

  • Utenti connessi

  • Utenti con microfono attivo

  • Utenti con webcam attive

Utilizzo CPU

Da questo grafico vediamo i valori minimi, la media ed i picchi relativi all'utilizzo della CPU

Nota bene: da documentazione ufficiale dopo il superamento del 75% di utilizzo della cpu le performance cominciano a degradare (per esempio l'audio comincia a sentirsi male)

Flectra text and image block
Flectra image and text block

Utilizzo Banda

Da questo grafico si vede l'utilizzo minimo, la media e l'utilizzo massimo della banda

Una visione di insieme

Nota bene: in questa configurazione è attiva l'opzione che inibisce a tutti di vedere tutti (gli studenti vedono l'insegnante, l'insegnante vede gli studenti ma gli studenti non si vedono tra loro) riducendo drasticamente il numero di flussi webcam (vedi articolo relativo) anche se da questi grafici non si vede

Nostre considerazioni finali e valori di riferimento utilizzati per calcolare il server necessario.

Noi consigliamo:

Nel caso di un server con 16 core e 32GB di ram (forse ne basta anche un po' meno) 

Prima di degradare la qualità può arrivare ad un massimo di:

200/220 utenti (con microfono)

22/24 webcam massimo (1/2 webcam per stanza)

ed utilizzerà circa 120Mbps di banda


Considerando i dati massimi:

231utenti : 14 stanze = 16,5 utenti per stanza

27 webcam : 14 stanze = 1,93 webcam per stanza

16,5 utenti x 1,93 webcam per stanza 31,845 flussi webcam per stanza x 14 stanze = 445,83 flussi webcam totali con un utilizzo eccessivo della cpu (78,43%)


Considerando i dati medi:

124 utenti : 8 stanze = 15,5 utenti per stanza

9 webcam : 8 stanze = 1,125 webcam per stanza

15,5 utenti x 1,125 webcam = 17,44 flussi webcam x 8 stanze = 139,5 flussi con un utilizzo della cpu della metà di quanto consigliato (36,8%)

non basta raddoppiare per avere i dati ottimali:  come quelli medi ma raddoppiati

139,5 x 2 = 279 flussi totali con un uso della cpu di 73,6% --> questo dato non è attendibile, come si evince dal confronto con i dati massimi sopra, dove l'utilizzo della cpu è di poco maggiore, a fronte di una quantità di flussi contemporanei di gran lunga maggiore.

Il consiglio che possiamo darvi è: testare e monitorare l'utilizzo medio, se volete possiamo aiutarvi a calcolare al meglio quello che vi serve in base alla nostra esperienza ed ai numerosi casi di utilizzo che abbiamo studiato. Il nostro approccio è partire con la configurazione migliore misurata sulle vostre esigenze, poi si può sempre aumentare le prestazioni o impostare numerevoli configurazioni per cercare di salvare banda o aumentare la qualità.

Discostamenti dovuti a:

qualità della webcam (ci sono più possibilità)

distribuzione reale delle webcam nelle stanze (quelle calcolate sono supposizioni non possiamo sapere la reale distribuzione puntuale da questo calcolo)

Esistenza o meno dello schermo condiviso

tecnologie utilizzate sono diverse: SFU e MCU 

e per finire, per i più golosi: schema di funzionamento

Altri dati dal web

Altri tests fatti su kurento server che è il componente che gestisce audio schermo condiviso

con i dati trovati nel sito: https://testrtc.com/sessions-kurento-server/

Qui abbiamo una configurazione con un server pari più o meno alla metà delle caratteristiche: 8 core, 15Gb di ram

Dal sito riportiamo la tabella finale:

Results Summary

The table below shows the various limits we’ve reached in our rounds of sizing tests:

Scenario Size
1:1 video calls 18 users in 9 parallel sessions
4-way group video calls 3 rooms of 4 users each
Live broadcast 1 broadcaster + 80-150 viewers


riassumendo:
- nel caso 18 utenti con 9 sessioni parallele (18 flussi webcam contemporanei) 

- 4x3 12 webcam 4x4x3 flussi webcam (in ogni stanza 4 persone vedono 4 persone per un totale di 16) x 3 stanze = 48 flussi webcam

- 1 x 150 = 150 flussi totali