Dai la priorità a UDP su FTP, SCP, ecc. In Linux

Ho una configurazione in cui un sistema Linux "master" comunica con 3 sistemi "slave" che eseguono anche Linux su un'interfaccia Ethernet dedicata (solo il master e i 3 slave). Gli slave inviano i dati al master via UDP ogni 5 ms circa. Inoltre, il master ha app che estraggono continuamente file da tutti e 3 gli slave tramite protocolli FTP, SCP, ecc.

I pacchetti UDP devono essere raccolti dal master il più rapidamente possibile, preferibilmente entro 3-4 ms. Quando eseguo l'installazione con solo l'app di ricezione UDP in esecuzione sul master, vedo che questa condizione è facilmente soddisfatta. Tuttavia, quando FTP / SCP / ecc. anche le app rimangono in esecuzione, ci sono picchi nel tempo di ricezione. La dimensione dei file trasferiti è piuttosto inferiore, ma un secondo file viene recuperato da ogni slave circa ogni secondo circa.

Il fatto che i risultati siano buoni quando si esegue l'installazione senza le app di trasferimento file attive indica che la "messa in coda / programmazione" della rete Linux sembra dare una priorità simile sia a UDP che agli altri protocolli. Forse sta addirittura trattenendo UDP se è attivo un FTP?

C'è un modo per dire a Linux (programmaticamente / comandi) di dare la massima priorità alla comunicazione UDP e "mettere in pausa" altre cose come il trasferimento di file quando un messaggio UDP è pronto per la ricezione?

Modifica 1: li ho aggiunti per controllare il traffico in base al tipo di protocollo (UDP è il protocollo 17)

tc qdisc add dev eth0 root handle 10: prio
tc filter add dev eth0 parent 10: protocol ip prio 1 u32 match ip protocol 17 0xff flowid 10:1
tc filter add dev eth0 parent 10: prio 3 protocol all u32 match u32 0 0 flowid 10:3

Il terzo è quello che penso sia un "filtro per tutte le partite". Tuttavia, questo non ha fatto differenza. Ottengo ancora gli stessi picchi.

— John Smith
fonte

Non è così che funziona UDP, non viene "raccolto" dallo slave, viene inviato alla cieca dallo slave e il master lo riceve. se noti ritardi, è perché la coda di rete è piena sugli slave o sul master o perché il master non sta pianificando correttamente per il tuo caso.

— djsmiley2k,

5ms implica 5 millisecondi o volevi dire 5 minuti. Se il primo è una folle commissione perché Linux non è un sistema operativo in tempo reale. Puoi dare la priorità al traffico aggiungendo limitatori di velocità / code - vorrai farlo sui mittenti. "Controllo avanzato dei pacchetti" di Google per istruzioni sulla gestione del traffico. Cerca anche di ridurre le dimensioni MTU di tutti i dispositivi sulla tua lan. Ciò ridurrà la produttività ma ridurrà anche la latenza.

— davidgo,

Sì, intendevo 5 millisecondi e mi rendo conto che Linux non è un RTOS. Detto questo, ho anche detto che quando si esegue l'app UDP da sola, i ritardi sono ben entro i limiti. È solo quando diventa attiva anche l'app FTP che il problema inizia. Questa è una rete gigabit riservata solo a queste 4 schede senza luppolo aggiunto, ecc. Ho cercato nel controllo del traffico Linux e creato 2 filtri. Tuttavia, non sembrano avere effetto. Si prega di guardare la modifica nella domanda.

— John Smith,

Primo: Linux non è un sistema operativo in tempo reale. Non c'è modo di dire al kernel che alcune applicazioni devono reagire a qualche evento in un determinato intervallo di tempo, come 3-4 ms, e di garantire che ciò avvenga. Quindi ogni volta che il sistema viene caricato, dovrai presumere che ci saranno ritardi.

Detto questo, puoi ottimizzare le cose a favore della tua applicazione di ricezione dei pacchetti UDP:

Linux ha il controllo del traffico di rete (vedi ad esempio Traffic Control HOWTO , esempio di script per DSL con larghezza di banda limitata ) che puoi usare per impostare code diverse con priorità diverse, ad esempio per i tuoi pacchetti UDP e per pacchetti di grandi dimensioni.
Linux ha cgroups (gruppi di controllo), che è possibile utilizzare per assegnare priorità e limiti di I / O diversi per il processo di ricezione UDP e i processi ftpd/ sshdecc., Poiché suppongo che l'I / O del disco da altri processi possa anche bloccare il tuo Applicazione di ricezione dei pacchetti UDP (esperimento per scoprire se è vero).

Ancora: non c'è modo di garantire nulla.

— dirkt
fonte

Ho cercato il controllo del traffico eseguito questi. "tc qdisc aggiungi dev eth0 root handle 10: prio", "filtro tc aggiungi dev eth0 parent 10: protocollo ip prio 1 u32 abbina protocollo ip 17 0xff flowid 10: 1", "tc filter aggiungi dev eth0 parent 10: protocollo prio 3 all u32 match u32 0 0 flowid 10: 3 ". Il terzo è quello che penso sia un" filtro per tutte le partite ". Tuttavia, questo non ha fatto differenza. Ottengo ancora gli stessi picchi.

— John Smith,

Non posso eseguire il debug in remoto del tuo problema, scusa. Il primo passo sarebbe scoprire se l'accodamento dei pacchetti è effettivamente correlato ai picchi, vale a dire ottenere una registrazione su come vengono utilizzate le code. E se è lo scheduler I / O che sta causando i picchi, ovviamente il controllo del traffico non aiuterà ...

— Dirkt

Apprezzo sicuramente il tuo aiuto! Questi filtri (li ho ora aggiunti alla domanda stessa. Formattati correttamente) ti sembrano corretti? Come posso verificare se le 3 bande prio vengono utilizzate come previsto? Non riesco a trovare alcun riferimento su questo.

— John Smith,