Impostazioni TCP a bassa latenza su Ubuntu


10

C'è un server per le misurazioni in esecuzione su Ubuntu nel mio laboratorio. E c'è un programma C, che riceve i dati attraverso la connessione TCP e dovrebbe appena possibile inviare una risposta.

Configurazione

  • CPU: 2 processori x 4 core - CPU Intel (R) Xeon (R) E5345 @ 2.33GHz
  • RAM: 12 GB
  • NIC: Controller Gigabit Ethernet Intel Corporation 80003ES2LAN / Controller Gigabit Ethernet 82546EB
  • Switch di rete: Cisco Catalyst 2960
  • Informazioni sui dati: i blocchi di dati sono disponibili ca. ogni 10 millisecondi. La dimensione del blocco dati è di ca. 1000 byte.

La latenza di rete quando si ricevono pacchetti è molto critica (sono importanti decine di microsecondi). Ho ottimizzato il programma al massimo, ma non ho esperienza di ottimizzazione di Ubuntu.

Cosa può essere configurato in Ubuntu per ridurre il ritardo locale di elaborazione / invio dei pacchetti?


Sì, mi piacerebbe conoscere la marca / modello del server.
ewwhite,

dovresti scavare più a fondo. leggi alcune cose sull'ottimizzazione del kernel per il trading ad alta frequenza. Per esempio un Cisco Sales: cisco.com/c/dam/en/us/products/collateral/switches/…, quindi ottenere una scheda PCI-E decente su entrambi i lati farà risparmiare un po '. Molto probabilmente (a seconda di quanto tempo vuoi spendere per questo) ricostruirai almeno il kernel con impostazioni diverse, rimuovendo un sacco di cose di cui Ubuntu ha bisogno ma non lo fai. Quindi, come ha scritto ewwhite nei commenti, Ubuntu potrebbe non essere perfetto per le impostazioni più basse.
Dennis Nolte,

Con l'hardware elencato, è un'apparecchiatura del 2008 (CPU Intel serie 5300). Allora, non c'erano troppe modifiche hardware speciali a bassa latenza possibili. Impostarei il BIOS di sistema per l'esecuzione in modalità ad alte prestazioni e disabiliterei gli stati C della CPU.
ewwhite,

@ewwhite Sì, hai ragione sulle apparecchiature dell'era 2008. Proverò i tuoi suggerimenti. Grazie!
Alex V,

Qualche possibilità di modificare questo software per TCP_NODELAY?
Matt,

Risposte:


10

Onestamente, non userei Ubuntu per questo ... ma ci sono opzioni che possono essere applicate a qualsiasi variante di Linux.

Ti consigliamo di aumentare i buffer dello stack di rete:

net.core.rmem_default = 10000000
net.core.wmem_default = 10000000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

Se l'applicazione sta scrivendo su disco, potrebbe essere necessario un cambio programmatore / ascensore (ad es. deadlineAscensore).

A livello di server, è possibile modificare il regolatore della CPU e la gestione dell'alimentazione e della frequenza della CPU (P-States, C-States).

A livello di sistema operativo, è possibile modificare la priorità in tempo reale dell'applicazione ( chrt), ottimizzando per ridurre gli interrupt, bloccandola su una CPU o un gruppo di CPU ( taskset) e arrestando eventuali servizi o demoni non necessari.

Puoi anche vedere alcuni suggerimenti su: Come risolvere i problemi di latenza tra 2 host Linux

È difficile diventare più specifici senza conoscere l'hardware o le apparecchiature di rete coinvolte.


3
Questo non è davvero il luogo adatto per dibattiti religiosi. Portalo altrove, come la chat.
Michael Hampton,

1
@MichaelHampton Ci sono stati collegamenti interessanti nella discussione relativi alla domanda: Red Hat Realtime Tuning Guide .
Alex V,

6

Se stai seguendo la strada delle alte prestazioni, in genere ti consigliamo di eseguire il minor numero possibile di altri processi (pianificati) in quanto interferiranno con la tua applicazione.

Linux, come i classici sistemi operativi UNIX, è progettato per eseguire contemporaneamente più applicazioni in modo equo e cerca di prevenire la fame di risorse e tu mirerai al contrario, affamando tutto il resto tranne la tua applicazione. Semplici passaggi a livello di sistema operativo stanno cambiando il buon livello e la priorità in tempo reale della tua applicazione, cambiando lo scheduler o scegliendo un kernel in tempo reale .

Il protocollo TCP / IP è in genere ottimizzato per evitare interruzioni della connessione e rendere disponibile in modo efficiente la larghezza di banda. Per ottenere la latenza più bassa possibile da un collegamento molto veloce, anziché ottenere la massima larghezza di banda possibile da una connessione in cui alcuni collegamenti intermedi sono più vincolati, regolerai l'ottimizzazione dello stack di rete.

 sysctl -a 

ti mostrerà una serie di impostazioni di kernel che puoi sintonizzare. Le impostazioni dipendono dal fatto che si stia utilizzando o meno IPv4 o IPv6 e che cosa esattamente si fa già nella propria applicazione ma di interesse potrebbe essere:

  • net.ipv4.tcp_window_scaling=1 RFC 1323 - supporto per finestre IPV4 di dimensioni superiori a 64 KB - generalmente necessario su reti con larghezza di banda elevata
  • net.ipv4.tcp_reordering=3 Il numero massimo di volte in cui un pacchetto IPV4 può essere riordinato in un flusso di pacchetti TCP senza che il TCP presupponga la perdita dei pacchetti e che inizi lentamente.
  • net.ipv4.tcp_low_latency=1destinato a privilegiare una bassa latenza rispetto a un throughput più elevato; setting = 1 disabilita l'elaborazione prequeue di IPV4 tcp
  • net.ipv4.tcp_sack=0 l'impostazione su 1 abilita il riconoscimento selettivo per IPV4, che richiede l'abilitazione di tcp_timestamps e aggiunge un sovraccarico di pacchetti, che non è necessario se non si verifica la perdita di pacchetti
  • net.ipv4.tcp_timestamps=0 Consigliato solo nei casi in cui è necessario il sacco.
  • net.ipv4.tcp_fastopen=1 Abilitare per inviare i dati nel pacchetto SYN di apertura.

La maggior parte se non tutti sono meglio documentati nel sorgente del kernel .

Naturalmente è possibile codificare socket TCP non elaborati e in gran parte bypassare lo stack TCP / IP del kernel.

Spesso i sistemi altamente ottimizzati funzionano in una rete affidabile e i loro firewall locali (iptables) sono disabilitati.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.