Caractéristiques du langage mql5, subtilités et techniques - page 92

 
Slava:
Quelle est la probabilité que l'heure locale de l'ordinateur change entre deux appels à GetMicrosecondsCount utilisés pour mesurer le temps en microsecondes ?

Pas zéro.

 
LeXpert:
Discussion très constructive ;)

Encore quelques scribouillards supprimés définitivement et c'est tout.

Nous ne tolérons plus ceux qui se précipitent sur l'embargo, tentent d'appeler la réalité des fonctions WinAPI un bug et nous en rendent responsables. Il est clair qu'il y aura plus constructif.

 
fxsaber:

Pas zéro.

Quelle est la probabilité de perte de temps des échanges client/serveur en millisecondes ? Probablement plus que la probabilité de changer l'heure locale.

 
Renat Fatkhullin:

Il suffit de supprimer définitivement quelques scribouillards de plus et c'est tout.

Nous ne tolérons plus ceux qui se précipitent sur l'embargo, en essayant d'appeler la réalité un bug et de nous blâmer. Il est clair qu'il y en aura d'autres.

un peu à droite du sujet, en direction de OnTimer()))

Je ne sais plus où j'ai lu, mais un représentant de MQ a écrit qu'il est possible (pour ceux qui ont une forte démangeaison ) de faire passer le système à un délai de 1 ms et alors, si vous utilisez EventSetMillisecondTimer(...), OnTimer() fonctionnera également avec une erreur d'environ 1 ms, mais pas de 16 ms.

Si j'ai bien compris, OnTimer() fonctionne avec le délai du système, n'est-ce pas ?


ps. a envoyé une demande au servcie-desk hierUnprocessed,Started : 2018.07.30 12:52,#2117844, pouvez-vous aider à la traiter, elle est en suspens depuis hier ;))
 

OnTimer fonctionne avec l'erreur de la minuterie WinAPI du système, contrôlée par la fonction WinAPI GetTickCount. Il s'agit d'une méthode de chronométrage très rapide et bon marché qui a un impact minimal sur le processus mesuré. Cela signifie qu'il n'affecte pas beaucoup le résultat final.

La précision de ce chronomètre peut être améliorée pour l'ensemble du système d'exploitation, mais au prix à la fois d'une consommation accrue de l'unité centrale et des effets induits aléatoires et massifs de la masse de programmes commençant à

  • mesurer le temps avec plus de précision
  • passer moins de temps dans les slips
  • certains délais d'attente qui fonctionnent pour les erreurs courantes dégénèrent en un comportement carrément mauvais.
  • Et d'autres trucs sympas

Le problème du minuteur du système Windows a plus de 20 ans. Mais il est dangereux de modifier le comportement et la précision des anciens.

C'est pourquoi de nouvelles méthodes de chronométrage plus précises ont été introduites depuis longtemps. Mais ils sont gourmands en ressources et il n'est pas raisonnable de les utiliser pour remplacer complètement l'ancien système.

Notre minuteur avec une plus grande précision est implémenté avec GetMicrosecondCount. Il doit être utilisé consciemment et en sachant qu'il coûte plus cher que GetTickCount. De même, le coût des appels à GetMicrosecondCount doit être explicitement pris en compte en cas de comptage précis.

Il est très facile de se tromper soi-même et de tromper les autres en utilisant mal la minuterie et en ne gardant pas le repère propre.

 
Renat Fatkhullin:

Nous ne tolérons plus ceux qui se précipitent dans l'embuscade et tentent de qualifier la réalité des fonctions WinAPI de bogue et de nous en rendre responsables. Il est clair qu'il y aura plus constructif.

Vous pouvez simplement écrire dans l'aide que GetMicrosecondsCount dépend du temps de l'ordinateur local et peut fonctionner de manière inadéquate lorsqu'il est modifié. GetTickCount ne le fait pas.

Donc, si vous devez le résoudre à notre niveau et au vôtre, vous devriez probablement le faire au nôtre.

