[cancellato] l'idea mia e' che essendo il server proton "buono" (nel senso di buono come il server di fastweb) allora il traffico li' da of=>w3=> arriva senza problemi, poi dopo dipende solo dalla saturazione del server vpn, nel mio caso era libero quindi andava al massimo
Presunta configurazione errata OLT | AREA BIANCA C/D
Ciao, anche io sono in area bianca e noto da tempo questa differenza importante tra host che hanno implementato BBR e non.
ISP: Dimensione
Provenienza: Trentino Alto Adige
CWNET: https://www.speedtest.net/result/c/a900e446-7356-4c64-b6fa-3f65ab2d3479
CDLAN: https://www.speedtest.net/result/c/0d095571-7154-47e4-9c81-0bfd9d36ed83
Fastweb: https://www.speedtest.net/result/c/a29e8bd8-6db7-430e-b803-e71e0ad7b0c6
Anche nel mio caso, se provo ad utilizzare una VPN, bypasso la "problematica".
[cancellato]
- Modificato
xzvice Beh però wireguard gira su UDP, quindi tutte le supposizioni sull'algoritmo di congestion control diventano "fragili".
Potrebbe essere qualche interfaccia satura da qualche parte nella rete di trasporto OF, magari da priorità al traffico UDP per minimizzare i packet loss. Sto pensando a voce alta eh... però non mi si spiega come alcuni server in realtà diano velocità buona anche direttamente in HTTP/TCP e altri no. Ok che l'algoritmo di congestion control magari è più "aggressivo" nell'utilizzare la capacity dei link, però mi pare un po' alta come differenza.
BTW, provate con i server incriminati a fare un test alle 4 di mattina. Scommetterei che va a banda piena...
[cancellato] BTW, provate con i server incriminati a fare un test alle 4 di mattina. Scommetterei che va a banda piena...
Nono, vanno identici giorno e notte 
- Modificato
[cancellato] BTW, provate con i server incriminati a fare un test alle 4 di mattina. Scommetterei che va a banda piena...
Al massimo vanno peggio (nelle ore con più traffico), non meglio di quello che è il "loro massimo".
La cosa è nata perché @xzvice si lamentava che sulla sua FTTH Wind i server di Wind stessa andavano a metà della banda (circa 500Mbps), la cosa era stata bollata dal gruppo Telegram come "Wind fa shaping sui suoi stessi server perché ha un kit di consegna sottodimensionato, cambia operatore e risolvi". Poi sono saltati altri utenti con altri ISP, collegati sia allo stesso che altri PCN, con problema analogo e il dubbio che Wind non c'entrasse nulla è diventata quasi certezza.
La cosa curiosa è che non è un semplice BBR, non BRR, ci sono server che non dovrebbero far uso di BBR (come Fastweb Milano) che vanno a banda piena (> 900Mbps).
Altra cosa curiosa che mi fa escludere che il tutto dipenda dalla congestione di un link, è che il PCN dell'OP è in grado di reggere due speedtest 1Gbps simultanei (da due linee diverse) e che nel suo caso la consegna wind è a pochi km dal PCN. Mi sembra altamente improbabile beccare lo stesso link congestionato degli utenti che hanno la consegna a 200km dal PCN.
Un utente inoltre afferma che pur non avendo mai visto quei server incriminati a banda piena, è cambiata la velocità massima raggiungibile dagli stessi con il cambio ISP, nello specifico con fibertelecom erano a circa 800Mbps, con aruba circa 600Mbps.
Mi verrebbe da dire che a questo punto sia un QoS "brutto" lato OLT (o comunque apparati OF), per quanto assurdo possa essere.
Mi spiego peggio, quando il PCN viene inizialmente rilegato con ponte radio viene applicato un sistema di QoS più pesante per evitare la saturazione "con un utente".
Dopodiché, quando il PCN viene rilegato in FTTH, OF non aggiorna la configurazione e quindi gli utenti rimangono con il QoS "vecchio", che ovviamente cappa più del dovuto.
BRR ed UDP sono solitamente degli ottimi modi per ignorare il QoS basilare, vedasi roba tipo quello dei Fritz, dove puoi impostare limiti semplici ma ti basta poco per superarli senza problemi.
Forse FW Milano usa un TCP-CC che non è BRR, ma nemmeno Cubic, bisognerebbe se ci sono differenze tra i vari server, o forse è semplicemente questione di "sfiga" con un bug in stile mikrotik (dove un IP si spacca e tutti gli altri funzionano bene, in questo caso il server FW Milano sarebbe spaccato)
- Modificato
LucaTheHacker Mi spiego peggio, quando il PCN viene inizialmente rilegato con ponte radio viene applicato un sistema di QoS più pesante per evitare la saturazione "con un utente".
Dopodiché, quando il PCN viene rilegato in FTTH, OF non aggiorna la configurazione e quindi gli utenti rimangono con il QoS "vecchio", che ovviamente cappa più del dovuto.
mai avuto rilegamento radio il mio, parliamo di molti PCN con la stessa problematica, e ipoteticamente tutti ma non ne siamo ancora certi, non abbiamo gli strumenti necessari per testarlo, se non un ISP
Vorrei invocare @giusgius e @[cancellato]:
se riusciste a raccogliere delle "prove" riguardo questo problema potreste magari segnalarlo a OF direttamente...
qui non si tratta solo di speedtest, come un server speedtest va male, tanti altri andranno a meno della meta', esempio riot games e tanto altro...
Se poteste fare qualcosa ve ne saremmo grati...
- Modificato
xzvice Partecipo anche io al thread segnalando che pure io, come utente C&D, ottengo un comportamento simile a questo.
Per il periodo in cui sono stato con Fiber Telecom avevo speedtest pieni stile area A&B (poi di sera con le partite crollava tutto a picco a livello inutilizzabile, ma è un altro discorso) mentre con altri ISP (prima Tiscali, da non considerare più di tanto per via dei suoi noti problemi, e ora Aruba) il comportamento, a spanne, è sempre stato quello indicato nel primo post.
LucaTheHacker Mi verrebbe da dire che a questo punto sia un QoS "brutto" lato OLT (o comunque apparati OF), per quanto assurdo possa essere.
Tenendo conto che con FT avevo dei massimi più alti ma dei minimi molto più bassi, ora con Aruba questo si traduce in massimi più bassi ma minimi più alti, quindi quest'ipotesi da te formulata potrebbe avere un senso anche se non credo che sia una cosa effettuata a livello di OLT.
[cancellato] BTW, provate con i server incriminati a fare un test alle 4 di mattina. Scommetterei che va a banda piena...
Non vanno mai a banda piena, nemmeno alle 4 di mattina; il massimo che ho visto sarà stato forse 650-700 mbps, che ci si avvicina ma non sono i canonici 940 mbps. NB: con FT andavano a banda piena negli orari scarichi.
- Modificato
beastlukas
Sono almeno 12 mesi che non eseguo uno SpeedTest, allo scopo di valutare la mia linea !
X deformazione professionale vorrei che ci fosse il modo, lato utente, di testare solo la tratta fra OLT e ONT perché gli SpeedTest lasciano sempre il tempo che trovano come ha giustamente sottolineato beastlukas viste le possibili variabili: rilegatura PCN, Saturazione Linea, ISP, ecc...
Allo stato attuale a parte qualche fuori servizio programmato non ho mai avuto problemi di banda lavorando in Smartworking; gradirei forse una maggiore velocità in Upload per una migliore Performace verso il Cloud aziendale !
Attualmente il mio ISP offre solo una 1000/300. spero solo che in seguito possa, come altri ISP, integrare l'offerta oltre 2,5G/500, con un taglio intermedio 1000/500; il sogno sarebbe un profilo 1000/1000 in grado di sfruttare al meglio la mia rete interna.
Paolo
giusgius però intendo comunque che non rientra in una cosa contrattualmente “contestabile” lato loro
Domanda ingenua e non rivolta solo direttamente a te: perché un utente qualsiasi come @MiloZ può segnalare a FT, Telia, Cogent o Sparkle che ci sono problemi spesso "non contrattualmente contestabili" ed essere preso in considerazione, ed invece con OF non c'è possibilità di far indagare (a quanto riferisci) il perché ci siano hiccup di questo tipo sulla loro rete?
giusgius non c’è alcunché da contestare. Questa è pura curiosità sul perché vi siano queste differenze tra aree nere e bianche. Magari una config. errata lato OF che se segnalata potrebbe benissimo essere fixata. Chi lo dice che sia una cosa VOLUTA e non un errore umano? Una piccola segnalazione a nome di tutti potrebbe essere fatta. Purtroppo noi utenti non abbiamo alcun modo di interfacciarci con OF, quindi è l’ISP stesso che deve perlomeno provare a farlo.
- Modificato
fl4co
Nel mentre altri con Aruba vanno invece al massimo
Abbiamo fatto delle prove con una linea in area bianca ed ONT Nokia (ISP Dimensione).
Praticamente come hai scritto al primo post: tramite VPN la velocità raddoppia, in pratica il problema si risolve pur NON essendo colpa di Dimensione (altrimenti impatterebbe tutti i clienti).
Io infatti con Dimensione sullo stesso BRAS dell’utente in area bianca, vado alle stesse velocità anche senza VPN.
Quindi: il problema è di OpenFiber ma si risolve con una VPN, pur transitando sempre sulla rete di OpenFiber prima di arrivare alla VPN.
Possibili spiegazioni? 
MiloZ Abbiamo fatto delle prove con una linea in area bianca ed ONT Nokia (ISP Dimensione).
Sarebbe quasi interessante provare a questo punto una A&B su Nokia...