Die gefräßigen Terminals von Alpari - Seite 7

 
Debugger: Bei anderen ist mir das noch nicht aufgefallen...

Sie haben 16 Instrumente. Haben Sie versucht, das Berechnungsintervall zu erhöhen - z. B. von 1000 ms auf 5000 ms? Wie sieht es aus?

Wenn Sie es nicht versucht haben und es auch nicht vorhaben, - dann ist es natürlich am bequemsten, weiterhin dem Terminal und dem DC die Schuld zu geben.

 
Besser noch, einmal pro Bar. Wenn der Nulldurchgang nicht wichtig ist, natürlich.
 

Die Null ist wichtig, wenn sie einmal pro Sekunde zählt.

Es ist alles seltsam. Ich kann nicht glauben, dass selbst 16 Paare auf einer fünfstelligen Zahl eine so unterschiedliche Steinbelastung aufweisen können wie die gleichen 16 Paare auf einer vierstelligen Zahl: Das ist eine kleine Geschichte.

Debugger, sollten Sie sich an den technischen Support wenden.

Was für einen Prozessor haben Sie?

 
Mathemat:

Das ist alles ein bisschen seltsam. Ich kann nicht glauben, dass selbst 16 Paare auf einer fünfstelligen Zahl so unterschiedlich sein können, was die Steinbelastung angeht, im Vergleich zu denselben 16 Paaren auf einer vierstelligen Zahl: das ist eine kleine Geschichte.

Natürlich ist die Menge der Eingabedaten bei einer fünfstelligen Zahl um eine Größenordnung größer.

Das Terminal hat also nichts damit zu tun, und die Lösung besteht entweder darin, auf vier Stellen zu filtern oder die Hardware durch eine effizientere zu ersetzen (CUDA als Beispiel für ein optimales Leistungs-/Preisverhältnis).

 

Andi, erstens weiß ich, dass der Datenfluss im fünfstelligen Bereich um eine Größenordnung größer ist. Aber ich sehe keine so schreckliche Belastung bei Alpari (fünfstellig!). Hier ist ein Bild, seien Sie nicht faul (zum Vergrößern anklicken):


Und zweitens, wie viel Prahlerei über Ihre Beteiligung an CUDA?!

2 Debugger: Es gibt viele Paare hier, alle auf М1, die Geschichte wurde mit einem Minimum von 26. Mai geladen (einige von ihnen sind tiefer), d.h. nicht weniger als 25 000 Balken in jedem Diagramm. Es gibt keine Indikatoren. Es ist nicht der passivste Moment auf dem Markt (siehe die aktuelle Grafik). Der Arbeitsspeicher wird bei Windows 7 ständig auf diese Weise geladen.

Ja, der Prozessor (Core 2 Duo E7200) ist ausgelastet, aber wir sprechen hier nicht von Zahlen in der Größenordnung von "25-30% Minimum".

Dann noch eine Frage: Wie viele Zeichen haben Sie in MarketWatch?

 

Ich habe 28 Paare auf Alpari, von denen 7 Fenster geöffnet sind, belegter Speicher: 20.800 (privater Arbeitsspeicher) 60.320(zugewiesener Speicher)

MT4-Einstellungen:

Max. Balken pro Fenster: 65000

Maximale Anzahl von Balken im Verlauf: 512000

 
Mathemat:

1. Erstens weiß ich, dass der Datenfluss im fünfstelligen Bereich um eine Größenordnung größer ist. Aber ich sehe keine so schreckliche Belastung bei Alpari (fünfstellig!). Hier ist ein Bild, seien Sie nicht faul (zum Vergrößern anklicken):

2. und zweitens, wie sehr Sie mit Ihrer Beteiligung an CUDA prahlen können!

1. eine Größenordnung mehr an Eingabedaten kann für einige Hochfrequenz-EAs kritisch sein. Es mag für Ihren EA nicht kritisch sein, aber das bedeutet nicht, dass es für alle gilt.

Ich habe mit CUDA nichts zu tun, aber vielleicht können Sie eine andere Option mit einem besseren Preis-Leistungs-Verhältnis anbieten, um das Problem der CPU-Belastung mit den Berechnungen, die Sie wirklich benötigen, zu lösen?

 
Andrei01:

1. eine Erhöhung der Eingangsdaten um eine Größenordnung kann für einige Hochfrequenz-EAs entscheidend sein.

Nun, das ist es, worüber sie hier sprechen.

Es geht nicht um das Terminal und unzureichende EAs, Indikatoren usw..

 
Ich habe Indizes für alle 16 Paare. Für jedes Paar gibt es 2 separate Indizes.
 

1. Ich habe absichtlich alle Berechnungen deaktiviert, um zu zeigen, dass das Terminal selbst fast nichts mit dieser Situation zu tun hat. Der Themenstarter gab an, dass die minimale CPU-Auslastung bei Alpari 25-30% beträgt.

2. Nein, das kann ich nicht und werde ich auch nicht tun: In diesem Thema geht es nicht um die Optimierung des Preis-Leistungs-Verhältnisses. Das Problem ist nur die Leistung.

Ich vermute, dass der Fehler entweder in übermäßigen Einstellungen des Terminals oder in zu häufigen und nicht optimierten Berechnungen liegt. Und die Berechnungen sind hier eindeutig solide.

Grund der Beschwerde: