Pensieri generali quando si tratta di processi a bassa latenza nel trading:
quando si va a valori di 10 ms per giro e sotto, non si ha quasi nessuna garanzia per la stabilità della latenza
se avete un mucchio di reti davanti a voi, la stabilità della latenza è un regalo, non una garanzia
non avete alcun controllo sulle reti dei vostri pari e sulla loro larghezza di banda e latenza.
Per avere una garanzia, bisogna eliminare tutti gli intermediari dalla rete.
per garantire, devi investire nel tuo hardware (larghezza di banda, computer, router) e controllare il percorso massimo
devi essere uno smanettone e un perfezionista.
I broker e i sistemi che sono technogeeks stanno chiaramente lavorando sulla loro infrastruttura tecnologica e investendo per migliorarla. Ma non tutti lo fanno, purtroppo.
Il terminale mostra l'ora locale di registrazione/ricezione del segnale sul vostro terminale, non l'ora esatta di ogni passo di esecuzione sul lato remoto.
In questo caso, hai ricevuto tutte le risposte (sia la conferma dal server MT5 che la conferma del piazzamento dell'ordine sulla borsa) nello stesso momento 029. Poiché ci sono molte reti tra di voi, non c'è garanzia che qualsiasi pacchetto vi venga consegnato istantaneamente nel tempo minimo di ping. Un piccolo ingorgo nella rete o una mancanza di larghezza di banda della rete (per esempio al broker) causerà l'accumulo di pacchetti che saranno poi consegnati in lotti.
Per questo non si possono contare i tempi delle diverse tappe se ci sono problemi con la rete. In una rete ideale, vicina al server del broker, si può ancora contare su qualche garanzia di latenza minima e contare il tempo dei passi intermedi.
La risposta "Ho una rete perfetta, non posso lamentarmi" non è appropriata. Perché stiamo parlando di tempi completamente diversi, che sono al di là della percezione umana in condizioni normali.
Cioè come qui:
2016.10.1010:00:05.148 Trades 'xxxxx': buy limit 5.00 RTS-3.17 at 988502016.10.1010:00:05.148 Trades 'xxxxx': sell limit 5.00 RTS-3.17 at 997802016.10.1010:00:05.154 Trades 'xxxxx': accepted buy limit 5.00 RTS-3.17 at 988502016.10.1010:00:05.154 Trades 'xxxxx': accepted sell limit 5.00 RTS-3.17 at 997802016.10.1010:00:05.155 Trades 'xxxxx': buy limit 5.00 RTS-3.17 at 98850 placed for execution in6.904 ms
2016.10.1010:00:05.156 Trades 'xxxxx': sell limit 5.00 RTS-3.17 at 99780 placed for execution in7.850 ms
fxsaber: Le domande sembravano riguardare centinaia e migliaia di millisecondi.
In pratica, avendo costruito una buona infrastruttura e godendo di 3-4 ms di esecuzione per giro con provaders di liquidità accuratamente assemblati, come un broker maturo, le persone sono stupefatte quando vedono picchi periodici di 700-1500 ms dopo essere andati in produzione. E i costruttori di sistemi perfetti devono conviverci e adattarsi.
Quindi questa è la realtà: non c'è nessuna garanzia di stabilità della latenza minima.
Soprattutto in un ambiente con tante tappe intermedie.
Ecco una grande caratteristica per gli sviluppatori per riprodurre i freni!
Ora non sarà più possibile dire "non possiamo vedere i freni".
Gli sviluppatori dovrebbero iniziare a mettere delle richieste limite all'apertura della sessione e monitorare il tempo di esecuzione. Se vedono la lentezza se ne occuperanno localmente.
Al momento la situazione è deprimente, purtroppo.
Sulla vostra infrastruttura. Pubblicando i log dei primi minuti del mercato aperto?
In pratica, avendo costruito una buona infrastruttura e godendo di 3-4 ms di esecuzione per giro con provaders di liquidità accuratamente assemblati, come un broker maturo, le persone sono stupefatte nel sedersi sul loro culo a terra quando vedono picchi periodici di 700-1500 ms dopo essere andati in produzione. E i costruttori di sistemi perfetti devono conviverci e adattarsi.
Quindi questa è la realtà: non c'è alcuna garanzia di stabilità della latenza minima.
Soprattutto in un ambiente con tante tappe intermedie.
Scusa Renat, ma non è possibile che si tratti di latenza di rete:
2016.09.2103:31:10.568 Terminal Открытие Брокер MetaTrader 5 СР x64 build 1430 started (ОАО '' Брокерский дом '' ОТКРЫТИЕ'')
2016.09.2117:30:00.156 Trades 'xxxxx': modify order #44620664 buy limit 5.00 ROSN-3.17 at 36438 sl: 0 tp: 0 -> 36470, sl: 0 tp: 0 placed for execution in19.086 ms
2016.09.2117:30:00.157 Trades 'xxxxx': buy limit 5.00 BR-12.16 at 47.66 placed for execution in19.185 ms
2016.09.2117:30:00.160 Trades 'xxxxx': deal #29616740 buy 5.00 BR-12.16 at 47.66 done (based on order #44620667)
2016.09.2117:30:01.064 Trades 'xxxxx': exchange sell 5.00 BR-11.16 at market
2016.09.2117:30:02.004 Trades 'xxxxx': cancel order #44620664 buy limit 5.00 ROSN-3.17 at 364702016.09.2117:30:04.827 Trades 'xxxxx': accepted exchange sell 5.00 BR-11.16 at market
2016.09.2117:30:04.827 Trades 'xxxxx': exchange sell 5.00 BR-11.16 at market placed for execution in3764.451 ms
2016.09.2117:30:04.829 Trades 'xxxxx': deal #29616752 sell 5.00 BR-11.16 at 47.33 done (based on order #44620682)
2016.09.2117:30:05.799 Trades 'xxxxx': cancel order #44613523 sell limit 1.00 TRNF-3.17 at 1493982016.09.2117:30:07.929 Trades 'xxxxx': accepted cancel order #44620664 buy limit 5.00 ROSN-3.17 at 364702016.09.2117:30:07.929 Trades 'xxxxx': cancel order #44620664 buy limit 5.00 ROSN-3.17 at 36470 placed for execution in5926.927 ms
2016.09.2117:30:08.738 Trades 'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32276 sl: 0 tp: 0 -> 32278, sl: 0 tp: 02016.09.2117:30:08.775 Trades 'xxxxx': accepted cancel order #44613523 sell limit 1.00 TRNF-3.17 at 1493982016.09.2117:30:08.776 Trades 'xxxxx': cancel order #44613523 sell limit 1.00 TRNF-3.17 at 149398 placed for execution in2977.588 ms
2016.09.2117:30:09.585 Trades 'xxxxx': accepted modify order #44620340 buy limit 1.00 TATN-3.17 at 32276 sl: 0 tp: 0 -> 32278, sl: 0 tp: 02016.09.2117:30:09.590 Trades 'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32276 sl: 0 tp: 0 -> 32278, sl: 0 tp: 0 placed for execution in852.561 ms
2016.09.2117:30:09.597 Trades 'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32278 sl: 0 tp: 0 -> 32312, sl: 0 tp: 02016.09.2117:30:09.637 Trades 'xxxxx': accepted modify order #44620340 buy limit 1.00 TATN-3.17 at 32278 sl: 0 tp: 0 -> 32312, sl: 0 tp: 02016.09.2117:30:09.638 Trades 'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32278 sl: 0 tp: 0 -> 32312, sl: 0 tp: 0 placed for execution in40.658 ms
2016.09.2117:30:10.053 Trades 'xxxxx': cancel order #44620340 buy limit 1.00 TATN-3.17 at 323122016.09.2117:30:10.075 Trades 'xxxxx': accepted cancel order #44620340 buy limit 1.00 TATN-3.17 at 323122016.09.2117:30:10.079 Trades 'xxxxx': cancel order #44620340 buy limit 1.00 TATN-3.17 at 32312 placed for execution in25.974 ms
2016.09.2117:30:44.537 Trades 'xxxxx': sell limit 1.00 BR-12.16 at 48.042016.09.2117:30:44.669 Trades 'xxxxx': accepted sell limit 1.00 BR-12.16 at 48.042016.09.2117:30:44.669 Trades 'xxxxx': sell limit 1.00 BR-12.16 at 48.04 placed for execution in132.352 ms
2016.09.2117:30:45.165 Trades 'xxxxx': sell limit 10.00 Si-6.17 at 704492016.09.2117:30:45.179 Trades 'xxxxx': accepted sell limit 10.00 Si-6.17 at 704492016.09.2117:30:45.180 Trades 'xxxxx': sell limit 10.00 Si-6.17 at 70449 placed for execution in14.720 ms
Pensieri generali quando si tratta di processi a bassa latenza nel trading:
I broker e i sistemi che sono technogeeks stanno chiaramente lavorando sulla loro infrastruttura tecnologica e investendo per migliorarla. Ma non tutti lo fanno, purtroppo.
Il terminale mostra l'ora locale di registrazione/ricezione del segnale sul vostro terminale, non l'ora esatta di ogni passo di esecuzione sul lato remoto.
In questo caso, hai ricevuto tutte le risposte (sia la conferma dal server MT5 che la conferma del piazzamento dell'ordine sulla borsa) nello stesso momento 029. Poiché ci sono molte reti tra di voi, non c'è garanzia che qualsiasi pacchetto vi venga consegnato istantaneamente nel tempo minimo di ping. Un piccolo ingorgo nella rete o una mancanza di larghezza di banda della rete (per esempio al broker) causerà l'accumulo di pacchetti che saranno poi consegnati in lotti.
Per questo non si possono contare i tempi delle diverse tappe se ci sono problemi con la rete. In una rete ideale, vicina al server del broker, si può ancora contare su qualche garanzia di latenza minima e contare il tempo dei passi intermedi.
La risposta "Ho una rete perfetta, non posso lamentarmi" non è appropriata. Perché stiamo parlando di tempi completamente diversi, che sono al di là della percezione umana in condizioni normali.
Cioè come qui:
Perché non fai un semplice registro, come
Il server commerciale ha ricevuto un ordine - tempo del server commerciale
Il server commerciale ha dato alla borsa un ordine - tempo del server commerciale
Il server commerciale ha ricevuto una risposta dallo scambio - l'ora del server commerciale.
Allora avreste chiuso questo lungo thread una volta per tutte.
Aggiunto.
E inviare queste volte (tutte e tre) invece diaccettare emettere in esecuzione
Pensieri generali quando si tratta di processi a bassa latenza nel trading:
Le domande sembravano riguardare centinaia e migliaia di millisecondi.
In pratica, avendo costruito una buona infrastruttura e godendo di 3-4 ms di esecuzione per giro con provaders di liquidità accuratamente assemblati, come un broker maturo, le persone sono stupefatte quando vedono picchi periodici di 700-1500 ms dopo essere andati in produzione. E i costruttori di sistemi perfetti devono conviverci e adattarsi.
Quindi questa è la realtà: non c'è nessuna garanzia di stabilità della latenza minima.
Soprattutto in un ambiente con tante tappe intermedie.
Forum sul trading, sistemi di trading automatico e test di strategie di trading
FORTI. Domande sull'esecuzione
fxsaber, 2016.10.10 11:38
Ecco una grande caratteristica per gli sviluppatori per riprodurre i freni!
Ora non sarà più possibile dire "non possiamo vedere i freni".
Gli sviluppatori dovrebbero iniziare a mettere delle richieste limite all'apertura della sessione e monitorare il tempo di esecuzione. Se vedono la lentezza se ne occuperanno localmente.
Al momento la situazione è deprimente, purtroppo.
In pratica, avendo costruito una buona infrastruttura e godendo di 3-4 ms di esecuzione per giro con provaders di liquidità accuratamente assemblati, come un broker maturo, le persone sono stupefatte nel sedersi sul loro culo a terra quando vedono picchi periodici di 700-1500 ms dopo essere andati in produzione. E i costruttori di sistemi perfetti devono conviverci e adattarsi.
Quindi questa è la realtà: non c'è alcuna garanzia di stabilità della latenza minima.
Soprattutto in un ambiente con tante tappe intermedie.
Scusa Renat, ma non è possibile che si tratti di latenza di rete:
Non puoi semplicemente controllare? sulla tua infrastruttura. Pubblicando i log dei primi minuti del mercato aperto?
Cosa c'è da controllare se non abbiamo praticamente nessun controllo su niente.
Hanno già mostrato dei test con la prova della norma all'apertura del mercato. Ma è un caso in cui una cosa tira l'altra, a quanto pare.
Ho già detto più volte sopra che non c'è garanzia di stabilità della latenza.
Se fossimo un broker, sarebbe un'altra cosa: non saremmo avari dell'infrastruttura più efficiente e ottimizzeremmo il massimo numero di rotte.
Scusa Renat, ma non è possibile che si tratti di latenza di rete:
State prendendo in considerazione SOLO i ritardi della vostra rete. Stai andando bene. E a un paio di passi da te tutto va bene.
Il problema è altrove. Leggete tutto quanto sopra, per favore. E magari leggere tra le righe.
Scusa Renat, ma non è possibile che si tratti di latenza di rete: