Flux tcp Linux à faible latence

Question

J'ai une application embarquée qui a cette exigence: Un flux de réseau TCP sortant a besoin d'une priorité absolue absolue sur tout le trafic réseau sortant. Si des paquets attendent d'être transférés sur ce flux, ils doivent être les prochains paquets envoyés. Période. La mesure du succès est la suivante: Mesurez la latence de haute priorité quand il n'y a pas de trafic d'arrière-plan. Ajoutez du trafic d'arrière-plan et mesurez à nouveau. La différence de latence devrait être le temps d'envoyer un paquet de faible priorité. Avec un lien de 100Mbps, mtu = 1500, soit environ 150 us. Mon système de test a deux boîtiers Linux reliés par un câble croisé. J'ai essayé beaucoup, beaucoup de choses, et bien que j'aie considérablement amélioré la latence, n'ai pas atteint l'objectif (je vois actuellement 5 ms de latence ajoutée avec le trafic d'arrière-plan). J'ai déjà posté une autre question très spécifique, mais j'ai pensé que je devrais recommencer avec une question générale.

Première question: Est-ce possible avec Linux? Deuxième question: Si oui, que dois-je faire?

• tc?
• Quel qdisc devrais-je utiliser?
• Paramètres du réseau de Tweak Tweak? Lesquels?
• Quelles sont les autres choses qui me manquent?

Merci pour votre aide!

Eric

Mise à jour 04/10/2010: Je mis en place tcpdump à la fois du côté émission et côté réception. Voici ce que je vois sur le côté de transmission (où les choses semblent encombrés):

0 us Send SCP (low priority) packet, length 25208 
200 us Send High priority packet, length 512 

Du côté, je reçois vois:

~ 100 us Receive SCP packet, length 548 
170 us Receive SCP packet, length 548 
180 us Send SCP ack 
240 us Receive SCP packet, length 548 
... (Repeated a bunch of times) 
2515 us Receive high priority packet, length 512 

Le problème semble être la longueur du SCP paquet (25208 octets). Ceci est divisé en plusieurs paquets basés sur le mtu (que j'avais fixé à 600 pour ce test). Cependant, cela se passe dans une couche réseau inférieure que le contrôle du trafic, et donc ma latence est déterminée par la taille maximale du paquet de transmission tcp, pas le mtu! Arghhh ..

Quelqu'un sait-il un bon moyen de définir la taille de paquet maximale par défaut pour TCP sur Linux?

Answer 1

Vous souhaiterez peut-être vérifier les paramètres de votre pilote de carte réseau. Certains pilotes fusionnent les interruptions, ce qui écarte le débit plus élevé pour une latence accrue.

http://www.29west.com/docs/THPM/latency-interrupt-coalescing.html

Aussi, je ne sais pas si la carte réseau est mise en mémoire tampon plusieurs paquets de sortie, mais si elle est, ce sera plus difficile de faire respecter les priorités souhaitées: s'il y a plusieurs paquets de faible priorité tamponnés Dans le NIC, le noyau n'a probablement pas le moyen de dire au NIC «oubliez ce que je vous ai déjà envoyé, envoyez d'abord ce paquet prioritaire».

--- --- mise à jour

Si le problème est longs segments TCP, je crois que vous pouvez contrôler la taille du segment max la couche TCP annonce par l'option mtu sur ip route. Par exemple:

ip route add default via 1.1.1.1 mtu 600 

(Notez que vous devez faire sur le côté recevoir).