matteocontrini grazie, quindi quando vedo che il server finale mi fornisce un valore di negoziazione di 30.000.000 secondo te è normale? potrei anche crederci se non fosse che dopo questo vedo continui ritrasmissioni degli stessi pacchetti e ack il che mi fa pensare che qualcosa non và. Anche microsoft considera errori queste ritrasmissioni. Ciò non accade se disabilito l'autotuning, niente errori di ritrasmissioni ma una finestra di scala bloccata a 65000 il che non è bene per la mia banda . Probabilmente c'è qualcosa che ti sfugge, la finestra di ricezione dovrebbe essere adeguata alla capacità di banda altrimenti non ci sarebbe differenza fra reti FTTH o in rame. In teoria una FTTH dovrebbe avere una finestra più elevata e quindi più trasmissioni di dati senza controlli..

La funzionalità Di ottimizzazione automatica della finestra di ricezione consente al sistema operativo di monitorare continuamente le condizioni di routing quali larghezza di banda, ritardo di rete e ritardo dell'applicazione. Pertanto, il sistema operativo può configurare le connessioni ridimensionando la finestra di ricezione TCP per massimizzare le prestazioni della rete. Per determinare la dimensione ottimale della finestra di ricezione, la funzionalità Di ottimizzazione automatica della finestra di ricezione misura i prodotti che ritardano la larghezza di banda e le velocità di recupero dell'applicazione. Quindi, la funzione Di ottimizzazione automatica della finestra di ricezione adatta le dimensioni della finestra di ricezione della trasmissione in corso per sfruttare l'eventuale larghezza di banda inutilizzata.

      Max1234 lo ripeto l'ultima volta: la finestra di ricezione cresce a piacere se necessario e non può creare nessun problema. Se TCP vede che ha bisogno di una finestra più grande perché si sta riempiendo, la allarga (usando più RAM, banalmente), altrimenti la riduce. Questa è l'"ottimizzazione automatica" di cui parli, non è una cosa che va toccata, funziona bene di suo e funziona così su tutti i computer del mondo. Una finestra troppo larga vuol dire al massimo che sarà in parte vuota ma finisce lì, una finestra vuota non crea ritrasmissioni né altro, non c'è un nesso. Non è poi, come ho detto, la finestra di ricezione ad evitare di saturare la rete, quella è la finestra di congestione.

      Se pensi di avere packet loss non lo capisci guardando le finestre TCP, metti su un ping ICMP e/o TCP verso un IP del videogioco per 6 ore e poi vediamo.

        Max1234 Al computer finale non interessa se è una rete in ftth, fwa, fttb, fttc, adsl... Non sa neanche quale è la banda. Tcp prova ad inviare dati ad una velocità, poi la raddoppia finché ha dati nel buffer ed il sistema lo consente. Giochi come fornite useranno 1/100 della tua banda quindi il buffer si svuoterà sempre e mai arriverà alla tua velocità di 100 Mbps.

        Ah comunque i valori dovrebbero essere multipli dell'mtu. Che mtu hai (usa speedguide)? Non è che hai forzato l'mtu della pppoe a 1500?

            • [cancellato]

            • Messaggio #103
            • Modificato

            Max1234 (Correggetemi se sbaglio)

            Ci hanno provato in diverse persone...

            simonebortolin i valori dovrebbero essere multipli dell'mtu

            MSS, non MTU 😉

            Può anche essere che lui li abbia arrotondati per scriverli più facilmente, cambia poco nella pratica.

            Max1234 vedo continui ritrasmissioni degli stessi pacchetti e ack il che mi fa pensare che qualcosa non và.

            Ogni rete perde pacchetti. È normale, sono progettate proprio per fare questo: stai adattando una rete locale a 1gbps o 2-300Mbps ad una FTTC nella migliore delle ipotesi a 200M, il tuo PC non lo sa cosa ha a monte, non può saperlo... Gli algoritmi sono progettati come ha detto @simonebortolin per provare via via ad inviare sempre più informazioni, finché "non ci passano più". A banda piena hai due scelte: o usi buffer enormi nei router (e causi picchi di latenza o bufferbloat), o li tieni corti e ciò che non ci sta lo scarti.
            A fronte di un packet loss gli algoritmi di congestion control agiscono riducendo le finestre di trasmissione e reinviando i pacchetti persi.

            Funziona così tutto il mondo, da 40 anni e più.

                  Max1234 Di nuovo due messaggi attaccati? Contieniti.

                    • [cancellato]

                    • Messaggio #105

                    Max1234 vedo negoziazioni troppo elevate

                    Di nuovo, cosa ti fa pensare che siano "troppo elevate"? Gli OS moderni partono con finestre più grandi di una volta perché le velocità medie delle reti sono maggiori e la memoria disponibile non è un problema. Come già detto, una finestra più grande non comporta problemi di ricezione, anzi, c'è spazio a iosa inviare dati speditamente. Poi tocca all'applicazione essere capace di processarli velocemente.

                    Max1234 poi una serie di 3 frequenze identiche

                    Fequenze o sequenze? Stai parlando dei sequence number? Usa i termini corretti che usano tutti 😀 E attenzione alle traduzioni in automatico degli articoli del KB di Microsoft, alcune sono pietose.

                    Fare un'analisi di una sessione TCP richiede un po' di pratica e di conoscenze precise di come funziona TCP, a anche lo specifico protocollo applicativo usato. Gli ACK in una trasmissione fluida sono continui, se dall'altra parte non riceve ACK in tempo ritrasmette i pacchetti. Così come gli ACK possono essere ripetuti, cosa significa dipende se dall'altra parte sono stati nel frattempo trasmessi altri pacchetti oppure no.

                    Max1234 viene abbassato a circa 65.000 ma non vedo più numeri sequenze identiche

                    Possibile - stai rallentando di brutto la trasmissione, quindi certi "burst" di dati potrebbero non avvenire e i pacchetti "spaziati" di più nel tempo. Comunque se hai problemi di gioco li stai probabilmente cercando nel posto sbagliato. Non ci ha detto come è fatta la tua rete, in quanti la usano contemporaneamente e come, che dispositivi di rete stai usando,e come sono configurati. La latenza può essere causata da molti fattori, di cui alcuni ben più probabili di altri.

                            6 giorni dopo

                            [cancellato] Rieccomi😂 Sono riuscito a tamponare un pò le cose limitando l 'MTU a 576.. Sembra che tra la mia rete e i server finali (TUTTI) ci sono molti punti con MTU più bassi. Probabilmente questa cosa, anche se il sistema operativo riduce automaticamente l mtu ovviando a perdite di pacchetti, credo sia la principale causa del rallentamento della rete.. Non penso sia il massimo un mtu a 576, sembra tornare indietro alla preistoria comunque è senz'altro meglio dei continui ridimensionamenti ....

                                Max1234 Sono riuscito a tamponare un pò le cose limitando l 'MTU a 576.. Sembra che tra la mia rete e i server finali (TUTTI) ci sono molti punti con MTU più bassi.

                                Mi puoi dare un po' di questi server?

                                Perché io non ho problemi ad avere un MTU più di 10 volte superiore al tuo😅

                                    nanomad non mi capacito di come gli funzioni tutto il resto ..

                                    Ma poi i collegamenti dei server hanno tutti almeno 1500 byte di MTU…

                                        gandalf2016 per ipv4 il minimo MTU é 68 bytes, con 576 il default consigliato eoni fa

                                            simonebortolin Non sò spiegare dove sia il problema ma vi posso assicurare che riducendo l'mtu accedo ai protocolli UDP ed è anche migliorato l'RWIN che su TCP analyzer è sempre fisso a 131072 ma comunque in rete negozio valori più alti. Ieri ho letto di uno che aveva un problema quasi simile e tramite MTR ha scoperto che sopra i 1100 di MTU i pacchetti venivano frammentati. Ho un pò preso spunto ed ho effettuato alcune verifiche con mtr, il primo punto con valori bytes (modem) a scendere fino a 900 era un disastro.. A 900 bene ma avevo comunque "loss" in altri punti . Ho abbassato i Bytes fino a non ricevere più "loss" sul percorso ( 600 ) ed ho impostato mtu manuale a 640 .... Sicuramente stò andando in palla, ormai provo di tutto🤣 ma Vi posso assicurare che per ora funziona MOLTO meglio di prima ...

                                                nanomad Sò che nel 2022 non dovrebbero esistere certi valori ma con MTU normali riscontro numerosi "loss" che, se anche TCP alla fine gestisce senza perdite, mi causa notevoli rallentamenti. Inoltre, se ci sono perdite sul percorso, è impossibile usare UDP che a differenza di TCP non gestisce loss, di conseguenza il server finale effettuerà la connessione solo ed esclusivamente tramite TCP...

                                                  Max1234 ma tu stai affermando che il loss è nel modem?

                                                  • Max1234 ha risposto a questo messaggio

                                                      simonebortolin fino a 900 si il modem ma non solo, a 900 nessun loss sul modem ma altri comunque presenti su altri punti.

                                                          Max1234 Per favore posta un paio di MTR, sicuro stai mal interpretando i dati

                                                              Informativa privacy - Informativa cookie - Termini e condizioni - Regolamento - Disclaimer - 🏳️‍🌈
                                                              P.I. IT16712091004 - info@fibraclick.it

                                                              ♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile