Passa al contenuto principale
"Siamo appena passati da un T1 (1,544 mbps) a un T3 (44,736 mbps), quindi perché ci vogliono ancora 90 minuti per copiare quel file?

 

La risposta semplice è che una maggiore capacità non è la stessa dei byte più veloci. Se si aumenta la capacità di quasi 29 (44.736 / 1.544) volte si può essere in grado di copiare 29 file negli stessi 90 minuti, ma probabilmente non sarà possibile copiare quel file più velocemente. Ho toccato questo argomento l'anno scorso nel blog intitolato "Application Performance Problems and Latency", ma penso che il trasferimento dei file e il copy_file richiedano un blog più focalizzato.

 

La chiave ha a che fare con le dimensioni della finestra, cioè quanti byte può inviare l'host/applicazione che invia senza doversi fermare ad aspettare un riscontro da parte dell'host/applicazione ricevente. Alcune applicazioni come FTP non hanno un riconoscimento a livello di applicazione e si affidano al TCP. In questo caso la dimensione della finestra si basa su ciò che il livello TCP dell'host remoto pubblicizza, fino a 64K byte, che è il massimo che STCP supporta. Alcune applicazioni hanno una finestra di livello applicazione, per queste applicazioni la finestra limitante è la più piccola delle finestre TCP e delle applicazioni.
La portata massima è calcolata come

 

W / RTT = T
Dove
W è la dimensione della finestra in byte
RTT è il tempo di andata e ritorno in secondi
T è la velocità di trasmissione in byte al secondo
Il tempo di andata e ritorno è il tempo necessario per inviare alcuni dati e ottenere il riconoscimento. Per le grandi distanze, vale a dire attraverso il paese, questo tempo si basa principalmente sulla distanza che i byte devono percorrere e sulla velocità di elaborazione di tutte le apparecchiature di rete tra i punti finali. La velocità di elaborazione dell'host ricevente, le dimensioni dei pacchetti (valore TCP MSS, vedi "Un modo semplice per migliorare il throughput attraverso le sottoreti") e naturalmente la larghezza di banda del collegamento più lento giocano un ruolo minore.

 

Ad esempio, se la RTT è di 0,050 secondi e la finestra è di 64K la velocità massima di trasmissione sarà di 1.310.720 byte al secondo (64 * 1024 / 0,050). Finché la capacità inutilizzata del collegamento è maggiore del throughput, l'aumento della capacità non accelererà il tempo di trasferimento.
T è la massima produttività possibile. Nulla di ciò che si fa (a parte aumentare la finestra o ridurre la RTT) può far andare le cose più velocemente MA condizioni di rete ostili possono far andare le cose molto più lentamente.

 

La stima del tempo di trasferimento è solo la divisione della dimensione del file per il throughput

 

F/ W * RTT = Ti
Dove
F è la dimensione del file in byte
W è la dimensione della finestra in byte
RTT è il tempo di andata e ritorno in secondi
Ti è il tempo in secondi per trasferire il file

 

OSL ha una dimensione della finestra dell'applicazione di 4K, il file system OpenVOS riporta le dimensioni dei file in blocchi di 4K byte in modo da stimare il tempo necessario per copiare un file tra due sistemi OpenVOS utilizzando il comando copy_file è semplicemente

 

F * RTT = Ti
Dove
F è la dimensione del file in blocchi
RTT è il tempo di andata e ritorno in secondi
Ti è il tempo in secondi per trasferire il file

 

Su un link con un RTT di 0,050 secondi, OSL impiegherà poco più di 41 minuti per copiare un file di 50.000 blocchi (50.000 * 0,05). Il throughput massimo sarà di 81.920 byte al secondo (4096 / 0,050). Finché la capacità di rete inutilizzata del vostro collegamento è superiore a 81.920 byte al secondo, l'aggiunta di capacità non riduce il tempo necessario per copiare il file.

 

Il modo più semplice per misurare il tempo di andata e ritorno è con il ping. Sfortunatamente, il ping non fornisce un solo numero per la RTT, ma più numeri e i numeri possono variare in modo significativo, ad esempio:

 

ping 172.16.1.80
Pinging host 172.16.1.80 : 172.16.1.80
ICMP Echo Reply:TTL 53 time = 418 ms
ICMP Echo Reply:TTL 53 time = 107 ms
ICMP Echo Reply:TTL 53 time = 91 ms
ICMP Echo Reply:TTL 53 time = 100 ms
Host 172.16.1.80 replied to all 4 of the 4 pings
ready 12:03:15

 

Se siete interessati a calcolare la migliore produttività possibile, utilizzate il numero più basso. Se siete interessati ad una stima ragionevole di ciò che dovreste aspettarvi, usate un ping di 10, gettate i due numeri più alti e i 2 più bassi e fate la media del resto.

 

ping 172.16.1.80 -count 10
Pinging host 172.16.1.80 : 172.16.1.80
ICMP Echo Reply:TTL 53 time = 89 ms
ICMP Echo Reply:TTL 53 time = 96 ms
ICMP Echo Reply:TTL 53 time = 95 ms
ICMP Echo Reply:TTL 53 time = 105 ms
ICMP Echo Reply:TTL 53 time = 186 ms
ICMP Echo Reply:TTL 53 time = 87 ms
ICMP Echo Reply:TTL 53 time = 90 ms
ICMP Echo Reply:TTL 53 time = 90 ms
ICMP Echo Reply:TTL 53 time = 89 ms
ICMP Echo Reply:TTL 53 time = 96 ms
Host 172.16.1.80 replied to all 10 of the 10 pings
ready 12:12:39
calc 96 + 95 + 90 + 90 + 89 + 96
556
ready 12:12:49
calc 556 / 6
92.6666666666667
ready 12:12:57

 

Come ho detto sopra, una rete ostile può rallentare le cose in modo significativo. I timeout del ping ne sono un'indicazione. Quindi qualsiasi timeout significa che questi calcoli sono probabilmente molto ottimistici. I trasferimenti possono anche essere rallentati da dischi occupati e/o CPU che impediscono al mittente di leggere e inviare i dati il più velocemente possibile o fanno sì che il ricevitore legga i dati più lentamente del suo tasso di arrivo, ritardando le conferme dell'applicazione (aumentando il tempo di andata e ritorno) ed eventualmente riempiendo i buffer di ricezione TCP che fanno sì che l'host di invio smetta di trasmettere. L'unico modo per sapere se una di queste condizioni è applicabile è con una traccia di pacchetto.

© 2024 Stratus Technologies.