MT5 et la vitesse en action - page 44

[Renat Fatkhullin]

fxsaber:

J'ai vu plus d'une fois des situations où le terminal charge le CPU à 100 % au point qu'il ne réagit plus à rien.

Puis j'ai regardé les journaux et j'ai vu qu'il y avait des sauts de ticks sauvages dans OnTick. Cependant, si j'écris correctement un EA, cette situation désastreuse n'affectera pas les résultats du trading. Je l'ai analysé précisément, tout est clair.

Je me demande dans quelle mesure les mécanismes permettant de faire face aux retards dans les produits de marché sont répandus. Je n'ai jamais vu une seule fois une mention de la puissance de la machine pour fonctionner. Le ping minimum est un oui.

Où les lanciez vous ?

Si vous êtes sur un VPS pour 2-5 dollars, alors des retards de dizaines et de centaines de millisecondes sont facilement pris en compte dans n'importe quelle fonction WinAPI à peine sérieuse. Tout ralentit à partir du niveau de l'hyperviseur, transformant une machine virtuelle en un diaporama.

Expliqué ci-dessus.

[Andrey Khatimlianskii]

Renat Fatkhullin:

Ce n'est pas GetMicrosecondsCount qui ralentit, mais le système d'exploitation qui quantifie les ressources CPU pour n'importe quel thread dans votre VPS étranglé. Pour toute fonction, toute action, tout programme au sein de votre UPU.

Eh bien, aucun shell CPU ne peut découper et allouer les ressources de manière équitable lorsqu'il dispose de 20 (c'est encore respectable) systèmes d'exploitation avec 1500 threads d'exécution par copie. Prenez 8 à 16 cœurs et répartissez-les sur 20 * 1 500 = 30 000 (trente mille pistes physiques).

