Connessione TIM 2.5 Gbps ma Speedtest dà 2.1 Gbps

mariored gli dà le stesse identiche performance

Io da sempre non arrivo ai 2 Gbps - con prove e controprove, ONT differenti, router differenti, etc etc... - nonostante una manciata di circuiti attivi sul ramo GPON per cause mai meglio accertate lato OLT.

mariored Windows 11

mariored PPPoE

BSoD a parte, non andresti comunque molto in là con quell'accoppiata...

Lorenzo1635 Adesso scopriamo che la sua ONU è sola soletta

Lorenzo1635 VULA/NGA XGS-PON su FiberCop?

Come sai i profili X1/X2 sono ben presenti nelle relative Offerte di Riferimento pertanto la domanda a mio avviso va rivolta agli Operatori

walt X1/X2

Ero rimasto al fatto fossero solo disponibili via EasyIP TIM

Lorenzo1635

Ma quindi, io che sono in area bianca (e che divido la linea con 16 utenti invece che con 64 come in area grigia o nera), in teoria dovrei subire meno il degrado di prestazioni? Al momento viaggio sempre circa a 2300 e 460, ovvero il massimo possibile, ma se un domani gli abbonati aumentassero molto, che succede? Scusate l'intrusione ma è una domanda che non ho mai avuto una risposta definitiva, perché alcuni sostengono che le aree bianche siano migliori sotto questo aspetto, altrimenti invece sostengono il contrario...

mariored Temo di non essere stato abbastanza chiaro, per me questo non è un problema, è solo una curiosità. In sostanza vorrei capire se ho commesso qualche errore di configurazione io - qualcosa in cui posso migliorare - contro la possibilità che invece sia proprio il massimo delle prestazioni possibile (mettendo "problema" tra virgolette pensavo che l'ironia fosse evidente).

Puoi di sicuro provare ad aumentare l'MTU in modo da avere quello pulito post PPPoE di 1492 (fattibile al 100%) o 1500 (in genere quasi tutti gli apparati TIM supportano i mini jumbo frame per arrivare a questo valore).

mariored Si, ma è una questione di pura curiosità, non mi lamento della velocità.

Non era ben chiaro

Lorenzo1635 @walt c'è da dire che il mio calcolatore fa alcune approssimazioni per arrivare al risultato, cioè che i frame ethernet siano tutti lunghi uguali in un pacchetto GEM, e sappiamo bene che questo non è possibile. Quindi i risultati sono abbastanza teorici e nella realtà ci possono essere differenze rispetto a questo valore.

simonebortolin Quindi i risultati sono abbastanza teorici e nella realtà ci possono essere differenze rispetto a questo valore.

Claro ma nel mio caso siamo davvero una manciata di circuiti, il "cap" anomalo è presente fin da principio e riconosciuto dai colleghi di rete...infatti mi son messo il cuore in pace da mo

Buonasera ragazzi, una curiosità, mi intrometto, ma c'è un modo per verificare quanto utenti sono collegati ad esempio nel mio "albero" grazie mille?

walt

Ok grazie mille

walt già mi ricordo il tuo caso, era solo per evitare che qualcuno dicesse, nel mio albero siamo in 64 e navigo a più di 1.7 Gbps...

walt

volevo chiederti gentilmente se è possibile se puoi, controllarmi quanti utenti collegati sul mio albero? ti ringrazio, più che altro per curiosità del mio upload ballerino

chigos85

Dubito che la tua problematica dipenda da saturazione del link in ogni caso ritengo improprio soddisfare certe richieste in quanto si determinerebbero precedenti inopportuni...

walt

Ok grazie mille lo stesso, mi hanno cambiato anche l ont con lo zte ma nulla

LinusCasp 2) Ho letto on line che ad eth1.835 bisogna assegnare lo stesso valore di pppoe-wan. Solo nel caso la rete (ISP, router, rete e dispositivi domestici) supporti il baby jumbo frames puoi aggiungere 8 alla interfaccia fisica eth1 (quindi assegnare 1508). Da quello che ho letto on line attualmente il Flint 2 non supporta il baby jumbo frames (forse con futuri aggiornamenti firmware le cose cambieranno).

Diciamo che i baby jumbo per la vlan tutti i device gigabit li supportano.

simonebortolin

Secondo un utente sul forum di GL.iNet, tentando di impostare un'MTU di 1508 sull'interfaccia WAN fisica (eth1) per supportare i baby jumbo frames, si riceve l'errore:

ifconfig: SIOCSIFMTU: Invalid argument

Questo suggerisce una limitazione a livello di hardware o di driver del kernel. Un altro utente ha osservato che il firmware di GL.iNet non supporta MTU superiori a 1500, rendendo impossibile l'uso dei baby jumbo frames.

https://forum.gl-inet.com/t/gl-inet-mt6000-baby-jumbos-mtu-1508-not-working-on-wan-interface/50912/2?utm_source=chatgpt.com

Tuttavia in altra fonte si trova:

"Baby jumbo frames

By default the firmware uses an MTU of 1500 for the WAN interface. Since PPPoE adds an 8 byte overhead, the MTU on the PPPoE interface will be 1492, which is considered suboptimal (by some). The issue is that as of writing the main GL.iNet firmware does not support MTUs larger than 1500, so these ‘baby jumbo frames’ are not possible (possibly due to still using kernel 5.x). The OpenWRT 24-based version with open source drivers, however, does support larger MTUs.

Various discussions on Dutch forums suggest:

1512 on the WAN interface (to account for VLAN tagging overhead).
1508 on the VLAN interface (for the aforementioned PPPoE overhead).
1500 on the PPPoE interface.

I have found that LuCI does not allow me to set the MTU on the VLAN interface to a value higher than 1500. So I modified the network configuration in /etc/config/network as follows:

config interface 'wan'
option force_link '0'
option classlessroute '0'
option metric '10'
option device 'eth1.6'
option proto 'pppoe'
option username 'internet'
option password 'internet'
option vlanid '6'
option disabled '0'
option peerdns '1'
option ipv6 '1'
option mtu '1500'
config device
option name 'eth1.6'
option type '8021q'
option ifname 'eth1'
option vid '6'
option mtu '1508'
option mtu6 '1508'
config device
option name 'eth1'
option mtu '1512'
option mtu6 '1512'

https://danieldk.eu/GL.iNet-GL-MT6000-on-KPN-fiber?utm_source=chatgpt.com