Tcp optimizer: parliamone qui!

Da qualche giorno è disponibile questo tweak (cercate in rete le repo non voglio fare spam di repo qui :slight_smile: ) che promette di incrementare le performance di rete dei nostri iDevice.
Sicuramente non è la scoperta dell’acqua calda, tuttavia complimenti ai developers per l’idea e la realizzazione! Ma cosa fa questo tweak?

Diciamo che installa un mini demone, che poi viene giù (non avremo nulla che mangia memoria) ma in fase di boot va a dettare tramite uno script questi valori:


sysctl -w net.inet.tcp.recvspace=292000
sysctl -w net.inet.tcp.delayed_ack=0
sysctl -w net.inet.tcp.maxseg_unacked=16
sysctl -w net.inet.tcp.mssdflt=1460

Questo sh si trova in /usr/libexec e con ifile potete editarlo come volete.

Le mie conclusioni? Trovo più che azzeccate le modifiche, volendo se ne potrebbero aggiungerne altre (le sto testando) in ogni caso va detto che i margini di guadagno sono leggeri, specie se non si mette sotto stress la rete.
Quindi il mio modestissimo parere è che sotto rete wifi fa solo bene, su 3G le differenze saranno minori, in particolare non sono poi convintissimo dell’MTU settato così alto (1460) in quanto è in valore più da LAN, però farò qualche prova i prossimi giorni.

Ah, in rete si legge che potrebbe aumentare lo scambio dati… Non è vero, anzi, se la rete del vostro gestore supporta l’MTU così alto, e lo potrebbe fare tranquillamente, in realtà mandando meno pacchetti perché questi sono più grossi si mandano meno header, e quindi si risparmiano 40byte per ogni header non inviato…
In pratica per ogni pacchetto devo mandare un header. Se mando pacchetti di 512 dovrò mandare più pacchetti e quindi più header. Se il corpo è più grande, dovrò mandare meno header perché meno pacchetti dovranno essere inviati…
Pago dazio in caso di frammentazione o pacchetti non ricevuti che dovranno essere rimandati, ma si spera che tutto sia ok, specie su wifi :slight_smile:

Nessun maniaco che ha fatto qualche prova? :slight_smile:
Io personalmente dopo qualche prova ho commentato la linea

sysctl -w net.inet.tcp.delayed_ack=0

quindi il file diventa


sysctl -w net.inet.tcp.recvspace=292000
# sysctl -w net.inet.tcp.delayed_ack=0
sysctl -w net.inet.tcp.maxseg_unacked=16
sysctl -w net.inet.tcp.mssdflt=1460

che credo sia poi la stessa cosa di:


sysctl -w net.inet.tcp.recvspace=292000
sysctl -w net.inet.tcp.delayed_ack=1
sysctl -w net.inet.tcp.maxseg_unacked=16
sysctl -w net.inet.tcp.mssdflt=1460

ma voglio provare, solo che qui non ho wifi solo il 3G di TIM, quindi… :rolleyes:

Voglio testare anche l’opzione

sysctl -w net.inet.tcp.rfc1323=1

Ack lo puoi mettere come vuoi sono solo bit di controllo errori,personalmente non ho fatte prove in quanto il valore dell’mtu cioè la dimensione massima del pacchetto che può transitare non penso abbia un’incidenza rilevante…

Veramente e’ il delayed acknowledgment TCP delayed acknowledgment - Wikipedia, the free encyclopedia
e dal punto di vista funzionare porta un sacco di differenze…

Tecnica di controllo errori di cui non ero a conoscenza,praticamente se ho capito bene non viene fatto un controllo errori ogni pacchetto inviato,una sorta di udp con controllo errori a intervalli di tempo? Sbaglio?

Allora per ogni pacchetto inviato / ricevuto (la cui dimensione viene per altro modificata dall’ultima voce) ne deve essere ricevuto l’ack (ricevuto se inviato, inviato se ricevuto).
Naturalmente c’e’ un tempo prefissato, c’e’ una sorta di “buffer” di pacchetti che possono essere ricevuti, elaborati, e poi “aknolegiati” di botto. Questo e’ il delayed ack.

Che non centra col controllo di errore nel senso stretto tipo CRC (quello e’ affidato allo strato piu’ basso, diciamo 1 e 2, qui siamo un filino piu’ in alto) ma che ovviamente centra col controllo di flusso del protocollo IP (quindi se non vado errato, siamo a livello 3).

Leggendo qua e la’ pare che solo un protocollo (samba) soffra in caso di delayed ack abilitato, poiché “aspetta” gli ack PRIMA di inviare altri pacchetti, e se gli ack sono ritardati, …hai gia’ capito anche tu che il trasferimento ne risente in peggio.
Il “Nagle’s Algorithm” serve, nella sua implementazione, è una sorta di estensione del delayed ack, e serve per ottimizzare l’invio degli ack. Ma anche qui non c’e’ una cura per tutti i male, e se questo metodo ottimizza la banda pura, penalizza il “ping” diciamo cosi’, in pratica non e’ il massimo per i gamer, e quindi se ne sconsiglia l’utilizzo se si usano molti giochi online proprio per massimizzare la “reattivita’” della rete.

Insomma qui si va ad innestare una reazione a catena e di tweak e ce ne sono da impazzire :wink:

Diciamo che, delayed ack a parte sul quale stiamo appunto discutendone l’efficacia, quelli “base” che ci sono qui non hanno controindicazioni.

Onestamente, IL MIO script di TCP Optimizer l’ho modificato cosi’ :


sysctl -w net.inet.tcp.recvspace=292000
sysctl -w net.inet.tcp.delayed_ack=1
sysctl -w net.inet.tcp.maxseg_unacked=16
sysctl -w net.inet.tcp.mssdflt=1460
sysctl -w net.inet.tcp.rfc1323=1

Come al solito invito a provare i settaggi prima con speed test (e’ gratuito sullo store) e cronometrando un’apertura di una home page abbastanza grossa, magari prima svuotando la cache di Safari :slight_smile:

Provo a breve sia la velocità do download/upload il Ping e la risposta se invio pacchetti size1460 appena posso ci smanetto.