Sorry jetzt für die noob Frage aber ich würde gerne wissen wie das mit FOREX jetzt genau fuzt.

Ein Broker hat eine bzw. mehrere Banken auf der anderen Seite.

 

Bank A hat ask 1.0015 bid 1.0013 der dem Kunden via ECN (oder sonst wie) angeboten wird. Spread=2

 

Hat der Broker 2 Banken im Hinterhof:

Bank A hat ask 1.0016 bid 1.0014

Bank B hat ask 1.0015 bid 1.0013

Broker somit ask 1.0015 bid 1.0014 was dem Kunden via ECN (oder sonst wie) angeboten wird. Spread=1

 

Entsprechend bessere Spreads bei mehreren Banken.

 

Nun die Frage…

Ihr bzw. im Netz spricht man immer wieder vom „Markt“ was ja für Future/Aktien ja auch zutrifft. Was ist jetzt der Markt bei FX?

Ich sehe nur Banken die anscheinend selbst Marketmaker sind. Ich lese immer wieder vom „der Markt bestimmt den Preis“…. Ich traue mich dann nie zu fragen „welcher Markt?“

 

Irgendwie müssen die Banken doch untereinander abgeglichen sein sonst wäre Arbitrage für Broker (glaub teilweise bis zu 13 Banken gelesen zu haben bei einem Broker) mit mehreren Banken eine Leichtigkeit.

 

Bei Aktien z.B. kann ich ja auch den Marktplatz selbst bestimmen die teilweise erhebliche Preisunterschiede haben. Arbitrage ist hier aber nicht möglich da die Gebühren noch viel höher sind. Bei Forex fallen diese horrenden Gebühren ja weg also muss eine andere Art des Ausgleiches vorhanden sein.

Der Ökonom würde vor der Bewilligung auch nur einer Personen-Minute, eines Cents oder jeder anderen Ressource (teils schon vollautomatisch im Unterbewußten) unter anderem fragen:

 

Und genau deswegen bin ich kein Ökonom! Ich geb dir in vielen Bereichen Recht, aber man lernt nunmal am meisten wenn man es einfach versucht. Wer sich vor jedem Schritt fragt ob er den jetzt auch wirklich machen soll, kommt nicht weit.

Vor allem muss es ja nicht immer nur ökonomische Gründe für eine Handlung geben oder? Viele große Entdeckungen/Erfindungen wären nie gemacht worden, wenn sich die Erfinder/Entdecker zuvor diese ökonomischen Fragen gestellt hätten (meine Meinung).

Nochmal zum "Sleep" Problem:

Ich habs jetzt mal mit einer solchen Schleife getestet:

 

start=TimeLocal();
  counter=0;
  while(counter < 5000)
  {
    counter++;
    Sleep(10);
  }
  end=TimeLocal();

(da MQL ja nur in Sekunden die Zeit messen kann muss man den Mittelwert von mehreren Durchläufen nehmen).

Die Schleife selber dürft keine zusätzliche Zeit brauchen weil ohne das Sleep kann man auch 100000 Durchläufe zeitlich noch nicht messen.

 

Ergebnis bei mir: (auf verschiedensten MT Instanzen)

Sleep(1) und Sleep(10) brauchen 15.6 Millisekunden, danach braucht Sleep(X) X*1.09 Millisekunden...

 

Falls jemand das bei sich testen will: ich hab ein kleines Script geschrieben. Es braucht keine Rechenleistung und tut im wesentlichen nix außer die obige Schleife für mehrere Werte testen und dann das Ergebnis ausgeben.

sSleepTest.mq4

Einfach auf einen Chart ziehen und warten bis im Experten-Reiter das Ergebnis geprintet wird. (Bei mir dauerts ca 40 Minuten)

 

Wäre interessant ob mein PC vergessen hat die man die Uhr liest oder ob das allgemein so ist.

Einfach auf einen Chart ziehen und warten bis im Experten-Reiter das Ergebnis geprintet wird. (Bei mir dauerts ca 40 Minuten)

 

Habe das Skript mal gestartet...

nette info :-)

12:31:02 sSleepTest EURUSD-fx,M1: loaded successfully

12:31:02 sSleepTest EURUSD-fx,M1: Start: 1250166683

12:31:23 sSleepTest EURUSD-fx,M1: checkpoint 1250166690

12:32:22 sSleepTest EURUSD-fx,M1: checkpoint 1250166742

12:40:56 sSleepTest EURUSD-fx,M1: checkpoint 1250167256

12:49:19 sSleepTest EURUSD-fx,M1: checkpoint 1250167759

12:57:42 sSleepTest EURUSD-fx,M1: checkpoint 1250168262

13:07:47 sSleepTest EURUSD-fx,M1: checkpoint 1250168867

13:07:47 sSleepTest EURUSD-fx,M1: Sleep(1) needs 1.4 Milliseconds

13:07:47 sSleepTest EURUSD-fx,M1: Sleep(10) needs 10.4 Milliseconds

13:07:47 sSleepTest EURUSD-fx,M1: Sleep(100) needs 102.8 Milliseconds

13:07:47 sSleepTest EURUSD-fx,M1: Sleep(1000) needs 1006 Milliseconds

13:07:47 sSleepTest EURUSD-fx,M1: Sleep(10000) needs 10060 Milliseconds

13:07:47 sSleepTest EURUSD-fx,M1: Sleep(100000) needs 100800 Milliseconds

13:07:47 sSleepTest EURUSD-fx,M1: Sleep(100000) alone needs 101 Seconds

13:07:47 sSleepTest EURUSD-fx,M1: uninit reason 0

13:07:47 sSleepTest EURUSD-fx,M1: removed

heisst doch eigentlich dass es sich bei mir innerhalb der Parameter ist :)

wundert mich nur dass das skript so lange dafür braucht.

@ Mythos

 

Ja, etwas Aufwand muß man für eine richtig programmierte Synchronisation schon treiben. Der ist aber zwingend notwendig, weil sonst in einem längeren Einsatz-Zeitraum andauernd undefinierte Zustände auftreten.

 

Die Plump-Methode ist übrigens die manuelle Anlage eines leeren Lock-Files zum Lesen und Schreiben als Synchronisations-Hilfsmittel. Ein Prozeß darf dann nur etwas mit den derart manuell geschützten Daten machen (Lesen oder Schreiben), wenn er das File geöffnet bekommt. Ansonsten hat es gerade der andere Prozeß geöffnet und beansprucht den Zugriff auf die Daten. Leider muß man dabei auch pollen (= beschäftigt warten, in einer Schleife mit Sleep() wieder und wieder prüfen), was man neben anderem mit den Betriebssystem-Funktionen vermeiden will.

 

Auf Sleep() kann man sich so genau nie verlassen. Normalerweise sollte man mittels Synchronisations-Funktionen oder Callback-Events punktgenau synchronisieren. Auch wenn Programmierer oft "auf die Schnelle" Sleep() benutzen, stimmt, wo im Near-Realtime-Bereich mit Sleep() (& Co. in anderen Umgebungen) hantiert wird, meistens etwas nicht mit der richtigen Nutzung eines ordentlichen Synchronisations-Protokolles und führt zu oft kaum nachvollziehbaren und teils nur schwer wiederholbaren Effekten.

 

Bei Sleep() sollte immer mit einer größeren systematischen Ungenauigkeit gerechnet werden. Sleep() ist nicht für die harte Realtime-Programmierung gedacht, sondern für die Wiederholung vormals wegen mangelnder Ressourcen-Verfügbarkeit blockierter Operationen, wie History-Einlesen oder Order-Ausführungen. Dafür reicht es, für Realtime-Zeit-Messungen nicht.

 

Die können mit den speziellen High-Resolution-Timern bei den Timer-Funktionen des Betriebssystems ausgeführt werden. Eine genauere Auflösung von Timern, die Aktionen auslösen macht in der Struktur von Windows auch keinen Sinn, da durch die minimal an einen Prozeß vergebenen Zeitscheiben und die Unmengen von der Hardware ausgelösten höher priorisierten Interrupt-Anforderungen eine solche Genauigkeit nicht durchgesetzt werden kann, im Gegensatz zur nachträglichen Messung.

