Requêtes ultra-rapides à l'aide de paquets UDP

10

J'implémente un système où un périphérique sur un réseau interroge à une fréquence très élevée (des centaines ou des milliers de requêtes par seconde) en envoyant un petit paquet UDP avec environ 8 octets de données. Ceci est reçu par une autre application, peut-être sur un autre appareil, qui effectue un traitement très simple et envoie le résultat de quelques octets encapsulé dans un autre paquet UDP.

Je voudrais savoir quels types de temps aller-retour sont possibles avec du matériel typique, où les systèmes communicants sont peut-être connectés via Ethernet câblé à quelques mètres l'un de l'autre, en tenant compte des délais de propagation et de transmission, etc.

D'autres réflexions et suggestions sont également les bienvenues.

ethernet latency speed

— John Smith
source

2

vous pouvez voir des latences dans des dizaines ou des centaines de microsecondes ... certainement une latence inférieure à la milliseconde ... d'après votre description, il semble que vous envisagiez un système de trading financier ... les latences que vous demandez dépendent très de votre matériel spécifique et vous feriez bien mieux de faire des tests que de demander des conseils gratuits

— Mike Pennington

Merci beaucoup pour votre réponse. Il ne s'agit pas en fait d'un système commercial financier dans ce cas. Je voulais juste une vague idée de ce qui était possible avant de commencer la mise en œuvre, plus comme une étude de faisabilité qu'autre chose.

— John Smith

11

Un exemple Juniper MX80 a un retard d'entrée> de sortie d'environ 8us, sur un commutateur de coupure à faible latence, il peut être <1us (peut-être 0,7us). (N'oubliez pas que le commutateur de coupure ne peut pas effectuer la coupure à 100% du temps, uniquement lorsque le port de sortie est inactif!)

1 km de fibre représente une latence d'environ 5us (encore une fois, dans une seule direction).

Le délai de sérialisation @ 10G pour une charge utile de taille minimale (46B) est d'environ 67ns (0,067us), en augmentant la vitesse de la liaison, vous diminuez le délai de sérialisation.

L'en-tête IP est de 20B, l'en-tête UDP est de 8B, vos données sont de 8B, vous n'avez donc que 36B de données, ce qui signifie que votre charge utile Ethernet comprendra 10B de poubelle que vous DEVEZ envoyer, c'est-à-dire si vous avez quelque chose à ajouter à votre charge utile, ajoutez-le, il a 0 coût de latence.

J'espère que vous pouvez extrapoler RTT à partir de ceux-ci, en multipliant le délai de l'appareil par le nombre d'appareils et en ajoutant 5us pour chaque kilomètre de fibre, puis multipliez cela par 2.

Je ne peux pas résister à ajouter quelques réflexions sur le HFT.

Selon ce volume HFT divisé par deux entre 2009 et 2012. Ce qui suggère que les gains faciles ont disparu. J'adorerais voir des articles scientifiques ou simplement des données réelles sur la latence HFT et son effet sur le profit. Je soupçonne que la latence qui affecte les bénéfices commerciaux est d'une autre ampleur que la latence dont nous parlons en ce moment. Un de mes amis qui construit un réseau pour l'un des plus grands échanges semble penser que ce sont juste les clients qui font «inférieur == mieux» sans comprendre les échelles.
Je peux complètement comprendre à quel point le HFT était utile lorsque peu de gens le faisaient, quand on pouvait observer le marché A ne pas voir le changement, le marché B le voit et en profite. Certains parlent de l'utilisation de la réglementation pour arrêter le HFT en taxant chaque transaction, ce qui en coûte cher à tout le monde, je ne pense pas que ce sera nécessaire, je pense que la fenêtre d'opportunité se ferme déjà.

— ytti
source

Excellente réponse et très informative, merci. Même quelques réflexions personnelles sur HFT!

— John Smith

1

@JohnSmith, ne négligez pas de considérer le délai introduit à l'intérieur de vos points de terminaison (comme le planificateur du système d'exploitation ou le traitement du noyau) ... cela peut contribuer de manière significative au délai que j'ai mentionné dans un commentaire précédent.

— Mike Pennington

Excellent point sur l'utilisation d'une taille de paquet minimale complète à un coût de latence de 0.

— generalnetworkerror

1

Je pense que sur du matériel semi-réglé conventionnel, vous devriez être capable de:

Sortez de votre pile réseau hôte
Augmentez votre prochaine pile réseau
Sauvegardez cette pile réseau avec votre «nouveau» paquet

En ~ 10 nous à 10gig. Si vous bloquez vraiment les choses, ce nombre peut être considérablement inférieur.

Presque TOUTE la latence que vous allez voir ne provient pas du matériel / des câbles réseau, mais de vos systèmes hôtes. Un interrupteur de coupure raisonnable (Arista, Gnodal, New Cisco, etc.) va être inférieur à 1us.

Commencez par vous assurer que les processus consommant les paquets UDP sont épinglés au même cœur que vos interruptions NIC. À partir de là, assurez-vous que la fusion sur votre carte réseau est désactivée et assurez-vous que vous avez MSI-X et DCA.

Si vous êtes plus sérieux ... consultez OpenOnload de SolarFlare. Ils ont également une excellente suite d'outils pour tester / vérifier les performances.

— radikalus
source