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


0

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.


1
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,

Risposte:


1

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.


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,
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.