FORTI. Problemi di applicazione - pagina 5
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Signoripapaklass eolyakish!
Non è chiaro perché hai iniziato una corrispondenza personale in questo importante argomento, dopo che Renat ha confermato la presenza di
"Errore fluttuante nella velocità delle risposte al terminale.
Ha anche promesso che MQ migliorerà il traffico complessivo di esecuzione degli ordini.
E comunque, come si può controllare qualcosa nelle cucine in forex?
In effetti, abbiamo pubblicato molte informazioni utili:
- le loro configurazioni di server;
- metodi di controllo della rete (ping -t);
- olyakish ha pubblicato il suo lavoro sulla selezione di un server virtuale.
Ma sembra che non ne abbiate bisogno.
Ci sono molte cose nel forex che sono testabili. E se pensate che non c'è manipolazione nella borsa, allora vi capisco. :)
Signoripapaklass eolyakish!
Non è chiaro perché hai iniziato una corrispondenza personale in questo importante argomento, dopo che Renat ha confermato la presenza di
"Errore fluttuante nella velocità delle risposte al terminale.
Ha anche promesso che MQ migliorerà il traffico complessivo di esecuzione degli ordini.
E comunque, come si può controllare qualcosa nelle cucine in forex?
Ecco il vero LMAX di API .NET
La performance sulle notizie è di 12ms con un ping di 8ms (misurato usando un timer ad alta frequenza)
Penso che questo sia un punto di riferimento
Ecco il vero LMAX di API .NET
La performance sulle notizie è di 12ms con un ping di 8ms (misurato usando un timer ad alta frequenza)
Penso che questo sia un punto di riferimento
Nell'ultimo lotto avete ordini inviati e risposte del server ricevute in 1 (!!!) ms. E il registro mostra un tempo di elaborazione del server di 10 ms. Incredibile. :)
La domanda sorge spontanea:
Ci si può fidare dei tempi pubblicati nel log del terminale?
Nell'ultimo lotto avete ordini inviati e risposte del server ricevute in 1 (!!!) ms. E il registro mostra un tempo di elaborazione del server di 10 ms. Incredibile. :)
La domanda sorge spontanea:
Ci si può fidare dei tempi pubblicati nel log del terminale?
Questi sono probabilmente esattamente 16ms discreti.
e questi possono essere più accurati
Ecco il vero LMAX di API .NET
L'esecuzione sulle notizie è di 12 ms a 8 ms di ping (misurato usando un timer ad alta frequenza)
Credo che questa sia la linea guida.
Cerchiamo di essere chiari e trasparenti. Parliamo della latenza meno tutti i ping tra i nodi.
Mi è stata mostrata una latenza di ~ 1ms da persone HFT sulla borsa russa. Non sono un tecnico e non so dirvi come ci riescano.
Allo stesso modo su LMAX la latenza è ~ 2-3 ms.
Ancora una volta, stiamo parlando della latenza al dettaglio meno tutti i ping.
L'infrastruttura MT5 si collega direttamente alle borse. Oppure, come hai detto tu, è solo un "tubo". Gli HFT collegano i loro tubi e ottengono il risultato come hai scritto sopra.
Il collegamento di un tubo MT5 comporta un costo di tempo molto più elevato. Quali sono le ragioni?
Non è necessario essere chiari, ma a un livello di conoscenza professionale.
Costruire 1036.
Come lo affronta? La differenza di esecuzione è mostruosa.
È possibile raggiungere la stabilità delle prestazioni sul server?
PS: Come sembra inappropriato pubblicizzare MT come una piattaforma ad alta frequenza. :(
papaklass!
Non c'è bisogno di agitarsi tanto!
Non ti prendi nemmeno la briga di leggere i post!
E scolpire stupidamente i tuoi post!
Non pensi che sia ora di fermarsi?
PERSONE CHE LAVORANO!!!!
Ti dispiacerebbe mostrarmi il messaggio che avrei dovuto leggere?
Per citare Renate:
Il server 1035 di Otkritie è già in funzione oggi.
Ecco come sono cambiati i tempi di attivazione degli ordini dal VPS di Mosca (stesso computer, stessoconto reale):
Come promesso, c'è un miglioramento qualitativo (multiplo) nella velocità di elaborazione degli ordini.
L'occasionale tempo fluttuante della consegna della risposta al terminale non è stato ancora eliminato, continueremo a lavorarci.
-------------------------------------------------------
E perché li considera interni?
1) Guarda in OnTradeTransaction quanti stati intermedi ottieni sull'ordine.
Ogni transazione commerciale non è un pacchetto (richiesta-risposta) ma diverse notifiche. È così che il terminale sa sempre a che punto è la richiesta (per esempio, l'esecuzione può richiedere molto tempo).
Ora stiamo pensando alla possibilità di includere in MQL5 una funzione separata per disabilitare tutte le notifiche di stato intermedie, trasformando lo schema in un semplice modulo. Questo potrebbe accelerare l'esecuzione.
2) Ti manca completamente il secondo lato della comunicazione con lo scambio e la variabilità della velocità di esecuzione. Sembra che tu pensi che ci sia uno 0 conosciuto, ma non c'è garanzia di velocità lì.
Mi sembra che sia circa 10 volte di più di quello che potrebbe essere.
Non c'è bisogno di essere ingannati guardando un pezzo di asberg che sporge sull'acqua.
Lasciatemi chiarire che non abbiamo effettivamente migliorato la velocità di un fattore 2, ma abbiamo guadagnato circa 20-30 ms. Due non è il doppio di uno, ma solo di un fattore uno. Questo è solo un effetto base basso.
Comunque, continuiamo a lavorare e otterremo risultati ancora migliori.