Priorisieren Sie UDP über FTP, SCP usw. in Linux

717
John Smith

Ich habe ein Setup, bei dem ein "Master" -Linuxsystem mit 3 "Slave" -Systemen kommuniziert, die ebenfalls Linux auf einer dedizierten Ethernet-Schnittstelle ausführen (nur der Master und die 3 Slaves). Die Slaves senden etwa alle 5 ms Daten über UDP an den Master. Darüber hinaus verfügt der Master über Apps, die kontinuierlich Dateien von allen 3 Slaves über die Protokolle FTP, SCP usw. abrufen.

Die UDP-Pakete müssen vom Master so schnell wie möglich gesammelt werden, vorzugsweise innerhalb von 3-4 ms. Wenn ich das Setup nur mit der UDP-Empfangs-App auf dem Master ausführen, sehe ich, dass diese Bedingung leicht erfüllt ist. Wenn jedoch FTP / SCP / etc. Apps laufen auch, es gibt Spitzen in der Empfangszeit. Die Größe der übertragenen Dateien ist ziemlich geringer, aber von jedem Slave wird etwa jede Sekunde eine neue Datei abgerufen.

Die Tatsache, dass die Ergebnisse gut sind, wenn das Setup ausgeführt wird, ohne dass die Dateiübertragungs-Apps aktiv sind, weist darauf hin, dass das "Queueing / Scheduling" des Linux-Netzwerks sowohl UDP als auch den anderen Protokollen eine ähnliche Priorität einräumt. Vielleicht hält es sogar UDP ab, wenn ein FTP läuft?

Gibt es eine Möglichkeit, Linux (programmgesteuert / Befehle) mitzuteilen, der UDP-Kommunikation die höchste Priorität zu geben und andere Dinge wie die Dateiübertragung "anzuhalten", wenn eine UDP-Nachricht für den Empfang bereit ist?

Edit 1: Ich habe diese hinzugefügt, um den Verkehr basierend auf dem Protokolltyp zu steuern (UDP ist Protokoll 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 

Der dritte ist meiner Meinung nach ein "All-Match-Filter". Dies machte jedoch keinen Unterschied. Ich bekomme immer noch die gleichen Stacheln.

0
So funktioniert UDP nicht, es wird nicht vom Slave „abgeholt“, es wird blind vom Slave gesendet und der Master empfängt es. Wenn Sie Verzögerungen sehen, liegt dies entweder daran, dass die Netzwerkwarteschlange auf den Slaves voll ist oder der Master oder der Master für Ihren Fall nicht ordnungsgemäß terminiert. djsmiley2k vor 7 Jahren 1
Bedeutet 5ms 5 Millisekunden oder meinten Sie 5 Minuten? Wenn Sie sich in einem Dummkopf befinden, ist Linux kein Echtzeitbetriebssystem. Sie können den Datenverkehr priorisieren, indem Sie Ratenbegrenzer / -warteschlangen hinzufügen. Sie sollten dies für die Absender tun. Google "Advanced Packet Control" für Howtos im Verkehrsmanagement. Beachten Sie auch die Reduzierung der MTU-Größen aller Geräte in Ihrem LAN. Dies verringert den Durchsatz, aber auch die Latenz. davidgo vor 7 Jahren 0
Ja, ich meinte 5 Millisekunden und ich weiß, dass Linux kein Echtzeitbetriebssystem ist. Das heißt, ich habe auch erwähnt, dass die Verzögerungen bei der alleinigen Ausführung der UDP-App durchaus innerhalb der Grenzen liegen. Erst wenn auch die FTP-App aktiv wird, beginnt das Problem. Dies ist ein Gigabit-Netzwerk, das nur für diese 4 Boards ohne zusätzliche Hops reserviert ist. Ich habe in der Linux-Verkehrssteuerung nachgeschlagen und 2 Filter erstellt. Sie scheinen jedoch nicht wirksam zu sein. Bitte schauen Sie sich die Bearbeitung in der Frage an. John Smith vor 7 Jahren 0

1 Antwort auf die Frage

1
dirkt

Erstens: Linux ist kein Echtzeitbetriebssystem. Es gibt keine Möglichkeit, dem Kernel mitzuteilen, dass einige Anwendungen innerhalb eines bestimmten Zeitraums, wie etwa 3-4 ms, auf ein Ereignis reagieren müssen, und geben eine Garantie dafür, dass dies geschieht. Wenn das System geladen ist, müssen Sie also davon ausgehen, dass es zu Verzögerungen kommt.

Das heißt, Sie können die Dinge für Ihre UDP-Paket-Empfangsanwendung optimieren:

  • Linux verfügt über eine Netzwerkverkehrskontrolle (siehe z. B. Traffic Control HOWTO, Beispielskript für DSL mit begrenzter Bandbreite ), mit der Sie verschiedene Warteschlangen mit unterschiedlichen Prioritäten einrichten können, z. B. für Ihre UDP-Pakete und für große Pakete.

  • Linux hat cgroups (Kontrollgruppen), mit denen Sie verschiedene E / A-Prioritäten und -Limits für den UDP-Empfangsprozess und die Prozesse ftpd/ sshdetc. festlegen können, da ich davon ausgehen kann, dass Festplatten-E / A durch andere Prozesse auch Ihr System blockieren kann UDP-Paketempfangsanwendung (testen Sie, ob dies wahr ist).

Nochmals: Es gibt keine Möglichkeit, etwas zu garantieren.

Ich schaute auf, dass die Verkehrssteuerung diese lief. "tc qdisc add dev eth0 root handle 10: prio", "tc filter add dev eth0 eltern 10: protokoll ip prio 1 u32 passen ip-protokoll 17 0xff flowid 10: 1", "tc filter add dev eth0 eltern 10: prio 3 protokoll alle u32 passen zu u32 0 0 flowid 10: 3 ". Der dritte ist meiner Meinung nach ein" all match filter ". Dies machte jedoch keinen Unterschied. Ich bekomme immer noch die gleichen Stacheln. John Smith vor 7 Jahren 0
Ich kann Ihr Problem nicht remote debuggen, sorry. Der erste Schritt besteht darin, herauszufinden, ob die Paketwarteschlange tatsächlich mit Ihren Spitzen zusammenhängt, dh Sie müssen ein Protokoll darüber erhalten, wie Ihre Warteschlangen verwendet werden. Und wenn es der I / O-Scheduler ist, der die Spitzen verursacht, dann hilft natürlich die Verkehrskontrolle nicht ... dirkt vor 7 Jahren 0
Ich bin auf jeden Fall dankbar für Ihre Hilfe! Sehen diese Filter (ich habe sie jetzt der Frage selbst hinzugefügt. Richtig formatiert) für Sie richtig aus? Wie überprüfe ich, ob die 3 Prio-Bänder erwartungsgemäß verwendet werden? Ich kann darauf keinen Hinweis finden. John Smith vor 7 Jahren 0