heisst doch eigentlich dass es sich bei mir innerhalb der Parameter ist :)

wundert mich nur dass das skript so lange dafür braucht.

Warum das Skript so lang braucht is schnell erklärt.

Wenn ich Sleep(10) aufrufe sollte es ca 0.010 Sekunden brauchen. Das kann man in MT nicht messen. Also muss man Sleep(10) sooft aufrufen, bis man ein sinnvoll messbares Ergebnis hat und dann durchdividieren. Bei 50 Sekunden Messzeit ist +- 1 Sekunde schon noch eine "starke" Abweichung deswegen sind die Schleifen so eingestellt das sie ca. 10 Minuten laufen. Also jede Variante wird ca. 10 Minuten lang ausgeführt und dann überprüft wie lang das gedauert hat. Deswegen die lange Laufzeit.

 

Dein PC weiß scheinbar wie man die Uhr liest ;) Obwohl du auch einen Overhead mit Faktor 1.006 hast... (aber besser als meine 1.09 !)

 

Aber Krümel hat ja schon schön aufgezeigt das das scheinbar normal ist :( muss man halt den Intervall Parameter anpassen. Habs mal ohne Sleep getestet, die aktuelle Version braucht 0.3 Millisekunden pro Durchlauf (mit dlls) also dlls sind in keiner Weise langsamer

Normalerweise sollte man mittels Synchronisations-Funktionen oder Callback-Events punktgenau synchronisieren.

 

Wenn du mir sagen kannst wie man das sinnvoll in MQL reinbringt würds mich interessieren sowas mal auszuprobieren.

Soda, es ist wiedermal Zeit für einen Bericht von der "Front" ;)

 

Da dlls keine Performanceprobleme machen, hab ich mir gedacht "Wieso nicht mehrere Broker?".

Dabei ergeben sich viele neue Probleme was die "Synchronisation" (nicht im EDV-technischen Sinn sondern von der Strategie her) betrifft. Also das "wer hat gerade wieviele Positionen offen" ist nicht das Problem, das Problem ist eher das "Wer sollte gerade wieviele Positionen offen haben?". Vor allem wieder das Problem: Was ist wenn einer nicht ausgeführt wird oder möglicherweise sogar den Einstieg verschläft...

 

Und noch ein Problem kommt dazu: Das ganze ist mit 3 Brokern schon ein bissl komplex zum verfolgen. Und wenn dann 3-4 Orders im Kreis laufen bzw. das System sagt das irgendwo was nicht stimmt, wird einem fast schon schwindlig beim zuschauen und erst recht beim Versuch herauszufinden was los ist...

 

Aber es ist mal lustig zum zuschauen.

Zeittechnisch schauts auch gut aus, ein Durchlauf von einer Instanz braucht bei 3 aktiven Instanzen (inkl. ein bissl grafischem Output fürs Auge) etwas über 8 Millisekunden also weit weg von kritisch.

2009.08.14 14:09:56 sSleepTest EURCHF,M5: Sleep(100000) alone needs 100 Seconds

2009.08.14 14:09:56 sSleepTest EURCHF,M5: Sleep(100000) needs 100200 Milliseconds

2009.08.14 14:09:56 sSleepTest EURCHF,M5: Sleep(10000) needs 10000 Milliseconds

2009.08.14 14:09:56 sSleepTest EURCHF,M5: Sleep(1000) needs 1000 Milliseconds

2009.08.14 14:09:56 sSleepTest EURCHF,M5: Sleep(100) needs 100 Milliseconds

2009.08.14 14:09:56 sSleepTest EURCHF,M5: Sleep(10) needs 10 Milliseconds

2009.08.14 14:09:56 sSleepTest EURCHF,M5: Sleep(1) needs 1 Milliseconds

2009.08.14 14:09:56 sSleepTest EURCHF,M5: checkpoint 1250258996

2009.08.14 13:59:55 sSleepTest EURCHF,M5: checkpoint 1250258395

2009.08.14 13:51:35 sSleepTest EURCHF,M5: checkpoint 1250257895

2009.08.14 13:43:15 sSleepTest EURCHF,M5: checkpoint 1250257395

2009.08.14 13:34:55 sSleepTest EURCHF,M5: checkpoint 1250256895

2009.08.14 13:34:05 sSleepTest EURCHF,M5: checkpoint 1250256845

2009.08.14 13:34:00 sSleepTest EURCHF,M5: Start: 1250256840

sollte ein vermaschtes netz das problem nicht lösen? also jedes paar seine eigenen variabeln. sollte doch mit arrays doch kein problem darstellen. da jedes instanz seine eigene ID erhält sollte eine 2 dimensionale array gut gehen.

sollte ein vermaschtes netz das problem nicht lösen? also jedes paar seine eigenen variabeln. sollte doch mit arrays doch kein problem darstellen. da jedes instanz seine eigene ID erhält sollte eine 2 dimensionale array gut gehen.

 

man muss dazusagen das ich gerade versuche mit minimalem Aufwand (auch was Codezeilen angeht) das ganze zu machen ;)

 

so ein Netz wäre sicher möglich, aber das wäre dann ja ziemlich das gleiche als würde ich für jede Kombination einen eigenen "simplen" laufen lassen. (Also mit unterschiedlichen Dateinamen etc.).

Die große Vorteile von mehreren Brokern wäre aber doch so ein "kreisgeschäft" oder?

Gap BidA > AskB => A verkauft, B kauft

Gap BidB > AskC => B verkauft (schließt die Order), C kauft -> B ist flat

Gap BidC > AskA => C verkauft (schließt), A kauft(schließt) -> alle sind flat und es wurde optimalerweise bei jeder Transaktion ein "Gewinn" gemacht.

 

Würde man das nur auf die Einzelpaare hin betrachten, so würde nach der Aktion Jeder eine Long und eine Short Position haben, die formal nichts miteinander zu tun haben.

Um das mit dem Netz zu machen müsste man dann vermutlich intern ein bissl mehr aufwand betreiben um die Positionen herumzuschieben.

Und falls eine Order nicht ausgeführt werden kann etc. hat man wieder das Problem zuzuordnen mit wem das jetzt war. D.h. man müsste den Orders (am besten in der MagicNumber) mitgeben aus welchem Broker-Paar es kommt und dann jedesmal vergleichen ob alle Orders die man wollte auch da sind. bzw. muss man dann das "gesamte" Netz immer wieder abgleichen.

 

 

Derzeit gibt jede Instanz den anderen nur ihre aktuelle Positionsgröße bekannt und falls es hier zu einer Unstimmigkeit kommt wird bei dem Broker mit der größen Position die Position entsprechend reduziert. (zugegeben, das könnte man ändern auf "der Broker der als letztes eine Aktion hatte")

Broker1 ID1

Broker2 ID2

Broker3 ID3

 

0=keine posi

1=long

2=short

 

Gap BidA posi[1][2]=1; posi[2][1]=2;

Schleifenabfrage:

Broker1

Posi[1][x]

 

Sie getrennt zu betrachten hat einfach den Vorteil dass die Zugehörigkeit eindeutig ist auch bei Fehlern.

Dein ineinander greifen hat zwar den Vorteil dass ich profitablere Posis habe aber Fehleranfälliger ist.

Sie getrennt zu betrachten hat einfach den Vorteil dass die Zugehörigkeit eindeutig ist auch bei Fehlern.

Dein ineinander greifen hat zwar den Vorteil dass ich profitablere Posis habe aber Fehleranfälliger ist.

 

Stimmt, aber wenn man sie sowieso getrennt betrachtet, ist es noch sicherer, es mit eigenen EAs zu machen (also jedes Paar kriegt einen eigenen DAteinamen und Chart. Damit kann man dann jedes Paar auch leichter auskoppeln etc.

 

Ich denk das ein zusammenziehen von "unabhängigen" Systemen in ein Programm (EA/Script) unnötiges Risiko produziert. Vor allem weil die einzelne Variante gut läuft.

(Ich kenn mich: Je mehr Code und komplexität, desto höher die Fehleranfälligkeit und desto schwerer das finden des Fehlers ;)

 

Ich wollt einfach das "große Miteinander" probieren ;)

