MT5 et la vitesse en action - page 69
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
comment envisagez-vous cela - un traitement parallèle dans un seul fil ?
Une boucle d'événements.
Et en général, c'est un problème de développeur de savoir pourquoi tout est exécuté dans un seul fil.
Il s'avère que le Market Overview est traité de manière asynchrone, et les handlers dans les programmes utilisateurs, de manière synchrone.
C'est juste chicardous, il n'y a pas de mots.
Merci pour les commentaires sur les statistiques ! Les décalages OnTick/OnBook semblent exister pour tout le monde. Sleep(1) est soit 1 ms soit 15 ms. La raison pour laquelle cela dépend n'est pas claire.
Tout le monde semble avoir des décalages entre OnTick et OnBook.
Je pense que vous savez que OnTimer() ne peut pas être appelé plus souvent que 10-16 millisecondes. Il est logique de supposer que les autres fonctions OnXXX ne sont pas appelées plus souvent non plus. C'est peut-être la raison de vos décalages ?
Je pense que vous savez que OnTimer() ne peut pas être appelé plus souvent que 10-16 millisecondes. Il est logique de supposer que les autres fonctions OnXXX ne sont pas appelées plus souvent non plus. C'est peut-être la raison de vos décalages ?
Pas logiquement, les gestionnaires ne sont pas liés à la fréquence/résolution du timer GetTickCount. Les événements sont déclenchés instantanément au moment où ils se produisent.
OnTimer n'est pas non plus lié à une erreur de 16ms. Il est facile d'obtenir un timer de 1ms dans la grande majorité des cas, à moins que l'ordinateur soit mort et chargé à 100%.
Le problème avec presque tous les tests de fxsaber est qu'il essaie de mesurer les valeurs aberrantes des appels individuels au lieu de faire la moyenne de l'ensemble et qu'il ne veut pas comprendre la réalité du distributeur de threads.
Il l'a fait :
Méthodes de lutte pour se rapprocher du temps de repos :
Par conséquent, sur un VPS ordinaire, les terminaux (ainsi que tout autre programme) souffriront toujours de retards inattendus. Plus il y a de VPS bon marché/sur-vendus, plus il y a de problèmes.
Demandez-vous sur votre VPS, si SR-IOV est activé et s'il existe des pilotes réseau spéciaux récents (installés manuellement uniquement) pour cela ? Dans 99% des cas, non, car cela casse la migration des virtualisations à travers le zoo matériel. Et sans elle, des retards supplémentaires sont garantis simplement à cause de la transmission/du traitement double (sur l'hôte et le virtuel) des paquets du réseau et du nombre accru d'interruptions.
Notre service VPS est beaucoup moins sujet à cela, tant en termes d'architecture que de terminaux légers sans interface graphique.
Non logique, les gestionnaires ne sont pas liés à la fréquence/résolution du minuteur GetTickCount. Les événements sont déclenchés instantanément au moment où ils se produisent.
OnTimer n'est pas non plus lié à l'erreur de 16ms. Il est facile d'obtenir un timer de 1ms dans la grande majorité des cas, à moins que l'ordinateur soit mort et chargé à 100%.
Le problème avec presque tous les tests de fxsaber est qu'il essaie de mesurer les valeurs aberrantes des appels individuels au lieu de faire la moyenne de l'ensemble et qu'il ne veut pas comprendre la réalité du distributeur de threads.
Il l'a fait :
Méthodes de lutte pour se rapprocher du temps de repos :
Par conséquent, sur un VPS ordinaire, les terminaux (ainsi que tout autre programme) souffriront toujours de retards inattendus. Plus il y a de VPS bon marché/sur-vendus, plus il y a de problèmes.
Demandez-vous sur votre VPS, si SR-IOV est activé et s'il existe des pilotes réseau spéciaux récents (installés manuellement uniquement) pour cela ? Dans 99% des cas, non, car cela casse la migration des virtualisations à travers le zoo matériel. Et sans elle, des retards supplémentaires sont garantis simplement à cause de la transmission/du traitement double (sur l'hôte et le virtuel) des paquets du réseau et du nombre accru d'interruptions.
Notre service VPS y est soumis par des ordres de grandeur inférieurs, tant en termes d'architecture que de terminaux légers sans interface graphique.
Et maintenant, imaginez combien de fois les performances des programmes utilisateurs seraient plus faibles sur une machine aussi optimisée, si les gestionnaires dans les programmes étaient exécutés de manière asynchrone.
Je ne comprends pas le sens de la super mise à niveau et de la super optimisation du matériel de la machine, si les gestionnaires du programme de l'utilisateur sont a priori exécutés de manière synchrone.
Pour le terminal lui-même et son fonctionnement interne, l'optimisation décrite ci-dessus est peut-être utile. Pour les programmes de combat de l'utilisateur, j'en doute.
Parce que l'exécution consécutive des handlers dans le programme utilisateur réduit tout le potentiel de toute machine super-optimisée.
Le problème ne réside pas dans le matériel, mais dans l'architecture du travail interne du terminal.
Et maintenant, imaginez combien l'exécution des programmes de l'utilisateur sera plus rapide sur une telle machine optimisée, si les gestionnaires des programmes sont exécutés de manière asynchrone.
Je ne comprends pas le sens de la super mise à niveau et de la super optimisation du matériel de la machine, si les gestionnaires du programme de l'utilisateur sont a priori exécutés de manière synchrone.
Pour le terminal lui-même et son fonctionnement interne, l'optimisation décrite ci-dessus est peut-être utile. Pour les programmes de combat de l'utilisateur, j'en doute.
Parce que l'exécution consécutive des handlers dans le programme utilisateur réduit tout le potentiel de toute machine super-optimisée.
Le problème ne réside pas dans le matériel, mais dans l'architecture du fonctionnement interne du terminal.
Il n'y aura pas d'accélération. Veuillez soumettre vos calculs, au moins en chiffres approximatifs, prouvant une accélération multiple.
Une course aux ressources ? Création incontrôlée de nouveaux fils de discussion ? Des conflits pour rien ?
Voulez-vous des ralentissements inexpliqués ?
Dans le modèle basé sur les événements, tous les événements se sont toujours déroulés en formation, un par un. Chewed up - mâché.
Notre service VPS est beaucoup moins sujet à cela, tant en termes d'architecture que de terminaux légers sans interface graphique.
S'il y a des décalages sur votre service VPS, le prendrez-vous au sérieux ?
Qui utilise le VPS de MQ, veuillez partager les résultats des programmes suivants.
S'il y a des décalages sur votre service VPS - allez-vous le prendre au sérieux ?
Je me demande combien de fois je devrai vous dire qu'avec autant (des milliers) de threads par nombre limité de cœurs, il est insensé de parler de stabilité de l'allocation de quantum de temps par thread ?
Vous êtes toujours assuré d'avoir des échecs sur des échantillons uniques aléatoires de n'importe quelle instruction, y compris les plus simples en assembleur comme inc eax. Ceci est dû à l'architecture et aux limites physiques de "l'allocation honnête des quanta de temps de milliers de threads à un petit nombre de cœurs".
Arrêtez d'être stupide et continuez à attraper des rafales uniques par million de demandes.
Arrêtez d'être stupide et continuez à attraper des aberrations uniques par million de requêtes.
Je vois ce qui se passe avec les pointes simples, merci pour l'explication détaillée. Pour le moment, nous ne parlons pas de SymbolInfoTick, mais de décalages d'un autre type, qui se produisent sur presque chaque tick.