Prestazioni di trasmissione multicast

Question

Abbiamo recentemente completato un'analisi delle prestazioni di invio multicast. Fortunatamente, Java e C si sono comportati in modo quasi identico, poiché abbiamo testato diverse velocità di invio del traffico su Windows e Solaris.

Tuttavia, abbiamo notato che il tempo di inviare un messaggio multicast aumenta all'aumentare del tempo tra le mandate. Più frequentemente chiamiamo invia, meno tempo ci vuole per completare la chiamata di invio.

L'applicazione ci consente di controllare la quantità di tempo che aspettiamo tra la chiamata di invio, di sotto si vede il tempo che aumenta come il ritardo tra i pacchetti sale. Quando si inviano 1000 pacchetti al secondo (1 ms di tempo di attesa), sono necessari solo 13 microsecondi per chiamare send. A 1 pacchetto/secondo (tempo di attesa 1000 ms), il tempo aumenta fino a 20 microsecondi.

Wait time (ms)      us to send 
0         8.67 
1         12.97 
10         13.06 
100         18.03 
1000        20.82 
10000        57.20 

Vediamo questo fenomeno sia da Java che da C e sia su Windows che su Solaris. Stiamo testando su un server Dell 1950, con una scheda di rete a doppia porta Intel Pro 1000. Il micro-benchmarking è difficile, specialmente in Java, ma non pensiamo che questo sia collegato a JITing o GC.

codice Java e la linea di comando che sto utilizzando per i test sono a: http://www.moneyandsoftware.com/2009/09/18/multicast-send-performance/

Answer 1

Alcune teorie:

Il mio primo pensiero è stato che io considero il caching ad essere un fattore qui - se il i compiti e i valori sono ancora in pila o nella recente memoria a breve termine, è possibile che sia in grado di inviarli più velocemente. Con l'aumentare del tempo, la possibilità che sia ancora disponibile diminuisce, quindi in media richiedere più tempo.

Tuttavia, mi aspetto che ci sia un limite superiore se questo fosse il caso ... qualche punto in cui è sempre in cache.

Un ragionamento alternativo è che c'è una perdita di memoria o un peggioramento delle prestazioni nel tempo nell'app/test/piattaforma. Questo anche se (se esiste) significa che più a lungo si aspetta, più a lungo si ha il tempo di degradare le prestazioni, e quindi più tempo ci vorrebbe per inviare.

ANCHE - se si impiegano più tempo tra i pacchetti per inviarli, è possibile superare i timeout di apprendimento dell'indirizzo, sia tabelle IP che tabelle MAC. Se queste tabelle/cache sono scadute, avrebbero bisogno di impararle nuovamente prima di inoltrare il pacchetto.

Buona fortuna!

Answer 2

Il codice per eseguire tali attività è memorizzato nella cache più vicino alla CPU (forse anche ancora nei registri) quando si è appena verificata una chiamata.

Answer 3

Potrebbe essere un artefatto di interrupt coalescenza con la scheda di rete su quel particolare host, controllare questo articolo entro il 29 occidentale sul tema, che mostrano come la latenza può aumentare fino a 125μs su un e1000 NIC,

http://www.29west.com/docs/THPM/latency-interrupt-coalescing.html

Answer 4

Come stai aspettando tra le mandate? Hai provato ad aspettare perché tu non rinunci alla CPU?