aternopae l'ONT è un dispositivo di livello 2, quindi è una comunicazione sincrona con l'OLT che risponde allo standard G.984, se diversi ONT avessero framerate diverse non negozierebbero con l'OLT.
Il link fisico di un canale ovviamente dipende esclusivamente dallo standard utilizzato per instaurare il canale, però il GPON a differenza di un cavo ethernet che è un mezzo P2P, dove se c'è link fisico con autosenting il throughput rispecchia il phy rate fisico dato che il cavo ha un determinato SNR da garantire la velocità decisa dall'autosenting non ci dovrebbero essere più di tanti errori che abbassano la velocità, in un mezzo condiviso come il GPON le performance dipendono da come viene gestito il mezzo condiviso e quindi la coppia OLT-ONT. Dato che nonostante tutti gli ONT rispecchiano lo standard G.984 possono essere ampiamente configurati in maniera diversa la cosa più facile che mi viene in mente da spiegare è la limitazione dell'upload viene fatta via OLT. L'OLT fa si che l'ONT non possa avere troppi pacchetti ethernet da inviare all'interno dei frame GEM e questo garantisce il limite dell'upload. Questo fa si che nell'ONT ci devono essere delle code, e le code non sono standardarizzate nel G.984, ma a discrezione del vendor e del manufacter, e proprio per questo il throughput dipende anche dal tipo di ONT.
In maniera analoga si può generalizzare in questo modo: il problema di diverse performance di diversi ONT sono le code dei frame GEM: ogni frame GEM contiene 20-30 pacchetti ethernet, e per creare e leggere questi frame serve avere dei buffer dove si incapsulano i pacchetti ethernet, ricordo che un frame GPON è di 38880 byte, 38 di overhead statico e 5 byte*numero di ont, in upload tu hai diritto ad alcuni slot di questi (con un numero massimo pari alla tua velocità di upload. Avere code configurate male non permette di usare al massimo questi frame GPON facendo sì che alcuni ne vengono sprecati.
Questo fa si che anche l'ONT è responsabile di performance inadeguate, però c'è un ma, essendo lo stesso ONT le performance inadeguate devono essere le stesse dal day0 al day1000000 e/o diventano inadeguate dopo aggiornamenti SW/HW dell'OLT.
aternopae Per potere testare il throughput, e quello magari può essere il router a fare la differenza, dovresti fare un altro tipo di test con il tuo next-hop, ma non è detto che questi abbia il necessario per poterlo fare.
Dato che è già stato chiesto di adeguare la guida allo speedtest a cosa, pensi, in questo messaggio:
Perché al posto di scrivere "hint" a caso non la fai così vediamo oppure, perché non evitiamo di dire certe cose nosense.
Mi spieghi come si fa a testare la velocità sul next-hop, che poi che perché il next-hop? Cioè semmai il dispositivo di confine della rete dell'OLO, ma non il next-hop, perché il next-hop potrebbe sotto casa (in un grande ISP) oppure un utik messo nel seminterrato di Caldera, è una indicazione forviante, non avrebbe senso, dato che nel percorso tra il tuo router e il next-hop, cioè il bras, a meno di tue reinvenzioni della routa, potrebbe essere connesso da una matrioska di kit vula, nga o rv fw, ponti radio, rfc1149, ethernet over coax, atm, .... incapsulati in altri pacchetti, MPLS, chi più ne ha più ne metta, e questo da una misura del throughput tra due device, ma non è confrontabile a nulla, perché ogni altro utente potrebbe avere configurazioni diverse della rete in mezzo e questo test fornisce come già detto il throughput all'interno di matrioske a caso senza nessuna possibilità di confronto con altri utenti. Mentre se lo si fa sul dispositivo di confine della rete dell'ISP avrebbe già più senso, ma anche quì tutti gli utenti dello stesso ISP potrebbero raggiungerne di diversi in load balancing, come succede nei grandi ISP, però questo è già più sensato di una misura che guarda solamente quanto throughput c'è in un L2 dal tuo router di casa a non si sa dove.
Però questo misura il throughput all'interno della rete dell'ISP, dopo di che bisogna misurare il throughput tra l'ISP e per esempio un OTT, cosa facciamo anche quì un next-hop alla volta?
Ma allora abbiamo che il 1/throughput = 1/throughput1 + 1/throughput2 + ... 1/throughputN che si può dire uguale a throughput = min(throughput1,throughput2, throughputN), che guarda caso è lo stesso risultato che da lo speedtest.
