Newsgroup: it.comp.os.linux.sys
Titolo: SCP e latenza

Buonasera,
 
sto facendo delle prove di laboratorio per capire quando è opportuno 
usare la compressione con scp e sto ottenendo dei risulati per me 
sorprendenti.
 
Supponiamo di trasferire un file altamente comprimibile (compress ratio 
0,27 con zlib o ad ogni modo quel che usa ssh), con e senza 
compressione. Su una linea molto lenta, ad esempio 256Kbits, mi aspetto 
che il rapporto
 
Tempo_trasferimento_con_compressione_scp/Tempo_trasferimento_senza_compressione_scp 
(per brevità Tc/Tnc)
 
sia molto simile alla compress ratio, ed infatti è ciò che ottengo.
 
E fin qui tutto bene direte voi ... e lo dico anch'io ..., ma poi mi è 
venuto in mente di variare anche la latenza. Infatti la linea da 
256Kbits l'ho ottenuta tramite tc (disciplina htb), ma a l'inizio ho 
lasciato la latenza base della mia LAN (quindi un'ambiente di test poco 
veritiero). Con un colpo di netem ho variato la latenza e ho rimisurato 
il rapporto Tc/Tnc, ecco i dati:
 
Latenza  Tc/Tnc
      0    0,28
     40    0,34
    200    0,50
 
All'aumentare della latenza la compressione diventa sempre meno 
conveniente. Se Tc/Tnc = 1 la compressione non abbatte i tempi di 
trasmissione, e graverà inutilmente sulla CPU.
 
Non capisco perché la latenza dia maggiormente fastidio alla 
compressione. Avete idee in merito?
 
 


 
Se ho capito bene le tue prove ed i tuoi risultati, aumentando la 
latenza, il problema si è postato sulla dimensione della finestra TCP.
 
Potresti provare ad aumentarne il valore, in 
/proc/sys/net/ipv4/tcp_window_scaling, /proc/sys/net/ipv4/tcp_rmem e 
/proc/sys/net/ipv4/tcp_wmem.
 
Magari la mia diagnosi è farlocca, eh.
-- 
Sul problema di Saint Venant:
"Al momento, preferisco il taglio".

compressione. Avete idee in merito?
 
Matematicamente non torna. Per spiegare la faccenda serve un ulteriore grado
di liberta', e non saprei dove trovarlo...
 
...a meno che stiamo osservando una formula del tipo (Tc+dt)/(Tnc+dt), tanto
per fare un'ipotesi.
 
Cambia qualcosa, se usi file molto piu' lunghi?
 
Leonardo
 
-- 
What would'st thou do, my squire so gay, that rides beside my reine
Were ye Glenallan's Earl this tide, and I were Roland Cheyne?
To turn the rein were sin and shame, to fight were wondrous peril:
What would ye do now, Roland Cheyne, were ye Glenallan's Earl?

 /proc/sys/net/ipv4/tcp_wmem.
 
In realtà sto testando hpn-ssh quindi la finestra TCP centra e non 
poco, tuttavia non mi capacito perché la copia con compressione è molto 
più soggetta a degrado con l'aumento della latenza.
 
Con l'aumentare della latenza iperf misura sempre correttamente la 
banda massima, nel caso specifico 256Kbits. Con latenza 0 o quasi scp 
senza compressione raggiunge valori vicino al 90-95% di iperf. Con 
latenza a 200ms SCP senza compressione degrada ma SCP con compressione 
degrada, in proporzione, maggiormente.
 
 
-- 
Gabriele
 

 Cambia qualcosa, se usi file molto piu' lunghi?
 
Ci sto provando, vi farň sapere.
 
Per inciso calcolo la media di piů rilevazioni, per limitare l'errore 
statistico.
 
-- 
Gabriele
 

 Cambia qualcosa, se usi file molto piu' lunghi?
 
Ho lanciato una run lunghetta con latenza 40ms, 256Kbits di banda e 
copia ripetuta di file da 10MB. I primi risulati mi ritornano il 
rapporto corretto di 0,27.
 