@ Mythos

 

Die Idee mit mehreren Brokern sehe ich genauso und ich würde mich auch daran machen, die von Dir angefragte Kommunikation und Synchronisation anzuarbeiten. Da Dir, als mal vermuteter Nicht-C/Windows-Super-Crack aber mit ein paar hingeworfenenen Bemerkungen kaum geholfen ist, muß ich es wohl selber programmieren, wozu ich aber nicht vor Mitte nächster Woche komme.

 

Mir schwebt da eine ganz klare Client-/Server-Lösung vor, bei der auf MT-Seite die Kommunikation über eine recht einfache Client-DLL erfolgt, die 2 Threads benutzt, einen zum Versenden der aktuellen Kurs-Daten dieser MT-Instanz an den Server und einen zum Erhalt von Handels-Anforderungen bei im Server erkannten Arbitrage-Möglichkeiten, vielleicht bei Erfordernis noch einen dritten zum Management.

 

Die Verwaltung aller Kommunikationen, der gelieferten Kurse, der abgeleiteten Handels-Anforderungen und der Zurechnung zu den beteiligten Systemen findet auf dem Server statt, wobei die einfachste Lösung pro angemeldetem MT-System zwei Threads benötigt, die aber bei Nutzung asynchroner I/O auch ggf. auf 2 Kommunikations-Threads für jeweils ein Dutzend angeschlossene MT-Systeme reduziert werden können. Dazu kommt noch ein Management-Thread, ein Thread zur Anmeldung neuer Systeme und bei guter Laune noch einer, der das ganze beobachbar macht, z. B. für eine Web-Site.

 

Für die Kommunikation zwischen der Client-DLL und dem Server nehme ich TCP/IP-Sockets, womit das ganze auch sofort Internet-fähig ist und nicht auf lokale Windows-Systeme beschränkt ist.

 

Gut finde ich, daß Du Dich jetzt dem inhaltlichen Problem der fehlenden Trade-Synchronisation (insbesondere bei Nicht-Zustandekommen der Gegenseite eines Trades) näherst, denn da ist einiges an fachlichen Ideen nötig, um nicht durch einen einzigen Ausfall einen riesigen Verlust zu erleiden. Die Verfolgung beauftragter und offener Trades sollte man nicht von der optischen Auffasssung abhängig machen, sondern streng algorithmisch im Server-Modul. Die muß ja nur inhaltlich richtig sein, nicht aber auf Anhieb zu überschauen.

 

Die erste Phase der Nutzung sollte aber die Nutzung des Systems zur Ermittlung der Kurs-Stellungs-Schwankungen im Tagesverlauf sein, um sinnvolle Zeiträume für den Ausgleich der Differenzen zu haben, denn wegen der fehlenden Transferierbarkeit der Assets muß die Position ja beim gleichen Dienstleister auch irgendwann wieder glattgestellt werden.

 

Ebenso könnte man außerhalb der eigentlichen Arbitrage-Funktion mal prüfen, ob die Anbieter unterschiedliche Kurse stellen je nach bereits eingegangener Position, so etwa flat xx50 - xx52, short xx52 - xx54, long xx48 - xx50 und wie lange sie das bei Nachkäufen aufrecht erhalten.

 

Bei aller Aufgeschlossenheit bei der programmtechnischen Umsetzung, gehe ich immer noch davon aus, daß nach allen Transaktionskosten keine dauerhafte Gewinnerzielung möglich sein wird. Weiterhin wirft spätestens das Zusammenschalten von Systemen verschiedener Nutzer einige juristische Probleme auf und selbst das Zusammenschalten von Systemen des gleichen Nutzers wird durch die AGB der Anbieter (wenngleich höchstwahrscheinlich juristisch unwirksam) meistens ausgeschlossen.

als mal vermuteter Nicht-C/Windows-Super-Crack

C kann ich schon, aber mit Multi-Thread Systemen etc. hab ich mich noch nie befasst.

 

wozu ich aber nicht vor Mitte nächster Woche komme.

Freu mich wenn du mitmachst, da kann ich sicher viel lernen. Ich bin nur die nächsten 2 Wochen nicht im Lande, also nur keinen Stress ;)

 

Gut finde ich, daß Du Dich jetzt dem inhaltlichen Problem der fehlenden Trade-Synchronisation (insbesondere bei Nicht-Zustandekommen der Gegenseite eines Trades) näherst,

Näherst? das war das erste worüber ich mir Gedanken gemacht habe ;) Ich wollte es nur erstmal bestmöglich hinkriegen ohne einen solchen Programmiertechnischen Aufwand zu betreiben wie du ihn gerade beschrieben hast. Unter anderem auch um mal zu testen wie das ganze überhaupt aussieht, und was machbar sein könnte.

 

Da ich wie gesagt die nächsten 2 Wochen weg bin, hier mal der derzeitige Stand des Multi-Broker Systems.

Es ist recht "dynamisch" programmiert, wodurch manche "Features" zwar noch vorhanden sind, aber nicht mehr benötigt werden. Aber es war für mich mehr ein learning-by-doing ;)

 

[hide]eRobinHoodMulti.mq4

[/hide]

EDIT:

Was ich noch sagen wollte: Bei der derzeitigen (Kommunikations-)Variante über Files kommt es zwar gelegentlich zu "Verbindungsfehlern", da aber die Zeiten für das Senden einer Order (die im wesentlichen bestimmen wie lang man warten muss bevor der Alarm losgeht) sowas von weit über der Abtastrate des Marktes sind, werden solche Fehler eigentlich immer rausgefiltert und Unsynchronizitäten treten nur auf wenn wirklich eine Order nicht abgesetzt werden konnte... und das Problem kriegt man auch mit einer aufwändigen Server-Client Struktur nicht weg :(

Soda, bin mal zurück von der "einsamen" Insel.

Ich hab in den 2 Wochen den RobinHood mal mit einer mindestEinstiegsdiff von 0.00015 auf EURUSD in der Multivariante mit Alpari, MasterForex und LiteForex laufen lassen.

Lotsize 0.01 jeder Account darf maximal 0.05 Lots offen haben.

 

Derzeit Gesamt Gewinn 5.93 wobei gerade wieder 5 Positionen offen mit 1 Dollar offenem Gewinn.

Davon wurden in der letzen Woche 1.95 Dollar gemacht.

Getätigt wurden ca 3200 Trades. Also ca 0.185 Gewinn pro Trade und Lot.

 

Es bleibt also nicht viel übrig, vor allem nicht wenn man ein so geringes Einstiegsdiff verwendet.

Soda, bin mal zurück von der "einsamen" Insel.

Soda, bin mal zurück von der "einsamen" Insel.

 

You have been missed!

 

 

Schön Dich zu lesen Mythos!

Gibts noch jemanden der sich für das Thema/Projekt interessiert? Vor allem bzgl. Realtests und so ....

hab aus einem anderen thread schon gesehen wie du "zwischen" den ticks traden willst. wenn du live daten hast würde mich das schon interessieren.

dein EA oben ist schon sehr viel code zum durcharbeiten. die idee von mystart finde ich aber toll von dir

hab aus einem anderen thread schon gesehen wie du "zwischen" den ticks traden willst.

 

Genau genommen hab ich den Code dort fast direkt aus dem EA hier genommen ;)

 

Was genau meinst du mit "live Daten"? Resultate aus Livetests?

 

bzgl. Code: stimmt, aber die Idee is recht einfach, es is halt großteil viel "technisches" Zeug was man reincoden muss.

 

EDIT:

Test der letzten 2 Wochen, mit parallel 2 Parametervarianten hat auf den Demokonten 24.2 Dollar/Lot gebracht

gerade "passiert" zwischen liteforex und Alpari:

Nicht verwirren lassen, LiteForex rechnet in anderer Zeitzone (+1), es sind also beide um 11:00 passiert.

 

kurze Rechnung:

Pos1 gekauft bei 1.45995, verkauft 36 Sekunden später bei 1.45938 -> Diff: -0,00057

