La limite de 2 Go pour les fichiers FXT est-elle toujours en vigueur ? - page 3
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
D'autres traders peuvent-ils vérifier que la même chose se produit pour eux, c'est-à-dire que, au moins sur les systèmes 64 bits, la limite d'USAGE des fichiers FXT de 2 Go semble avoir disparu.
Merci à tous.
~DV
Mon tout premier message ne vous suffit-il pas ? Pas de problème au-delà de 2GB sur Win7 64 bit MT4 version445.
Pour le bénéfice de tous, je viens de terminer le test Win7, 64-bit, build 500 sur mon ordinateur portable (un test presque identique à celui que j'ai décrit plus tôt dans ce fil de discussion et qui a échoué sur XP 32-bit). Le .fxt dans ce cas était de 6,372,486kb et il a ÉCHOUÉ à produire des résultats après avoir atteint environ 60% du chemin à travers l'exécution. Je n'ai pas les résultats du test 32bit à portée de main pour voir si l'un est allé plus loin que l'autre, mais IIRC il était dans la même région.
Je vais effectuer quelques tests supplémentaires (le même test mais avec des plages de dates plus étroites) pour voir où se situe la limite en ce qui concerne la taille du .fxt.
Je viens d'avoir la confirmation que le même test sur une machine 32 bits s'est arrêté au même endroit que la machine 64 bits et que les deux étaient juste au-dessus de 6 Go de .fxt.
J'ai refait mes tests 64 bits avec des plages de dates plus étroites. Il semblerait que la limite du .fxt soit maintenant d'environ 4 Go sur les deux architectures, un test à 3 470 706 Ko de taille .fxt a été effectué, un autre à 4 269 203 Ko s'est arrêté juste avant (au même endroit que le test complet de 6 Go). 4 Go = 4 194 304 Ko (en JEDEC).
Il serait bon que certains d'entre vous puissent vérifier la même chose. Le test de DV était certainement inférieur à 4 Go, c'est pourquoi il a été correct.
Le problème est que je pense avoir effectué ce test sur des versions précédentes de MT4 (mais je ne suis pas sûr que c'était avant le build 445) et il a abouti à peu près au même résultat, donc je ne suis pas sûr que nous soyons mieux lotis. Quoi qu'il en soit, il semblerait que sur 32bit et 64bit la limite est maintenant de 4gb pour la lecture des .fxt.
Il serait bon que certains d'entre vous soient en mesure de vérifier la même chose. Certainement que le test de DV était inférieur à 4gb, c'est pourquoi il aura été correct.
Le problème est que je pense avoir fait ce test sur des versions précédentes de MT4 (bien que je ne sois pas sûr si c'était avant la construction 445) et il a couru à peu près au même point, donc je ne suis pas sûr si nous sommes mieux lotis. Quoi qu'il en soit, il semblerait que sur les deux 32bit et 64bit la limite est maintenant 4gb pour la lecture .fxt.
J'ai déjà confirmé qu'un système d'exploitation 64 bits (Win 7) fonctionnera au-delà de 2 Go... Je n'ai pas de système d'exploitation 32 bits isolé, seulement le mode XP sur Win 7.
RaptorUK:
Il semble bien que ce soit le cas, mon test a produit un fichier fxt de 3,10 Go et le test a fonctionné du début à la fin.
Bonjour Raptor, désolé, je pense que vous avez mal compris. J'ai confirmé de mon côté que 4gb est maintenant la limite sur les architectures 32 et 64 bits. Je ne pense pas que 32/64 fasse une différence.
Ce que j'espérais, c'est que quelqu'un ici confirmerait maintenant qu'il trouve aussi que 4 Go est la limite, puisque des tests réussis au-dessus de 2 Go mais en dessous de 4 Go (que j'ai corroborés) ont été confirmés, mais que j'étais le seul à avoir testé au-delà de 4 Go.
J'ai mis à jour ma demande de service à la lumière de ces informations, mais je n'ai reçu aucune réponse en 8 jours...
Bonjour Raptor, désolé, je pense que vous avez mal compris. J'ai confirmé de mon côté que 4gb est maintenant la limite sur les architectures 32 et 64 bits. Je ne pense pas que 32/64 fasse une différence.
Ce que j'espérais, c'est que quelqu'un ici confirmerait maintenant qu'il trouve aussi que 4 Go est la limite, puisque des tests réussis au-dessus de 2 Go mais en dessous de 4 Go (que j'ai corroborés) ont été confirmés, mais que j'étais le seul à avoir testé au-delà de 4 Go.
J'ai mis à jour ma demande de service à la lumière de ces informations, mais je n'ai reçu aucune réponse en 8 jours...
Ah je vois, je vais voir quelles données j'ai pour faire un fichier fxt de plus de 4 Go et je ferai un rapport. Je suppose que 4 Go est la nouvelle limite mais c'est bien de tester et d'être sûr.
Merci messieurs, c'est bon d'être sûr.
Dans le même ordre d'idées, si je lance une optimisation, y a-t-il des contraintes .fxt ou d'autres contraintes connexes ? Ce que je veux dire, c'est que si je fais une seule exécution sur un ensemble de données et que cela crée un .fxt de 1 Go, si je veux ensuite exécuter une optimisation sur cet ensemble et que les permutations requises pour la réaliser sont, disons, de 200 exécutions, qu'est-ce qui permet à 80 d'entre elles de se terminer correctement (par exemple) mais que le reste se plante ? Si c'est purement le .fxt, et que c'est 1gb sur une seule exécution, pourquoi cela ferait plus de 4 exécutions avant d'échouer ? Un conseil ?
Merci messieurs, c'est bon d'être sûr.
Dans le même ordre d'idées, si je lance une optimisation, y a-t-il des contraintes .fxt ou d'autres contraintes connexes ? Ce que je veux dire, c'est que si je fais une seule exécution sur un ensemble de données et que cela crée un .fxt de 1 Go, si je veux ensuite exécuter une optimisation sur cet ensemble et que les permutations requises pour la réaliser sont, disons, de 200 exécutions, qu'est-ce qui permet à 80 d'entre elles de se terminer correctement (par exemple) mais que le reste se plante ? Si c'est purement le .fxt, et que c'est 1gb pour une seule exécution, pourquoi est-ce qu'il ferait plus de 4 exécutions avant d'échouer ? Un conseil ?
Je n'ai pas exécuté d'optimisation depuis un certain temps, je ne peux donc pas commenter directement la stabilité de la ST pour les optimisations sur les versions récentes, mais j'ai exécuté de nombreuses optimisations dans le passé et je n'ai jamais eu de fin prématurée du nombre d'exécutions prévu. J'ai vu que la date de début peut se dérégler, mais je n'ai jamais essayé de reproduire ce phénomène, qui pourrait être particulier à l'utilisation de données en tick et au TDS: https://www.mql5.com/en/forum/140857.
Que voulez-vous dire par "crap out" ? Peut-être avez-vous trouvé une combinaison de paramètres qui montre une erreur de division par zéro dans votre code, l'avez-vous vérifié ?