FORTS. Questions relatives à l'application de la loi - page 79

 

Réflexions générales sur les processus à faible latence dans le commerce:

  • lorsque vous passez à des valeurs de 10 ms par tour et moins, vous n' avez pratiquement aucune garantie quant à la stabilité de la latence.
  • si vous avez un tas de réseaux devant vous, la stabilité de la latence est un cadeau, pas une garantie
  • vous n'avez aucun contrôle sur les réseaux de vos pairs, leur bande passante et leur latence.
  • pour avoir une garantie, il faut supprimer tous les intermédiaires du réseau.
  • pour la garantir, vous devez investir dans votre matériel (bande passante, ordinateurs, routeurs) et contrôler le chemin maximal.
  • il faut être un geek et un perfectionniste.


Les courtiers et les systèmes qui sont technogeeks travaillent clairement sur leur infrastructure technologique et investissent pour l'améliorer. Mais tout le monde ne le fait pas, malheureusement.

 
Renat Fatkhullin:

Le terminal indique l'heure locale d'enregistrement/réception du signal sur votre terminal, et non l'heure exacte de chaque étape d'exécution du côté distant.

Dans ce cas, vous avez reçu toutes les réponses (à la fois la confirmation du serveur MT5 et la confirmation du placement de l'ordre sur la bourse) au même moment 029. Comme il existe de nombreux réseaux entre vous, il n'est pas garanti qu'un paquet vous soit livré instantanément dans le temps de ping minimal. Un petit encombrement du réseau ou un manque de bande passante (par exemple chez le courtier) entraînera l'accumulation de paquets qui seront ensuite livrés par lots.

C'est pourquoi vous ne pouvez pas compter les temps des différentes étapes s'il y a des problèmes avec le réseau. Dans un réseau idéal, proche du serveur du courtier, on peut toujours compter sur une certaine garantie de latence minimale et compter le temps des étapes intermédiaires.


La réponse "J'ai un réseau parfait, je ne peux pas me plaindre" n'est pas appropriée. Parce que nous parlons de délais complètement différents, qui sont au-delà de la perception humaine dans des conditions normales.

C'est-à-dire comme ici :

2016.10.10 10:00:05.148 Trades  'xxxxx': buy limit 5.00 RTS-3.17 at 98850
2016.10.10 10:00:05.148 Trades  'xxxxx': sell limit 5.00 RTS-3.17 at 99780
2016.10.10 10:00:05.154 Trades  'xxxxx': accepted buy limit 5.00 RTS-3.17 at 98850
2016.10.10 10:00:05.154 Trades  'xxxxx': accepted sell limit 5.00 RTS-3.17 at 99780
2016.10.10 10:00:05.155 Trades  'xxxxx': buy limit 5.00 RTS-3.17 at 98850 placed for execution in 6.904 ms
2016.10.10 10:00:05.156 Trades  'xxxxx': sell limit 5.00 RTS-3.17 at 99780 placed for execution in 7.850 ms

Pourquoi ne pas faire un journal simple, tel que

Le serveur commercial a reçu un ordre - heure du serveur commercial

Le serveur commercial a donné un ordre à la bourse - temps du serveur commercial

Le serveur commercial a reçu une réponse de la bourse - l'heure du serveur commercial.

Vous auriez alors clos ce long sujet une fois pour toutes.

Ajouté.

Et envoyer ces temps (tous les trois) au lieu d'êtreaccepté etplacé pour l' exécution

 
Nous le ferons peut-être à l'avenir.
 
Renat Fatkhullin:

Réflexions générales sur les processus à faible latence dans le commerce:

Les questions semblent porter sur des centaines ou des milliers de millisecondes.
 
fxsaber:
Les questions semblaient porter sur des centaines et des milliers de millisecondes.

En pratique, après avoir construit une bonne infrastructure et bénéficié de 3-4 ms d'exécution par tour avec des fournisseurs de liquidité soigneusement assemblés, en tant que courtier mature, les gens sont abasourdis quand ils voient des pics périodiques de 700-1500 ms après la mise en production. Et les constructeurs de systèmes parfaits doivent vivre avec et s'adapter.

Voilà donc la réalité : il n'y a aucune garantie de stabilité de la latence minimale.

Surtout dans un environnement comportant autant d'étapes intermédiaires.

 
Renat Fatkhullin:
Vous voulez le vérifier ?

Forum sur le trading, les systèmes de trading automatisés et l'essai de stratégies de trading

FORTS. Questions sur l'exécution

fxsaber, 2016.10.10 11:38

Voilà une belle fonctionnalité pour les développeurs pour reproduire les freins !

Maintenant, il ne sera plus possible de dire "on ne voit pas les freins".

Les développeurs devraient commencer à placer des demandes de limite à l'ouverture de la session et surveiller le temps d'exécution. S'ils constatent une lenteur, ils s'en occupent localement.

En ce moment, la situation est malheureusement déprimante.

Sur votre infrastructure. En affichant les journaux des premières minutes du marché libre ?
 
Renat Fatkhullin:

Dans la pratique, après avoir construit une bonne infrastructure et bénéficié de 3-4 ms d'exécution par tour avec des fournisseurs de liquidité soigneusement assemblés, en tant que courtier mature, les gens sont abasourdis de rester assis sur leurs fesses sur le sol quand ils voient des pics périodiques de 700-1500 ms après avoir été mis en production. Et les constructeurs de systèmes parfaits doivent vivre avec et s'adapter.

Voilà donc la réalité : il n'y a aucune garantie de stabilité de la latence minimale.

Surtout dans un environnement comportant autant d'étapes intermédiaires.

Désolé Renat, mais il est impossible que ce soit une latence de réseau:

2016.09.21 03:31:10.568 Terminal        Открытие Брокер MetaTrader 5 СР x64 build 1430 started (ОАО '' Брокерский дом '' ОТКРЫТИЕ'')

2016.09.21 17:30:00.156 Trades  'xxxxx': modify order #44620664 buy limit 5.00 ROSN-3.17 at 36438 sl: 0 tp: 0 -> 36470, sl: 0 tp: 0 placed for execution in 19.086 ms
2016.09.21 17:30:00.157 Trades  'xxxxx': buy limit 5.00 BR-12.16 at 47.66 placed for execution in 19.185 ms
2016.09.21 17:30:00.160 Trades  'xxxxx': deal #29616740 buy 5.00 BR-12.16 at 47.66 done (based on order #44620667)
2016.09.21 17:30:01.064 Trades  'xxxxx': exchange sell 5.00 BR-11.16 at market
2016.09.21 17:30:02.004 Trades  'xxxxx': cancel order #44620664 buy limit 5.00 ROSN-3.17 at 36470
2016.09.21 17:30:04.827 Trades  'xxxxx': accepted exchange sell 5.00 BR-11.16 at market
2016.09.21 17:30:04.827 Trades  'xxxxx': exchange sell 5.00 BR-11.16 at market placed for execution in 3764.451 ms
2016.09.21 17:30:04.829 Trades  'xxxxx': deal #29616752 sell 5.00 BR-11.16 at 47.33 done (based on order #44620682)
2016.09.21 17:30:05.799 Trades  'xxxxx': cancel order #44613523 sell limit 1.00 TRNF-3.17 at 149398
2016.09.21 17:30:07.929 Trades  'xxxxx': accepted cancel order #44620664 buy limit 5.00 ROSN-3.17 at 36470
2016.09.21 17:30:07.929 Trades  'xxxxx': cancel order #44620664 buy limit 5.00 ROSN-3.17 at 36470 placed for execution in 5926.927 ms
2016.09.21 17:30:08.738 Trades  'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32276 sl: 0 tp: 0 -> 32278, sl: 0 tp: 0
2016.09.21 17:30:08.775 Trades  'xxxxx': accepted cancel order #44613523 sell limit 1.00 TRNF-3.17 at 149398
2016.09.21 17:30:08.776 Trades  'xxxxx': cancel order #44613523 sell limit 1.00 TRNF-3.17 at 149398 placed for execution in 2977.588 ms
2016.09.21 17:30:09.585 Trades  'xxxxx': accepted modify order #44620340 buy limit 1.00 TATN-3.17 at 32276 sl: 0 tp: 0 -> 32278, sl: 0 tp: 0
2016.09.21 17:30:09.590 Trades  'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32276 sl: 0 tp: 0 -> 32278, sl: 0 tp: 0 placed for execution in 852.561 ms
2016.09.21 17:30:09.597 Trades  'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32278 sl: 0 tp: 0 -> 32312, sl: 0 tp: 0
2016.09.21 17:30:09.637 Trades  'xxxxx': accepted modify order #44620340 buy limit 1.00 TATN-3.17 at 32278 sl: 0 tp: 0 -> 32312, sl: 0 tp: 0
2016.09.21 17:30:09.638 Trades  'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32278 sl: 0 tp: 0 -> 32312, sl: 0 tp: 0 placed for execution in 40.658 ms
2016.09.21 17:30:10.053 Trades  'xxxxx': cancel order #44620340 buy limit 1.00 TATN-3.17 at 32312
2016.09.21 17:30:10.075 Trades  'xxxxx': accepted cancel order #44620340 buy limit 1.00 TATN-3.17 at 32312
2016.09.21 17:30:10.079 Trades  'xxxxx': cancel order #44620340 buy limit 1.00 TATN-3.17 at 32312 placed for execution in 25.974 ms
2016.09.21 17:30:44.537 Trades  'xxxxx': sell limit 1.00 BR-12.16 at 48.04
2016.09.21 17:30:44.669 Trades  'xxxxx': accepted sell limit 1.00 BR-12.16 at 48.04
2016.09.21 17:30:44.669 Trades  'xxxxx': sell limit 1.00 BR-12.16 at 48.04 placed for execution in 132.352 ms
2016.09.21 17:30:45.165 Trades  'xxxxx': sell limit 10.00 Si-6.17 at 70449
2016.09.21 17:30:45.179 Trades  'xxxxx': accepted sell limit 10.00 Si-6.17 at 70449
2016.09.21 17:30:45.180 Trades  'xxxxx': sell limit 10.00 Si-6.17 at 70449 placed for execution in 14.720 ms
 
fxsaber:
Ne pouvez-vous pas simplement le vérifier ?
sur votre infrastructure. En affichant les journaux des premières minutes du marché libre ?

Qu'y a-t-il à vérifier si nous n'avons pratiquement aucun contrôle sur quoi que ce soit.

Ils ont déjà montré des tests avec la preuve de la norme à l'ouverture du marché. Mais c'est un cas où une chose en entraîne une autre, apparemment.

J'ai déjà dit plusieurs fois ci-dessus qu'il n'y a aucune garantie de stabilité de la latence.


Si nous étions un courtier, la situation serait différente - nous ne serions pas avares de l'infrastructure la plus efficace et optimiserions le nombre maximum de routes.

 
prostotrader:

Désolé Renat, mais il est impossible que ce soit une latence de réseau:

Vous ne tenez compte QUE des délais de votre réseau. Vous vous débrouillez très bien. Et à quelques pas de vous, tout va bien.

Le problème est ailleurs. Lisez tout ce qui précède, s'il vous plaît. Et peut-être lire entre les lignes.

 
prostotrader:

Désolé Renat, mais il est impossible que ce soit une latence de réseau:

Merde, quelqu'un peut-il me dire si, sur d'autres plateformes, ce genre d'absurdité avec des soumissions d'ordres de plusieurs secondes se produit ?