Che vuol dire?
 
-- 
Gabriele
 


Credo che l'errore sia dovuto alla presenza di una coda di trasmissione.
Quando il rapporto coda/file e' elevato, introduce un errore percettibile;
aumentare le dimensioni del file riduce questo errore, che e' sistematico.
 
Comunque - se lo scopo dell'operazione e' trasferire file, considera anche
l'idea di usare tar, bzip2 e ssh "non" compresso.


 [...]
 
 
Ciao  Manlio

 l'idea di usare tar, bzip2 e ssh "non" compresso.
 
Purtotppo per i miei scopi ci� non � applicabile. Mi inerressa usare 
ssh tunelizzando varie connessioni (ftp, db, altro), e capire sull'hw a 
disposizione fino a quando la compressione � conveniente (la prossima 
fase di test verter� sul numero concorrente di sessioni).
 
Grazie.
 
-- 
Gabriele
 

 Non dovrebbe essere difficile verificare se la causa è questa.
 
Mi sembra di aver aperto il vaso di pandora … Non pensavo di dover 
cosniderare tutta questa marea di dettagli.
 
Secondo:
 
http://www.bolet.org/~pornin/deflate-flush.html
 
 
SSH usa il partial flush e non il full-flush. Puoi confermarmi?
 
Grazie mille.
 
-- 
Gabriele
 

 rapporto corretto di 0,27.
 
Per quel che posso paragnostare, in condizioni reali (e non ideali) ci sono 
anche le ritrasmissioni di pacchetti persi che alterano i tempi in maniera 
significativa, ad esempio.
 
Se vuoi che la gente ti aiuti in maniera ragionata devi incollare i 
risultati *grezzi* di più run ed in più condizioni e scrivere esattamente i 
risultati che ottieni ed esattamente il modo di configurare i vari stack 
tcp/ip che utilizzi.
 

fase di test verterà sul numero concorrente di sessioni).
 
In uno scenario del genere io terrei SSH non compresso, e poi lascerei a
ciascun protocollo - se possibile - di implementare la compressione piu'
adatta.
 
Ti posso dire, per es., che dopo varie prove e kilotoni di bestemmie, ho
concluso che MySQL con "compressed client-server protocol" attraverso un
tunnel non compresso funziona piu', e meglio, di MySQL non compresso che
passa attraverso un tunnel compresso.
 
Sospetto che la stessa cosa si applichi piu' o meno a tutti i formati.



Non conosco i dettagli di SSH, ma dal sito che hai riportato, dice:
 
A partial flush means that the current compressed block is ended and all 
data will be output
 
Bisogna vedere cosa intende con "be output".
Il blocco viene inviato come pacchetto TCP separato?
 
Se è questo il caso, allora **potrebbe** spiegare la latenza, dico 
potrebbe perchè alla fine è il kernel che decide quando spedire un 
pacchetto.
 
 
Ciao  Manlio
 
 
 
Ciao  Manlio

 passa attraverso un tunnel compresso.
 
Io dovrei usare Oracle che (almeno nella versione in uso) non provede 
compressione di sorta, quindi sarei "costretto" a comprimere attraverso 
SSH.
 
In LAN di certo non userei la compressione, su un'ADSL sicuro si, su un 
ponte radio con tot di latenza boh? Considerando poi che server SSH <> 
da server Oracle, e magari usando ssh-hpn con cipher none potrei avere 
delle piacevoli sorprese, ma per l'appunto � tutto da testare ancora, o 
meglio devo ancora trovare una metodologia di test solida.
 
-- 
Gabriele
 

 tcp/ip che utilizzi.
 
E hai ragione pure tu, ma i dati che per il momento ho raccolto sono 
parecchi e non ancora bene organizzati, vi farei pi� confusione che 
altro.
 
Se la storia finir� con un lieto fine di qualche tipo, ho intentzione 
di scrivere un piccolo paper, ma per il momento sono lontano da tale 
traguardo.
 
Grazie.
 
-- 
Gabriele