3. Cos’è PCHAR
Pchar è un programma opensource che consente di misurare la larghezza di
banda, la latenza e la perdita di informazioni lungo una comunicazione punto
a punto attraverso la rete Internet.
Si basa sulla reimplementazione del programma pathchar, la cui prima
versione è stata rilasciata nel 1997.
Funziona con lo stesso meccanismo adottato dall‟utility traceroute, in grado di
calcolare il numero dei nodi intermedi in una rete e definirne la latenza.
4. Come funziona pchar
1. Pchar invia pacchetti “sonda” attraverso la rete differenziandone la dimensione
2. Successivamente analizza i messaggi ICMP di ritorno dai router intermedi
3. Dalla misurazione dei tempi di risposta dei pacchetti di dimensione
diversa, pchar è in grado di stimare la banda e il tempo RTT
5. Come funziona PCHAR
L'analisi è effettuata basandosi sul seguente modello di network:
1. Prima di lasciare il nodo i-1, il pacchetto aspetta in coda l'instradamento verso i
2. Il pacchetto viene spedito nella rete secondo la funzione direttamente proporzionale alla
dimensione del pacchetto: latenza + dimensione / banda
3. Al nodo n, il pacchetto aspetta in coda nuovamente fino a quando il router lo processa e
genera il pacchetto di errore
4. Il pacchetto di errore aspetta in coda nel nodo i, quindi ritorna al nodo i-1 con il tempo di
trasmissione latenza + dimensione / banda
6. Come funziona pchar
Il round trip time RTT dal nodo i-1 al nodo i e ritorno è così calcolato:
rtt = q1 + (lat + dim_packet / bw) + q2 + forward + q3 + (lat + dim_error / bw) + q4
Per semplificare questa espressione sono possibili tre assunzioni:
la dimensione del pacchetto di errore è talmente piccola che si può considerare
trascurabile. Quindi dim_error / bw = 0
il tempo di processo è trascurabile
se si effettuano un lungo numero di misurazioni di uno stesso percorso, i primi pacchetti
inviati faranno in modo che il il ritardo nelle code durante il round trip sia trascurabile.
Eliminando i termini trascurabili si ottiene:
rtt = (lat + dim_packet / bw) + lat
7. Esempi
TEST RETE DOMESTICA: TEST RETE DOMESTICA:
fure@Andrea ~/Desktop/pchar-1.5 $ sudo ./pchar 192.168.1.10 fure@Andrea ~/Desktop/pchar-1.5 $ sudo ./pchar 192.168.1.100
pchar to 192.168.1.10 (192.168.1.10) using UDP/IPv4 pchar to 192.168.1.100 (192.168.1.100) using UDP/IPv4
Using raw socket input Using raw socket input
Packet size increments from 32 to 1500 by 32 Packet size increments from 32 to 1500 by 32
46 test(s) per repetition 46 test(s) per repetition
32 repetition(s) per hop 32 repetition(s) per hop
0: 192.168.1.15 (Andrea.local) 0: 192.168.1.15 (Andrea.local)
Partial loss: 0 / 1472 (0%) Partial loss: 6 / 1472 (0%)
Partial char: rtt = 2.135705 ms, (b = 0.000721 ms/B), r2 = 0.993529 Partial char: rtt = 1.523985 ms, (b = 0.000552 ms/B), r2 = 0.992269
stddev rtt = 0.008092, stddev b = 0.000009 stddev rtt = 0.005934, stddev b = 0.000007
Partial queueing: avg = 0.000672 ms (931 bytes) Partial queueing: avg = 0.000498 ms (901 bytes)
Hop char: rtt = 2.135705 ms, bw = 11091.113733 Kbps Hop char: rtt = 1.523985 ms, bw = 14494.917574 Kbps
Hop queueing: avg = 0.000672 ms (931 bytes) Hop queueing: avg = 0.000498 ms (901 bytes)
1: 192.168.1.10 (192.168.1.10) 1: 192.168.1.100 (HPL7680.local)
Path length: 1 hops Path length: 1 hops
Path char: rtt = 2.135705 ms r2 = 0.993529 Path char: rtt = 1.523985 ms r2 = 0.992269
Path bottleneck: 11091.113733 Kbps Path bottleneck: 14494.917574 Kbps
Path pipe: 2960 bytes Path pipe: 2761 bytes
Path queueing: average = 0.000672 ms (931 bytes) Path queueing: average = 0.000498 ms (901 bytes)
Start time: Tue May 19 19:16:46 2009 Start time: Tue May 19 20:50:14 2009
End time: Tue May 19 19:22:58 2009 End time: Tue May 19 20:56:42 2009
9. Esempi
Principali parametri
./pchar [-a analysis] [-b burst] [-c] [-d debuglevel] [-g gap] [-G gaptype] [-h] [-H hops] [-I increment] [-m mtu] [-n] [-p
protocol] [-P port] [-q] [-R reps] [-s hop] [-t timeout] [-T tos] [-v] [-V] [-w file] -r file | host]
-a analysis Set analysis type (default is lsq)
lsq Least sum of squares linear fit
kendall Linear fit using Kendall's test statistic
lms Least median of squares linear fit
lmsint Least median of squares linear fit (integer computations)
-b Burst size (default = 1)
-c Ignore route changes
-g gap Inter-test gap in seconds (default = 0.25)
-I increment Packet size increment (default = 32)
-m mtu Maximum packet size to check (default = 1500)
-M mode Operational mode (defaults to pchar)
pchar Path characterization
trout Tiny traceroute
-p protocol Network protocol (default is ipv4udp)
ipv4udp UDP over IPv4
ipv4raw UDP over IPv4 (raw sockets)
ipv4icmp ICMP over IPv4 (raw sockets)
ipv6icmp ICMPv6 over IPv6 (raw sockets)
ipv6tcp TCP over IPv6
ipv6udp UDP over IPv6
-R reps 9
Repetitions per hop (default = 32)
10. Problemi
Un problema che affligge pchar è l'esistenza di collegamenti attraverso la rete fatti di
pipes parallele. Se in questo collegamento viene inviato un intero pacchetto in una delle
due pipe, invece di spezzarlo, quel link e conseguentemente la banda risulterà uguale a
quella della singola pipe.
Purtroppo non vi è una valida soluzione per questo problema.
Un altro problema è causato dai pacchetti che superano l'MTU di un collegamento. Un
pacchetto che supera l'MTU verrà frammentato in pacchetti più piccoli e un pacchetto di
errore verrà inviato non appena il primo pacchetto arriverà all'ennesimo nodo.
Anche in questo caso non vi è una valida soluzione, poiché anche settando il flag “don’t
fragment” nel pacchetto ciò che si ottiene è una risposta ICMP dal primo nodo in cui
sarà necessario frammentare il pacchetto.
11. Problemi
Un problema invece che pchar è in grado di affrontare e che solerte è causa di
problemi significativi, è l‟intercambiabilità del percorso (alternate routing).
L„intercambiabilità del percorso è la tendenza di modificare il percorso tra due host
nel tempo, tipicamente tra poche possibilità.
Fortunatamente la maggior parte (91%) dei percorsi in Internet rimane immutato per
ore.
La corrente versione di pchar cerca di fissare il primo percorso trovato e rifiuta i
successivi percorsi diversi dal primo. Se capita di analizzare il primo nodo il quale ha
alta probabilità di cambiamento, vi è una probabilità elevata di perdere molti
pacchetti. Inoltre se il primo nodo non è il più vicino, la stima per i nodi successivi
può essere poco accurata.
12. Conclusioni
Con l'utilizzo della versione attuale di pchar abbiamo trovato che:
la stima delle latenze dei collegamenti è relativamente semplice; si basa sulla latenza
dei collegamenti interessati e non è direttamente calcolabile tramite pchar
la stima della banda è più difficile, perchè la differenza dell'rtt tra il pacchetto più
grande e quello più piccolo è piccola comparata con la misura degli errori. Maggiore
è la banda, più difficile è la sua stima
la chiave per avere una buona stima della banda è di inviare abbastanza pacchetti tali
che uno di essi attraversi l'intero percorso, senza incorrere in ritardi delle code. Se la
lunghezza del percorso aumenta, il numero di pacchetti da inviare per avere una
buona stima aumenta rapidamente