Les terminaux voraces d'Alpari - page 7
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
Vous disposez de 16 instruments. Avez-vous essayé d'augmenter l'intervalle de calcul - disons de 1000ms à 5000ms ? Comment ça se passe ?
Si vous n'avez pas essayé et n'avez pas l'intention de le faire, il est bien sûr plus commode de continuer à blâmer le terminal et le DC.
Le zéro est important s'il compte une fois par seconde.
C'est tout à fait étrange. Je n'arrive pas à croire que même 16 paires sur un cinq chiffres puissent être si différentes en termes de charge en pierres des mêmes 16 sur un quatre chiffres : c'est une petite histoire.
Debugger, vous devriez écrire au support technique.
Quel type de processeur avez-vous ?
C'est un peu étrange. Je n'arrive pas à croire que même 16 paires sur un cinq chiffres puissent être si différentes en termes de chargement de pierres des mêmes 16 sur un quatre chiffres : c'est une petite histoire.
Il est évident que la quantité de données d'entrée sur un appareil à cinq chiffres est beaucoup plus importante, d'un ordre de grandeur.
Le terminal n'a donc rien à voir avec cela et la solution est soit de filtrer à quatre chiffres, soit de changer le matériel pour un plus efficace (CUDA comme exemple de rapport performance/prix optimal).
Andi, tout d'abord, je sais que le flux de données sur le cinq chiffres est environ un ordre de grandeur plus grand. Mais je ne vois pas de charge aussi terrible sur Alpari (cinq chiffres !). Voici une photo, ne soyez pas paresseux (cliquez pour agrandir) :
Et deuxièmement, eh bien, combien de fois vous êtes-vous vanté de votre implication dans CUDA ? !
2 Débogueur : Il y a beaucoup de paires ici, toutes sur М1, j'ai téléchargé l'historique au moins jusqu'au 26 mai (certains logs sont plus profonds), c'est-à-dire pas moins de 25 000 barres dans chaque graphique. Il n'y a pas d'indicateurs. Ce n'est pas le moment le plus passif du marché (regardez le graphique actuel). La RAM est chargée comme ça tout le temps, pour Windows 7.
Oui, le processeur (Core 2 Duo E7200) se charge, mais nous ne parlons pas de chiffres de l'ordre de "25-30% minimum".
Alors une dernière question : combien de personnages avez-vous dans MarketWatch ?
J'ai 28 paires sur Alpari, dont 7 fenêtres sont ouvertes, mémoire occupée : 20 800 (ensemble de travail privé) 60 320(mémoire allouée)
Paramètres MT4 :
Nombre maximum de barres par fenêtre : 65000
Nombre maximal de barres dans l'historique : 512000
1. Tout d'abord, je sais que le flux de données sur le cinq chiffres est d'un ordre de grandeur supérieur. Mais je ne vois pas de charge aussi terrible sur Alpari (cinq chiffres !). Voici une photo, ne soyez pas paresseux (cliquez pour agrandir) :
2) Et deuxièmement, combien vous pouvez vous vanter de votre implication dans CUDA !1. une augmentation d'un ordre de grandeur des données d'entrée peut être critique pour certains EA haute fréquence. elle ne l'est peut-être pas pour le vôtre, mais cela ne veut pas dire que c'est vrai pour tout le monde.
2. je ne suis pas impliqué dans CUDA, mais peut-être pouvez-vous proposer une autre option avec un meilleur rapport performance/prix pour résoudre le problème de la charge du CPU avec les calculs dont vous avez vraiment besoin ?
1. une augmentation d'un ordre de grandeur des données d'entrée peut être critique pour certains EA à haute fréquence.
C'est de ça qu'il s'agit ici.
Il ne s'agit pas du terminal et des EAs inadéquates, des indicateurs etc...
1. J'ai volontairement désactivé tous les calculs pour montrer que le terminal lui-même n'a pratiquement rien à voir avec cette situation. Le topicstarter a déclaré que la charge minimale du CPU est de 25-30% sur Alpari.
2. Non, je ne peux pas et je ne vais pas le faire : le sujet n'est pas d'optimiser le rapport performance/prix. Le problème ne concerne que les performances.
Je soupçonne que le bug se situe soit dans des réglages excessifs du terminal, soit dans des calculs trop fréquents et non optimisés. Et les calculs ici sont clairement solides.