Pos2 verkauft bei 1.46050, zurückgekauft nach 35 Sek bei 1.45890 -> Diff: +0,00160

 

Also Einstiegsgap: 5,5 Pips, Ausstiegsgap: 4,8 Pips

 

In Summe also 10,3 Pips Gewinn in 36 Sekunden

Ja ich weiß, Demo und Ausnahme etc... aber in der Demo is es gar nicht so die Ausnahme. Ok, so extrem schon, aber in letzter Zeit schließt er fast keine Pos mehr mit Minus (also jeweils das Orderpaar betrachtet)

 

Mal sehen wie der Unterschied im realen ist.

Aus aktuellem Anlass entstaub ich den Thread hier mal.

Der liebe Kay hat uns ja auf die extremen Kursdifferenzen bei FXD aufmerksam gemacht, da hab ich mir gleich gedacht: Testen wir mal wies wirklich aussieht.

Und die Ergebnisse sind selbst für ein Demokonto abartig!

Heute Demokonto eröffnet und um 10:00 das System gestartet. Beteiligte: FXD vs. MasterForex (weil MasterForex in der Realität wenig Requotes zeigte).

Auf 4 Währungspaaren EURUSD, GBPUSD, USDJPY und EURGBP. EURGBP und USDJPY haben nur vormittag mal eine Position gemacht, und seither ruhig, aber die anderen zwei gehen gewaltig ab.

Bis jetzt sage und schreibe in summe 556 Pips bei 50 Aktionen (also 100 Positionen) . Und spannenderweise positionen in beide Richtungen. Also nicht wie gewohnt, das ein Broker immer über dem anderen quotiert, man also schnell einen gap zum einstieg findet, aber selten runter kommt und man somit schwer wieder rauskommt. Sondern wirklich beide richtungen, es gibt also immer wieder große Gaps in beide Richtungen...

 

Schade das FXD kein Centkonto anbietet, sonst würd mich echt interessieren wie stark hier in Realität die Requotes sind...

Bis jetzt sage und schreibe in summe 556 Pips bei 50 Aktionen (also 100 Positionen) .

 

das heißt, Du hast per EA 100 Positionen geöffnet/closed ?

 

Ich hoffe, ich versteh jetzt was nicht falsch - aber die 556 Pips sind dann zum Ungunsten bei FXD oder?

das heißt, Du hast per EA 100 Positionen geöffnet/closed ?

pro Broker 50 Positionen.

 

Ich hoffe, ich versteh jetzt was nicht falsch - aber die 556 Pips sind dann zum Ungunsten bei FXD oder?

jein. man kann nicht vorhersagen was passiert.

Bsp: EURUSD

16:02 hat FXD Bid 1.4799 MasterForex Ask: 1.4795 also ne (für FXD "normale") Differenz. Position wird eröffnet FXD Short, MasterForex Long.

16:19: Fxd Ask: 1.4823 MasterForex Bid: 1.4827 also Diff genau in die andere richtung-> Position wird geschlossen.

(das sind jetzt jeweils die Kurs die ich dann in der Demo wirklich gekriegt hab)

Die Pos bei FXD macht jetzt 24 Pip minus, die bei MF 32 plus.

 

Die Frage ist: ist das jetzt ein Gewinn für FXD und Verlust für MF?

 

Konkret hab ich gerade am Demokonto bei MF 1015 Pips plus bei FXD 420 Pips minus. so gesehen also einen Gewinn für FXD und Verlust für MF. Wäre der Kurs in der Zeit aber mehr gefallen (heute ist EURUSD ja eher gestiegen), dann wär mein Konto bei FXD im Plus und bei MF im Minus...

 

Grund für meinen Gewinn ist auf alle Fälle die Differenz zwischen den Brokern, aber welcher der Broker jetzt auf lange Sicht dabei gewinnt und welcher verliert, oder ob beide ein bissl verlieren entscheided sich rein durch die Bewegung des Marktes... (ich würd ja tippen das sich die Konten auf lange sicht die Waage halten und somit beide Broker ein bissl verlieren)