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
Re-engineering pour une macro
Bien sûr, il peut faire plus qu'un seul noyau.
Je voulais dire pendant la période sans sommeil.
Il est clair que le glissement ne convient pas ici, car nous avons besoin de microsecondes. Mais elle ronronnera sans elle...
Je voulais dire pendant la période sans sommeil.
Il est clair que le glissement ne fonctionnera pas ici car nous avons besoin de micro-secondes. Mais il ronronnera sans elle.
Bien sûr, il ronronne sans glissement.
Le compteurGetMicrosecondCount est en cours d'exécution.
Bien sûr, ça tourne sans glissement.
Le compteur GetMicrosecondCount est en cours d'exécution.
Il n'y a pas que le compteur qui est chargé. Une boucle infinie vide le chargera aussi. C'est ce que je veux dire.
Mauvaise solution, en général. Mais je ne le proposerai pas mieux.
Il n'y a pas que le compteur qui est chargé. Une boucle sans fin vide se chargera également. C'est ce que je veux dire.
C'est une mauvaise solution, tout compte fait. Mais je ne le proposerai pas mieux.
Ainsi, une boucle vide prendra évidemment tout le potentiel des cycles d'horloge du processeur.
Je ne comprends pas la plainte concernant une mauvaise solution. S'il n'est pas adapté à vos ressources, cela ne signifie pas qu'il est mauvais.
µsSLEEP vous donne une latence de boucle inférieure à celle du Sleep(1) standard ; c'est-à-dire en microsecondes, et non en millisecondes.
Les 5000000 dans les exemples ci-dessus sont juste pour un exemple, la fréquence réelle en combat serait inférieure à 1 ms.
Je ne comprends pas votre problème.
Avez-vous besoin qu'elle soit exempte de stress ?
Mettre un régulier Sleep(20) ; en millisecondes
Il est donc compréhensible que le vide tout en captant tout le potentiel des cycles d'horloge du processeur.
Je ne comprends pas la plainte concernant une mauvaise solution. Si cela ne convient pas à vos ressources, cela ne veut pas dire que c'est mauvais.
µsSLEEP vous donne une latence de boucle inférieure à celle du Sleep(1) standard ; c'est-à-dire en microsecondes, et non en millisecondes.
Les 5000000 dans les exemples ci-dessus sont juste pour un exemple, la fréquence réelle en combat serait inférieure à 1 ms.
Je ne comprends pas votre problème.
Avez-vous besoin qu'elle soit exempte de stress ?
Mettez régulièrement Sleep(20) ; en millisecondes.
Il n'y a pas eu de plainte.
Je n'ai pas besoin d'un tel minuteur, je l'étudiais par intérêt. Mais je trouve que c'est une mauvaise solution car elle charge inutilement le processeur.
Et dans quel but avez-vous besoin d'un glissement de microseconde ?
Il n'y a pas eu de plainte.
Je n'ai pas besoin d'un tel minuteur, je l'ai étudié par intérêt. Mais je trouve cette solution mauvaise, car elle charge inutilement le processeur.
Pourquoi as-tu besoin d'une microseconde de glissement ?
Si vous vous demandiez pourquoi ça charge, et si vous trouviez pourquoi, vous n'auriez pas cette opinion.
Si vous voulez moins d'1 ms, vous devrez le payer en ressources.
Et il me semble que vous ne pouvez pas le décharger, car vous avez besoin d'un minuteur de microsecondes pour compter l'intervalle.
D'autre part, si la minuterie microseconde fonctionne constamment et donne une charge égale à vide pendant,
alors il y a une question, pourquoi ce délai alors mettre, et utiliser la minuterie microseconde. Mais peu importe, c'est lyrique.
Donc, j'envoie un ping au serveur, avec une certaine fréquence et sans délai.
Et j'ai besoin d'un échantillonnage à la microseconde, car il y aura des appels inutiles.
J'utilise la première solution, que j'ai postée plus tôt, et j'ai aussi écrit µsSleep, ça peut être utile.
Dans quel but avez-vous besoin d'un glissement de microseconde ?
Voici une solution toute prête.
Print(), vous le remplacez bien sûr par votre propre code.
Envoyé au PM.
Dans le testeur, cet EA génère des millions d'enregistrements d'ordres commerciaux complets et raisonnables (pas de spam) sous forme de modifications. Pour cette raison, le journal du Testeur s'engorge rapidement de manière catastrophique.
Ces journaux ne sont pas nécessaires dans 99% des cas, mais nous avons souvent besoin de ce que le conseiller expert produit via l'impression. Par conséquent, je vous demande à nouveau d'envisager la possibilité de désactiver la génération automatique d'entrées pour chaque pack OrderSend dans le Testeur.
Si j'ai bien compris, la désactivation de la génération de ces chaînes se traduira par une augmentation des performances des exécutions individuelles. C'est-à-dire que l'avantage est double.
Mais AMPGlobalEU-Live (en fait, il est préférable de le rechercher sous le nom d'AMPGlobalUSA-Live) pour MetaTrader 5 avec un noyau physique de plateforme à Chicago est en fait de 19,53 ms, car nos serveurs les plus proches sont à New York :
Tous leurs points ont été scannés manuellement - le minimum est de 19 ms.
Nous allons essayer de mettre des serveurs à Chicago dans les prochains jours. Je n'ai pas eu le temps de le faire.
Le serveur de Chicago a été déployé.
Dans les 24 heures, il va scanner tous les serveurs et commencer à les distribuer.