Newsgroup: it.comp.os.linux.sys
Titolo: ssh e saturazione banda

Ho due intranet collegate da una linea ISDN.
Quando ci sono grossi trasferimenti ftp le  connessioni ssh diventano molto 
lente, sembra essere unproblema di latenza: premo un tasto, aspetto un po' 
ed ho risposta.
Il collo di bottiglia è sicuramente la line isdn ( cmq qualcuno consce dei 
tool per misurare la banda e la latenza *lungo*  una connessione ? )
Mi piacerebbe che il traffico ssh ( che consuma poca banda ) avesse un'alta 
priorita rispetto agli altri. Considerate che posso agire solo su
1) un endpoint della connessione isdn ( una è una macchina linux, dall'altra 
parte non so neanche *cosa* mi risponde, anche quà avete idee su come posso 
interrogarlo ? )
2) limitatamente su un endpoint della connessione ( in genere sono macchine 
linux/unix ), dall'altra parte ci sono N ( con n troppo grandi ) macchine 
Window con putty ( il più bel programma sotto windows .... )
Avevo pensato a una soluzione di traffing shaper, ma cosi posso "regolare" 
il traffico in una direzione, nell'altra mi devo prendere i pacchetto che 
mi da il "coso" e basta. Certo risolvo il 50% dei casi.
Forse lavorando di mtu ? 
Avete qualche letteratura a cui rimandarmi ?
TIA

 Avete qualche letteratura a cui rimandarmi ?
sicuramente il traffic shaping e' la soluzione migliore, anche se
sofisticata, quindi non facilissima.
probabilmente ti e' sufficiente una semplice manipolazione del TOS che fai
con iptables:
iptables -t mangle -A OUTPUT -j TOS --set-tos 0x10
(ovviamente questa rule va messa dove risiede sshd)
per sapere cosa fa quel comando di preciso, una semplice ricerca con google
di iptables + TOS dovrebbe darti tutte le risposte che vuoi

 google di iptables + TOS dovrebbe darti tutte le risposte che vuoi
Basta molto meno ...
[root@moscow conf]# iptables -j TOS -h | grep 0x10
                                     Minimize-Delay 16 (0x10)
Il problema è sapere quanto i vari stack sono rispettosi di questo 
suggerimento; farò dei test .....

 mi da il "coso" e basta. Certo risolvo il 50% dei casi.
Se sei tu  a scaricare dalla macchina remota non  risolvi con un traffic
shaper sulla tua macchina.
Se  proprio non  hai  accesso  alla macchina  remota,  puoi provare  con
il  target LIMIT  di  iptables. L'host che  trasmette  inizia a  spedire
pacchetti  ad una  certa  velocita`,  aumentandola gradualmente;  quando
iniziano le prime richieste di ritrasmissione la velocita` si stabilizza
(su  quella che  dovrebbe  essere  la massima  consentita  dal media  in
uso).  Con iptables  puoi forzare il drop dei pacchetti  anche quando la
connessione non e` del tutto saturata,  riservandoti un po' di banda per
ssh.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Un apostolo vedendo Gesu` camminare sulle acque:
- Cazzo se e` buono 'sto fumo!!!

 (ovviamente questa rule va messa dove risiede sshd)
Purtroppo NON serve. Facendo un po' di test, si vede che di suo ssh mette il 
TOS pari a 0x10 ( Minimize-Delay ); ho visto anche che ftp ( per lo meno 
sotto linux ) nei trasferimenti dei dati lo setta a 0x08 ( 
Maximize-Throughput )... insomma tutto è come deve essere ( ed in effetti 
in un angolino della mia testa ricordavo qualcosa del genere ) ... 
*probabilmente* c'è durante il percorso dei pacchetti un qualche stack che 
ignora questi pacchetti....
Per maggiori info 
man 7 socket
man 7 ip
ethereal

 ethereal
preferisco tcpdump (sai, lo Stevens mi ha insegnato quello...) :-)


questo basta se sai di cosa si parla, ma io non potevo certo indovinare il
tuo livello di conoscenze dal primo post, no? :-)

mustafa® wrote:

Ovviamnete stavo rispondendo a tono :) al tuo sfotto... non me la sono 
presa, ne spero che tu te la sia presa...
Cmq ero io che avevo chiosto delle info, e tu mi hai dato un *ottimo* 
spunto...

 presa, ne spero che tu te la sia presa...
e di che? ;-)
solo il mio tono non voleva essere di sfotto...
;-)

ed ho risposta.
Forse non c'entra niente, scusate ma non sono molto pratico... e devo
ancora provare quello che poi vi suggeriro'... mi fate da cavie? ;-)
http://lartc.org/wondershaper