Newsgroup: it.comp.aiuto
Titolo: leggere trace route

 E quando appaiono gli asterischi?
Missing in action... ;)
Semplicemente  non  si e' ricevuta  nessuna  risposta per il pacchetto
sonda.
Traceroute funziona cosi'.  Lancia  raffiche  di 3 pacchetti, in  ogni
raffica  viene specificato  il numero di   "hop" che il pacchetto puo'
attraversare prima  di essere scartato (tale  numero e' detto  time to
live - tempo da vivere, tempo misurato in hop).  Al  momento in cui il
pacchetto viene scartato,    il nodo in   cui cio'   avviene  dovrebbe
rispondere  con  una  notifica   che    il  pacchetto e'   "morto   di
vecchiaia".  Alcuni  siti non   rispondono,   alte volte uno   dei due
pacchetti (sonda o risposta) viene perso. That's all.
o   oooooo	Gian Uberto Lauri        "So, are you working on finding
      o    o	
sa...@dei.unipd.it
        that bug *now* or leaving it until
     o o				  later?" - "Yes!" 
Attenzione, i dati nello header sono alterati per proteggermi dagli spammer.
L'indirizzo corretto e' nella firma.

pacchetti (sonda o risposta) viene perso. That's all.
Va bene. Questa e' la spiegazione teorica. Ma in pratica a cosa serve sapere
che il tal server ha risposto in 300 ms o tal'altro in 700 ms di media?
Mi spiego meglio. Questo e' un trace su 
204.182.160.150
:
 1. 161.27.9.66    
rm4-max.Infostrada.Olivetti.it
(200 ms) 
 2. 193.76.81.33   
serial1-gw1.iunet.it
          (224 ms) 
 3. 204.59.224.237 gsl-dc-3-Serial9/
2.gsl.net
    (319 ms) 
 4. 204.59.144.198 
gsl-sl-dc-fddi.gsl.net
        (362 ms) 
 5. 198.67.0.7     sl-dc-1-F/
T.sprintlink.net
    (334 ms) 
 6. 144.228.10.2   sl-stk-2-H8/
0-T3.sprintlink.net
(374 ms) 
 7. 198.67.6.6     sl-stk-6-F/
T.sprintlink.net
   (393 ms) 
 8. *** 
 9. *** 
10. *** 
11. 134.24.30.100  
owb-anaheim-ds3.cerf.net
      (466 ms) 
12. 134.24.82.200  
wdc-owb.cerf.net
              (509 ms) 
13. 129.253.80.253 <unknown>                     (449 ms) 
14. *** 
15. 129.253.50.1   <unknown>                     (475 ms) 
Trace route finished - Port unreachable
Il tempo massimo di risposta e' stato di 509 ms. Poca roba.
Per ottenere questo trace saranno passati almeno due minuti.
Proviamo il PING. 
204.182.160.150id =     8 rtt =       1256ms
204.182.160.150id =    11 rtt =       1292ms
204.182.160.150id =    15 rtt =       1270ms
204.182.160.150id =    20 rtt =       1230ms
204.182.160.150id =    22 rtt =       1217ms
Ping to 
www.wdc.com
 (204.182.160.150) completed.
Sent = 24, received = 11 packet loss =  54.17%
Statistics: min rtt = 1217   max rtt = 1326   avg rtt = 1277
Abbastanza male, 54% dei pacchetti persi. RTT medio 1277 ms.
Proviamo raggiungerlo in ftp e scaricare qualcosa. 100KB ... una vita.
Deduzioni?
 
Orion2. 
P.S. - chiedo scusa per il ritardato 'intervento'. Dopo un incrocio tra
news.tin.it
 e 
news.iol.it
 questo gruppo non mi veniva piu' aggiornato. 

 Proviamo raggiungerlo in ftp e scaricare qualcosa. 100KB ... una vita.
Dal traceroute sembrerebbe potersi avere  tempi di risposta elevati ma
non intollerabilil fino  a   129.253.50.1.  Dopodiche' c'e'   un  ramo
estremamente trafficato, troppo per quella che e'  la sua capacita' di
trasferire  dati. Ping  e' un sistema  "quasi  hardware", non  e' raro
vedere macchine  praticamente   inutilizzabili che   pero'  rispondono
ancora al ping.
 
Conta che per ogni pacchetto perso devi attendere  un timeout (mi pare
di circa un minuto, ma posso sbagliarmi).


 Ping o di un Traceroute e la velocità di uno scarico FTP.
Vorrei obiettare.
Le velocita'  indicate dai  due programmi sono  direttamente collegate
alla capacita' del percorso in esame di far viaggiare i dati. Maggiore
e'  la  capacita' di   trasportare  dati,  piu' velocemente  avrai  la
risposta. Con  questa capacita' consideri  non solo la velocita' delle
linee fisiche tra un nodo e l'altro,  ma anche la capacita' dei router
intermedi di smaltire il traffico. 
Quindi piu' rapidamente ricevi la risposta ad un  ping, maggiore e' la
capacita'  di  trasporto  dei  dati,    e   piu'  veloce  risulta   il
trasferimento dati.
Indicativamente  tempi superiori ai   500 ms indicano un  collegamento
affollato, lag di un secondo sono sicuro presagio di guai.
Allo stesso modo, una   percentuale di perdite  superiore al  10% puo'
causare ritardi nella comunicazione (per ogni  perdita di dati bisogna
aspettare  un  timeout che  si   misura in secondi,   non millesimi di
secondo).
