Discussion sur le trading à haute fréquence sur MT5 - page 64

Nouveau commentaire
 

MT4 + Niveau 2 en terminal (fx+++n) temps M1 et niveau 2 basé sur FDK (fx+++n), par rapport à l'implémentation avec FDK, la pile dans MT4 est une tortue lente.

Par conséquent, les volumes sont différents, c'est-à-dire qu'il n'y a aucun sens à utiliser un TS basé sur le niveau 2 dans MT4.

MT5 fx+++n ne l'a pas, désolé de ne pas pouvoir comparer, mais très probablement la situation ne sera pas particulièrement avantageuse.

 
ProstoTak:

le verre dans MT4 est une tortue lente.

Mais ce n'est pas natif, c'est un produit tiers. le mt4 n'a rien à voir avec ça.

Les programmeurs l' ont peut-être fixé à 500 ms dans le flux de débogage et ont ensuite oublié de le réduire.

 
sergeev:

Mais ce n'est pas natif, c'est un produit tiers. MT4 n'a rien à voir avec cela.

Les programmeurs ont peut-être réglé la mise en veille dans le flux de débogage sur 500 ms et ont ensuite oublié de la réduire.

Non, le rafraîchissement de la tasse est juste dans la fonction de démarrage. C'est-à-dire que la pile n'est mise à jour que lorsque le tick approprié doit arriver à la méta. En d'autres termes, la pile n'est mise à jour que lorsqu'il y a un changement de prix sur le bestband. Si on le met en boucle et qu'on le règle sur Sleep, il se mettra à jour à la vitesse souhaitée. Jusqu'au fait que les prix dans la coupe seront visibles un peu plus tôt que dans la méta.
 
sergeev:

c'est un peu bizarre.

MT4 server + terminal stand locally. i.e. comme vous avez 0 ping.

Oui, localement.

Jusqu'à 400 est y compris l'envoi au pvp. c.-à-d. 150-200 pour l'envoi et l'exécution sur la vérification. selon le nombre de paquets de réponse et ping.

450 est le temps d'exécution de la fonction OrderModify, c'est-à-dire que rien n'est envoyé par STP. Uniquement vers l'agrégateur via le pont MT4. Le pont lui-même consomme environ 100 ms.
 
hrenfx:

Oui, localement.

450 est le temps d'exécution de la fonction OrderModify, c'est-à-dire que rien n'est envoyé à STP.

j'ai compris. j'ai testé deux serveurs MT4. sur des serveurs différents et les deux avaient ~150 sans envoyer à STP.

Peut-être qu'il s'agit de serveurs physiques très puissants... mais je ne le pense pas.

 

J'ai testé différents serveurs MT4, je n'ai jamais pu approcher les 150 ms. Peut-être, je suis dans des serveurs de commerce très chargés, mais peu probable.

En fait, sur LIVE in F***N sur MT4, c'est ~450ms (parfois environ une seconde (pas de reconnexion, je suppose)), FDK ~15ms. Et vous devez également tenir compte du fait que les prix dans FDK sont également plus rapides que dans MT4. Par conséquent, la différence réelle de négociation est encore plus grande.

 
hrenfx:

J'ai testé différents serveurs MT4, je n'ai jamais pu approcher les 150 ms. Peut-être, je suis dans des serveurs de commerce très chargés, mais peu probable.

En fait, sur LIVE in F***N sur MT4, c'est ~450ms (parfois environ une seconde (pas de reconnexion, je suppose)), FDK ~15ms. Et vous devez également tenir compte du fait que les prix dans FDK sont également plus rapides que dans MT4. Par conséquent, la différence réelle de négociation est encore plus grande.

Même situation. Avec un ping vers le serveur de 120 m.s., le temps moyen pour fixer une limite est de 620 m.s. Le retrait est à peu près le même.
 
Une petite queue de retard.
anonymous: Nous pouvons commencer par les classiques :

...

2. l'influence des offres importantes sur le comportement des prix. Les offres importantes peuvent être un moyen de manipulation d'une part (auquel cas il est intéressant de négocier contre ces offres), et d'autre part - un changement inefficace de la taille de la position, révélant au marché des informations sur les attentes de quelqu'un (auquel cas il est intéressant de faire face à ces offres).

Si je comprends bien, dans certaines approches (basées sur le modèle Obizhaeva-Wang ou le modèle d'Alfonsi, Fruth et Schied), l'exécution optimale (négociation de gros volumes) implique précisément l'exécution d'ordres relativement importants à certains moments. Si tel est le cas, la question se pose de savoir dans quelle mesure ces approches sont utilisées et comment elles sont masquées par d'autres algorithmes utilisant de fausses offres (par exemple, comme dans Chameleon dans Cortex iX).

Encore une fois, peut-être que je rate quelque chose. Tout cela s'avère assez compliqué.


... Certains messieurs aiment écrire de méchants diffuseurs stochastiques et des équations de Hamilton-Jacobi-Bellman lorsqu'ils résolvent des problèmes de fourniture optimale de liquidités. Il est clair que, pour des raisons pratiques, cela est grandement simplifié.
Mathemat: Wow. Nah, c'est trop.
Il y a un travail similaire dans le fichier joint pour ceux qui sont intéressés.
 
Les gars, pourquoi vous vous extasiez devant des articles stupides ? C'est pour je ne sais pas qui, pour les geeks probablement. Si vous voulez savoir quels algorithmes les grands utilisent réellement, regardez comment les offres étaient placées et ce qui se passait pendant le crash de darkpool - ce qu'ils faisaient était encore plus facile qu'un pantalon de chintz à rube-twenty. Noir et blanc, il a dû être dit dix fois dans ce fil que l'avantage est dans le matériel, dans les pings, mais pas dans les mathématiques.
 
HideYourRichess:
Les gars, pourquoi vous vous extasiez devant un article stupide. C'est pour je ne sais pas qui, des geeks probablement. Si vous voulez savoir quels algorithmes les grands oncles utilisent réellement, regardez comment les offres étaient placées et ce qui se passait pendant le crash de darkpool - ce qu'ils faisaient est encore plus facile qu'un pantalon de chintz à rub twenty. Noir et blanc, il a dû être dit dix fois dans ce fil que l'avantage là est dans le fer, dans les pings, mais pas dans le matan.

Euh, tu viens de tout gâcher.)

Vous ruinez tout le cirque.)

1...575859606162636465666768697071...94
Nouveau commentaire