java - Problemi con MulticastSocket su Windows Server 2008

Question

Ho un'applicazione java che utilizza alcune istanze MulticastSocket per ascoltare in alcuni feed multicast UDP. Ciascuno di questi socket è gestito da un thread dedicato.
Il thread legge ciascun datagramma, ne analizza il contenuto e scrive nel log (log4j) l'ID della sequenza del pacchetto (lungo) e il timestamp ricevuto dal datagramma.

Quando provo a fare funzionare 2 istanze della stessa applicazione su un Windows Server 2008 R2, con 2 * 6 core e confrontare i 2 registri creati dai 2 applicazioni, ho notato che molto spesso i tempi dei pacchetti non è lo stesso

I più pacchetti vengono ricevuti dalle 2 applicazioni contemporaneamente (milis), ma spesso c'è una differenza di circa 1-7ms diff tra il tempo di ricezione dello stesso pacchetto dai 2 applicazioni.

Ho provato ad allocare più buffer nella scheda NIC e ho anche aumentato il buffer di lettura del socket. Inoltre ho provato a ridurre le esecuzioni di GC e uso anche -verbose: gc e posso vedere che i tempi di GC e la differenza di temporizzazione problematica non si verificano allo stesso tempo. Questo mi consente di presumere che il mio problema non sia legato al GC.

Non è stato rilevato alcun problema di pacchetti di rilascio e non è probabile un problema di larghezza di banda.

Idee/Opinioni sono i benvenuti. Grazie.

Answer 1

Per impostazione predefinita, la frequenza di interruzione del timer di Windows è 100 Hz (1 tick per 10 ms). Ciò significa che il sistema operativo non può garantire che i thread Java vengano riattivati ​​con maggiore precisione.

Ecco un estratto da un eminente James Holmes article circa la sincronizzazione in Java - potrebbe essere il vostro caso:

per gli utenti Windows, in particolare su sistemi dual-core o multi-processore (e sembra più comunemente su x64 Sistemi AMD) se si verifica un comportamento irregolare della temporizzazione in Java o in altre applicazioni (giochi, presentazioni multimediali) sul proprio sistema, quindi provare ad aggiungere l'opzione/usepmtimer nel file boot.ini.

PS: in nessun modo io sono credibili nel campo della ottimizzazione delle prestazioni di Windows, anche a partire da Windows 2008 HPET è supportato, ma come si è legato alla frequenza del timer interrupt è un mistero per me.

Answer 2

7 ms è un ottimo risultato per una macchina a 6 core, e la deriva in java sarà molto più alta di quella in cui si immette il garbage collector. Non dimenticare che java runtime ha il proprio overhead.