Pourquoi devriez-vous interdire ?

 
Renat Fatkhullin:

OnTimer fonctionne avec la minuterie WinAPI du système, contrôlée par la fonction WinAPI GetTickCount. Il s'agit d'une méthode de chronométrage très rapide et bon marché qui a un impact minimal sur le processus mesuré. Cela signifie qu'il n'affecte pas beaucoup le résultat final.

La précision de ce chronomètre peut être améliorée pour l'ensemble du système d'exploitation, mais au prix d'une consommation accrue de l'unité centrale et des effets induits aléatoires et massifs de la masse des programmes commençant à

  • mesurer le temps avec plus de précision
  • passer moins de temps dans les slips
  • certains délais d'attente qui fonctionnent pour des délais normaux dégénèrent en mauvais comportements purs et simples.
  • et quelques problèmes de refroidissement.

Le problème du minuteur du système Windows a plus de 20 ans. Mais il est dangereux de changer le comportement et la précision de l'ancien.

C'est pourquoi de nouvelles méthodes de chronométrage plus précises ont été introduites depuis longtemps. Mais ils sont gourmands en ressources et il n'est pas raisonnable de les utiliser pour remplacer complètement l'ancien système.

Notre timer avec une plus grande précision est implémenté avec GetMicrosecondsCount. Il doit être utilisé consciemment et en sachant qu'il coûte plus cher que GetTickCount. En outre, le coût des appels à GetMicrosecondsCount doit être explicitement pris en compte en cas de comptage précis.

Il est très facile de se tromper soi-même et de tromper les autres en utilisant mal la minuterie et en ne gardant pas le repère propre.

oops, c'est ce que j'ai pensé après que le représentant de MQ ait écrit sur la diminution du temps de temporisation du système ;))

donc je suis d'accord qu'il n'est pas nécessaire de changer quelque chose dans cette direction.

à propos, j'aimerais savoir si des développements sont faits vers laréflexion comme en C# ou au moins comme en boost ? par exemple la sérialisation / désérialisation serait plus pratique à implémenter

 
TheXpert:

Vous pouvez simplement écrire dans l'aide que GetMicrosecondsCount dépend de l'heure locale de l'ordinateur et peut ne pas fonctionner correctement lorsqu'il est modifié. Et GetTickCount n'en dépend pas.

Il est écrit dans l'aide : La fonction GetMicrosecondCount() renvoie le nombre de microsecondes, écoulées depuis le début du programme MQL5.

C'est ce que j'ai dit clairement : mesurer le nombre de microsecondes.

Le problème de la mesure à la microseconde par rapport au problème peut également être résolu, bien que de manière un peu maladroite.

Pourquoi devrions-nous interdire ?

Nous devons interdire.

Tout d'abord, le minuteur microseconde n'a aucun problème avec la mesure du temps. Deuxièmement, certaines personnes n'ont qu'une envie, c'est de trouver une excuse pour faire une crise, et de la garder jusqu'à la fin.

Une fois de plus - les règles ont changé.

Plus d'insultes ou de "vous devez" ne seront acceptés. Nous ferons un balayage sans avertissement.

 
Renat Fatkhullin:

C'est indiqué dans l'aide : La fonction GetMicrosecondCount() renvoie le nombre de microsecondes écoulées depuis le début du programme MQL5.

Et il est écrit pour la fonction GetTickCount:

La fonction GetTickCount() renvoie le nombre de millisecondes qui se sont écoulées depuis le démarrage du système.

Les phrases sont presque identiques mais une fonction dépend de l'heure locale et l'autre non. Comment deviner ?

 
LeXpert:

Et il est écrit pour la fonction GetTickCount:

Les phrases sont presque identiques, mais une fonction dépend de l'heure locale, l'autre non. Comment sommes-nous censés le deviner ?

Il s'agit de la WinAPI.

Un rappel sur l'utilisation des phrases "devrait", explicitement ou implicitement. L'utilisation de "metaquotes must" au lieu de "please consider" est désormais inacceptable.