Dans mon cas (boîte virtuelle avec vin7 + 2 cœurs + 16 GB de RAM sur mon propre matériel sans rien d'autre), d'où viennent les 2-3 µs périodiques ?

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

MT5 et vitesse en combat

Andrey Khatimlianskii, 2020.10.05 10:19

Pas vraiment une UPU, mais une machine virtuelle sur du matériel loué :

2020.09.29 00:11:11.350 Terminal        MetaTrader 5 x64 build 2615 started for MetaQuotes Software Corp.
2020.09.29 00:11:11.352 Terminal        Windows 7 Service Pack 1 build 7601 on Virtual Box, Intel Core i7-4770  @ 3.40 GHz, 14 / 15 Gb memory, 4 / 31 Gb disk, IE 11, Admin, GMT+2

2020.10.05 11:11:25.340 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:11:31.308 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:12:34.699 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 3 mсs.
2020.10.05 11:13:04.388 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:13:58.116 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:14:08.388 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:14:14.975 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:14:19.095 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:15:28.814 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:15:55.814 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:15:56.814 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:16:27.818 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 9 mсs.
2020.10.05 11:16:35.275 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:16:45.775 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 27 mсs.
2020.10.05 11:16:51.715 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:17:30.477 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 5 mсs.
2020.10.05 11:18:25.081 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.

[Renat Fatkhullin]

Andrey Khatimlianskii:

Dans mon cas (boîte virtuelle avec win7 + 2 cœurs + 16GB de RAM sur son propre matériel sans rien d'autre qui tourne), d'où vient la périodicité de 2-3 µs ?

C'est le prix de la double virtualisation.

D'autant plus que VirtualBox n'est pas un hyperviseur complet de type Hyper-V, mais vit au-dessus de votre système d'exploitation de bureau actuel (Windows 7 aussi ?) qui a une coquille de CPU conçue pour un cas d'utilisation différent.

Vous avez donc : Windows 7/10 -> VirtualBox -> Windows 7. Essentiellement, deux niveaux de virtualisation, le premier ignorant les aspirations de VirtualBox, le considérant comme un programme ordinaire. L'allocation des ressources du CPU (le threadsheduler) est clairement foutue.

Il devrait l'être : Hyper-V 2016/2019 -> Windows 2016/2019

[fxsaber]

Renat Fatkhullin:

Ce n'est pas GetMicrosecondsCount qui ralentit, c'est l'OS qui quantifie les ressources CPU pour n'importe quel thread dans votre VPS étranglé. Pour toute fonction, toute action, tout programme au sein de votre UPU.

Je pense qu'un argument comme celui-ci vous fera réfléchir. Conseiller.

#include <fxsaber\Benchmark\Benchmark.mqh> // https://www.mql5.com/ru/code/31279

// Сделал действия по этой ссылке: https://www.mql5.com/ru/forum/342090/page41#comment_18597040

void OnStart()
{
  _BV(
  for (int i = 0; i < 1 e6; i++)
    GetMicrosecondCount();
      , 1)
      
  _BV(
  for (int i = 0; i < 1 e6; i++)
    GetTickCount();
      , 1)      
}

2020.10.06 00:24:26.779 Alert: Time[Test6.mq5 52: for(inti=0;i<1 e6;i++)GetMicrosecondCount();] = 16289902 mсs.
2020.10.06 00:24:26.784 Alert: Time[Test6.mq5 57: for(inti=0;i<1 e6;i++)GetTickCount();] = 4300 mсs.

C'est loin de tout ralentir. C'est pourquoi j'ai pu changer pour winmm::timeBeginPeriod(1)+winmm::timeGetTime() de manière tout à fait inoffensive, obtenant une vitesse comme GetTickCount, mais sans la redoutable limite de 16 ms. Cependant, les producteurs de marché ne sont pas autorisés à le faire, car il s'agit d'une DLL. Il est peu probable que vous fassiez une version régulière à la milliseconde.

[fxsaber]

Renat Fatkhullin:

La fonction MQL5 permettant de réduire toutes les fenêtres et l'application elle-même est une excellente idée. Nous allons travailler sur ce point.

Voici une autre chose.

terminal sur un VPS, elle sera fortement opposée à ce que tout soit brusquement basculé. Il peut et doit minimiser lui-même les fenêtres s'il quitte la session RDP.

J'utilise actuellement WinAPI pour minimiser par touche de raccourci. Très pratique et beaucoup plus inoffensif que le TerminalClose standard.

[Roman]

Renat Fatkhullin:

Voici un exemple de ce que je voulais dire.
Les deux serveurs sont des courtiers différents, se trouvent dans la même zone, voire au même endroit.
La carte de service suggère que l'AMP soit situé au Royaume-Uni.
Et pour Juste pour une raison quelconque offre dans NL.
Pourquoi ? S'il y a un vpc plus proche.

[Renat Fatkhullin]

fxsaber:

Je pense que vous trouverez que c'est un argument qui vous fera réfléchir. Conseiller.

C'est loin de ralentir les choses. C'est pourquoi j'ai pu changer pour winmm::timeBeginPeriod(1)+winmm::timeGetTime() de manière tout à fait inoffensive, obtenant une vitesse comme GetTickCount, mais sans la redoutable limite de 16ms. Cependant, les producteurs de marché ne sont pas autorisés à le faire, car il s'agit d'une DLL. Il est peu probable que vous fassiez une version régulière en millisecondes.

Eh bien, vous êtes un maître des tests de stress de course sans corrélation ni contrôle de vraisemblance.

Bien entendu, le comptage à la microseconde nécessite des ressources pour pouvoir mesurer des intervalles 1000 fois plus petits qu'une milliseconde.

Si vous avez occasionnellement besoin de mesurer des intervalles avec une grande précision, utilisez les microsecondes. Et cela vous coûtera 0 microseconde.

Si vous êtes configuré pour appeler des millions de fois l'auto-mesure, vous êtes probablement en train de vous faire des illusions.

Sur un VPS étouffé, surclocker le timer du système via timeBeginPeriod est risqué. Vous ne feriez qu'augmenter la charge du processeur :

Cette fonction affecte un paramètre global de Windows. Windows utilise la valeur la plus basse (c'est-à-dire la résolution la plus élevée) demandée par un processus. La définition d'une résolution plus élevée peut améliorer la précision des intervalles de temps dans les fonctions d'attente. Cependant, cela peut également réduire les performances globales du système, car le planificateur de threads change de tâches plus souvent. Les hautes résolutions peuvent également empêcher le système de gestion de l'énergie du processeur d'entrer dans les modes d'économie d'énergie. Le fait de définir une résolution plus élevée n'améliore pas la précision du compteur de performance à haute résolution.

Sinon, le système d'exploitation aurait dû faire des GetTickCount/GetTickCount64 précis depuis longtemps et se réjouir de la précision gratuite. Mais non, vous devrez payer pour la précision de cette minuterie.

[fxsaber]

Veuillez supprimer les freinsCHART_IS_MAXIMIZED. La solution WinAPI n'est maintenant pas un ordre de grandeur plus rapide que la solution de base.

[Renat Fatkhullin]

Roman:

Voici un exemple de ce que je voulais dire.
Les deux serveurs sont des courtiers différents, se trouvent dans la même zone, voire au même endroit.
La carte de service suggère que l'AMP soit situé au Royaume-Uni.
Et pour Juste pour une raison quelconque offre dans NL.
Pourquoi ? S'il y a un RTCP plus proche.

Nous connaissons les géo-points des serveurs, et ici les positions des serveurs de courtage sont construites à partir des bases GeoIP.

Et il arrive souvent que les informations ne correspondent pas à la réalité. Par conséquent, nous ne devons jamais supposer que la position du courtier est exacte.

Nous examinerons ce point plus en détail demain, car nous devons tout revérifier et re-scanner manuellement pour répondre à la question.

[Andrey Khatimlianskii]

Renat Fatkhullin:

C'est le prix de la double virtualisation.

D'autant plus que VirtualBox n'est pas un hyperviseur complet de type Hyper-V, mais vit au-dessus de votre système d'exploitation de bureau actuel (Windows 7 également ?) qui a un shell CPU adapté à un cas d'utilisation différent.

Vous avez donc : Windows 7/10 -> VirtualBox -> Windows 7. Essentiellement, deux niveaux de virtualisation, le premier ignorant les aspirations de VirtualBox, le considérant comme un programme ordinaire. L'allocation des ressources du processeur (le threadsheduler) est clairement détraquée.

Il devrait l'être : Hyper-V 2016/2019 -> Windows 2016/2019

Non, j'ai des virtualisateurs qui tournent sous CentOS. Mais je ne suis pas compétent pour poursuivre ce dialogue.