Socket TCP a bassa latenza in .NET

Question

Socket TCP a bassa latenza in .NET

#1 da (8 voti)

6

È possibile ottimizzare un'applicazione .NET in esecuzione su una versione server di Windows per una comunicazione TCP a latenza quasi zero? O ci saranno sempre ritardi imprevedibili / inevitabili?

Ad esempio, durante la ricerca di app open source a bassa latenza ho trovato questa applicazione OpenPDC su Github che sembra essere la -facile applicazione standard per "raccolta di dati ad alte prestazioni" utilizzata da numerose utility di tutto il mondo. È anche utilizzato negli articoli accademici come strumento per valutare i ritardi di rete per i dispositivi di misurazione. Eppure, l'applicazione è scritta in .NET e funziona su Windows.

Sono a conoscenza delle "tecniche" utilizzate per ridurre GC in generale (meno generazione di rifiuti, allocazione statica e materiale simile), ma avevo ancora l'idea generale che Windows fosse "non un sistema operativo in tempo reale ", e che nulla può impedire al GC di mettere in pausa la tua app - puoi solo ritardare l'inevitabile.

Qualcosa è cambiato nelle recenti versioni di .NET / Windows Server che consentirebbero a questo tipo di applicazioni di funzionare con latenza prossima allo zero? È possibile che questa e altre applicazioni simili siano scritte in un modo che impedisce completamente la raccolta / blocco dei dati "stop-the-world" a causa della natura non in tempo reale di Windows o non è realistico aspettarsi che questo sia garantito?

windows .net garbage-collection latency tcp

posta user7834712 07.04.2017 - 22:45

fonte

1 risposta

Leggi altre domande sui tag windows .net garbage-collection latency tcp

Un qualsiasi linguaggio di programmazione può dedurre i domini di una funzione dai domini delle sue funzioni di input? Quanto è complessa la documentazione che scrivi? [chiuso]

score 8 · Accepted Answer

For example, while searching for low-latency open source apps I found this OpenPDC application on Github which seems to be the de-facto standard application for "high-performance data collection" used by numerous utilities around the world. It's even used in academic articles as the tool for assessing network delays for the measurement devices. And yet, the application is written in .NET, and runs on Windows.

Il numero di applicazioni che hanno requisiti hard in tempo reale potrebbe essere inferiore a quello che pensi. Tieni anche presente che prestazioni elevate possono significare throughput elevato , non bassa latenza . Queste sono due metriche diverse, a volte in disaccordo.

Se preferisci la latenza bassa, disabilita l'algoritmo di Nagle: link .

I am aware of "techniques" used to reduce GC in general (less garbage generation, static allocation, and similar stuff), but I still had the general idea that that Windows is "not a real-time OS", and that nothing can prevent the GC from pausing your app - you can only delay the inevitable.

I collezionisti contemporanei possono raccogliere alcuni rifiuti nelle discussioni in background senza mettere in pausa il mondo. Molti GC ti danno anche la possibilità di controllare quando possono verificarsi pause GC, incluso .NET:

link

Anche prima, a meno che non si generi molta spazzatura, le pause GC sono spesso abbastanza brevi da non costituire un problema, specialmente nel contesto di reti in cui ritardi di 100 ms solo instradando i pacchetti su Internet attraverso diversi router non sono infrequenti. Il GC potenzialmente mettendo in pausa la tua app anche solo per pochi millisecondi in questo contesto non è probabilmente un problema. I sistemi operativi per scopi generali possono sospendere i thread più a lungo, solo per condividere la tua CPU con altri processi.

Has something changed in recent .NET/Windows Server versions which would allow this kind of applications to run with near zero latency? Is it possible that this and other similar applications are written in a way which completely prevents "stop-the-world" garbage collection/blocking due to Windows non-real-time nature, or is it unrealistic to expect this to be guaranteed?

C'è una grande differenza tra "esecuzione con latenza quasi zero per la maggior parte del tempo" e "garanzia di esecuzione con latenza quasi zero per tutto il tempo, in qualsiasi circostanza."

Direi che il primo è stato abbastanza possibile in Windows e .NET per un po 'di tempo - il cambiamento più recente sono consapevole dell'adozione di GC simultanei - mentre il secondo potrebbe significare che il protocollo TCP non ha mai è stata un'opzione per te, per non garantire abbastanza.