Tiki in tempo reale - pagina 17

 
Yuriy Zaytsev:

SEI SICURO DI QUESTO?


4 secondi ???? Non è possibile! Pensi davvero che il processore sia stato congelato per 4 secondi o che la memoria sia stata liberata per 4 secondi? Stai scherzando?

È più probabile che sia la coda di scrittura sul disco.

Il disco è più lento della memoria e del processore.

E poi flush(), c'è un tale comando nel linguaggio C, probabilmente lo sapete, viene eseguito quando è conveniente e comodo e può essere eseguito con qualche ritardo più spesso legato al caricamento del disco.

Questo è quello che viene chiamato quando i buffer devono essere resettati su disco.

Beh, non ne sono così sicuro, dato che non l'ho verificato sperimentalmente in MT. Ma è una specie di standard - perché in un log c'è il tempo di scrittura su disco, se il tempo dell'evento, che ha causato questa scrittura in un log, è più importante, non è logico?

E se assumiamo, che il registro sia scritto su disco in tempo di scrittura, e se il disco è caricato, comunque si avrà un ritardo nella registrazione fisica, e il tempo sarà l'invio di un comando per scrivere nel buffer di scrittura.

cioè il flush non cambia il buffer - semplicemente lo resetta un po' più tardi se c'è un ritardo.

wp. ha giustamente notato che è necessario scrivere l'ora, perché in ogni caso, solo il tempo è formato dal terminale stesso quando si scrive nel log, non ha senso orientarsi.

 
Aleksey Mavrin:

Beh, non ne sono così sicuro, perché non l'ho verificato sperimentalmente in MT. Ma è una specie di standard - perché nel log il tempo di registrazione su disco, se è più importante il tempo dell'evento, che ha causato questa registrazione nel log, logicamente?

E se assumiamo, che il registro sia scritto su disco in tempo di scrittura, e se il disco è caricato, comunque si avrà un ritardo nella registrazione fisica, e il tempo sarà l'invio di un comando per scrivere nel buffer di scrittura.

cioè il flush non cambia il buffer - semplicemente lo resetta un po' più tardi se c'è un ritardo.

s.s. giustamente notato che necessità di scrivere e tempo, perché in ogni caso, solo il tempo che il terminale stesso genera quando si scrive al log, guidato nessun senso.


Ho supposto - che il tempo sia inserito appena prima di scrivere sul disco, poi tutto si adatta.

cerchiamo di descrivere lo scenario passo dopo passo - per renderlo più chiaro


1-The tick came (hit onTick) - dovrebbe essere stampato

2-E OnTick stampa un log - è stato salvato con successo

3-Questo tick arriva anche a OnTick - dovrebbe anche essere stampato.

4-Ecco che arriva l'incubo: Windows improvvisamente vomita 20 flussi di dati sul disco da vari programmi in questo momento e blocca temporaneamente il disco.

Il driver ha messo la sua testa magnetica di dati da qualche altra parte -) e sta scrivendo i propri dati.

5-Questo è quando il metatrader cerca di inviare qualcosa al DISK

Ma il disco è terribilmente occupato con il sistema operativo Windows - Il sistema operativo sta dicendo al metatrader sorry MQ che ho cose più importanti da fare - aspetta

6- Passano 4 secondi.

7- e poi Windows dopo 4 secondi - ha cancellato la coda al disco - e dice alla MetaTrader - Caro terminale di trading - vuoi scrivere qualcosa sul disco? - ok scrivilo!

8-metatrader scrive su disco con un ritardo di 4 secondi e registra il TEMPO nel registro, non quando voleva scrivere i dati su disco - ma quando l'ha effettivamente fatto.

Ecco da dove vengono i 4 secondi.



---

Qualsiasi altro scenario, come il terminale ha messo l'ora locale nel buffer - ma la scrittura è stata ritardata di 4 secondi - NON FUNZIONA un tale scenario

altrimenti il tempo avrebbe coinciso!

 
Aleksey Mavrin:

Beh, non ne sono così sicuro, perché non l'ho verificato sperimentalmente in MT. Ma è una specie di standard - perché nel log il tempo di registrazione su disco, se è più importante il tempo dell'evento, che ha causato questa registrazione nel log, è logico, giusto?

E se assumiamo, che il registro sia scritto su disco in tempo di scrittura, e se il disco è caricato, comunque si avrà un ritardo nella registrazione fisica, e il tempo sarà l'invio di un comando per scrivere nel buffer di scrittura.

cioè il flush non cambia il buffer - semplicemente lo resetta un po' più tardi se c'è un ritardo.

s.s. ha giustamente notato che si deve scrivere il tempo, perché in ogni caso, solo il tempo che il terminale stesso genera quando scrive nel log, non ha senso concentrarsi su.

E se non controlli, allora non dire stronzate.

Sai almeno di cosa stiamo parlando in questo thread?

Mostrami il test o vattene da qui.

 
Aleksey Mavrin:

Beh, non ne sono così sicuro, perché non l'ho verificato sperimentalmente in MT. Ma è una specie di standard - perché nel log il tempo di registrazione su disco, se è più importante il tempo dell'evento, che ha causato questa registrazione nel log, logicamente?

E se assumiamo, che il registro sia scritto su disco in tempo di scrittura, e se il disco è caricato, comunque si avrà un ritardo nella registrazione fisica, e il tempo sarà l'invio di un comando per scrivere nel buffer di scrittura.

cioè il flush non cambia il buffer - semplicemente lo resetta un po' più tardi se c'è un ritardo.

s.s. ha giustamente notato che è necessario scrivere il tempo, perché in ogni caso, solo il tempo che forma il terminale stesso quando si scrive al log, guidato da nessun senso.

Solo nel nostro caso abbiamo il tempo di scrivere su disco!

Ma il tempo può essere sistemato nella procedura GetTickDescription, ne ho scritto all'autore sopra.

E se l'avesse messo lì, non avremmo discusso la possibile causa del ritardo in 4 secondi. Nel registro molto probabilmente l'ora locale sarebbe arrivata ugualmente per OnBock e OnTick, ma il tempo su disco sarebbe stato diverso di 4 secondi.

//+------------------------------------------------------------------+ 
//| возвращает строковое описание тика                               | 
//+------------------------------------------------------------------+ 
string GetTickDescription(MqlTick &tick)
{
..
..
Sergey Chalyshev:

E se non l'avete controllato, allora non ve ne frega niente.

Hai idea di cosa sia questo thread?

Mostrami il test o vattene da qui.

Non essere così duro con me.

 

È possibile migliorare questo tick-catching, impostarlo per una settimana o due, e forse catturare il momento in cui la data di registrazione nel registro si diffonde con la data dell'evento.

Naturalmente, è possibile accelerare questo processo caricando periodicamente un disco per la registrazione.

Un'altra domanda, la più importante. Perché perdere tempo in questa ricerca :-))) qual è il beneficio pratico.

---

Per il momento è chiaro che i tick prima vengono in OnTick e solo dopo vengono in OnBuk, quello che è bello è che OnBuk viene chiamato non solo con i tick ma per esempio con i cambiamenti dei volumi a mercato, in altre parole qualcuno ha aperto un ordine, lo ha chiuso o cancellato, i volumi sono cambiati.

E naturalmente seguendo la logica delle decisioni di trading nel mercato delle azioni / futures logico prendere esattamente in OnBuk, e non in OnTick.

 
Sergey Chalyshev:

E se non avete controllato, allora non ve ne frega niente.

Hai idea di cosa sia questo thread?

Mostrami il test o vattene da qui.

Sei tu che blateri, cazzone, 16 pagine non hanno pensato di cronometrare l'evento prima della Stampa e scrivere la velocità che misurano, esperti, dannazione).

Quello che mi hai fatto notare con tanto orgoglio, dicono, non ho controllato, non hai nemmeno capito bene di cosa sto parlando, scommetto. Ma è improbabile che lei lo capisca.

E il fatto che questo tempo non sia esattamente il tempo di registrazione su disco, è controllato.

 
Sergey Chalyshev:

E se non avete controllato, allora non ve ne frega niente.

Hai idea di cosa sia questo thread?

Mostrami il test o vattene da qui.

Che ne dici di questo, intelligentone, mostrami almeno un modo credibile per testare quello che stai ottenendo, e io me ne vado e ammetto che non capisco, altrimenti ammetti che non capisci tu stesso, scusati, o vattene.

Vale a dire - almeno un modo affidabile al 100% per verificare sperimentalmente esattamente a che ora il terminale scrive nel log, cioè le opzioni principali:

1. il tempo in cui il terminale riceve il comando di stampa nella coda.

2. ora di inizio del comando di stampa.

3. ora di fine della stampa nel buffer).

Questa variante può essere l'ora esatta:

4. tempo di esecuzione della stampa su disco.

 
Aleksey Mavrin:

Che ne dici di questo, intelligentone, tu mi mostri almeno un modo affidabile per verificare dove vuoi arrivare, e io me la svigno e ammetto che non ho capito, altrimenti ammetti che non capisci tu stesso, chiedi scusa, o te la svigno.

Vale a dire - almeno un modo affidabile al 100% per verificare sperimentalmente esattamente a che ora il terminale scrive nel log, cioè le opzioni principali:

1. il tempo in cui il terminale riceve il comando di stampa nella coda.

2. ora di inizio del comando di stampa.

3. ora di fine della stampa nel buffer).

Questa variante può essere l'ora esatta:

4. il tempo di esecuzione della stampa su disco.

Allora, qual è il punto?

Aspettando il tuo codice...

 
prostotrader:

Quindi qual è il problema?

Aspettando il tuo codice...

Che codice state aspettando? Ti ho promesso qualcosa? Qual era il prezzo?).

p/s/ anche tu non hai capito, come il tuo amico, di cosa sto parlando.
 

Mentre il dibattito è in corso, ho fatto un altro esperimento.

//+------------------------------------------------------------------+
//|                                                   Ticks_test.mq5 |
//|                                      Copyright 2019 prostotrader |
//|                                             https://www.mql5.com |
//+------------------------------------------------------------------+
#property copyright "Copyright 2019 prostotrader"
#property link      "https://www.mql5.com"
#property version   "1.00"
//---
bool is_book;
ulong st_time, func_time;
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
{
  is_book = MarketBookAdd(Symbol());
  st_time = GetMicrosecondCount();
  func_time = GetMicrosecondCount();
  Print(__FUNCTION__, "; Time: ", MathAbs((func_time - st_time)/1000), " ms");
  return(INIT_SUCCEEDED);
}
//+------------------------------------------------------------------+
//| Expert deinitialization function                                 |
//+------------------------------------------------------------------+
void OnDeinit(const int reason)
{
  if(is_book == true) MarketBookRelease(Symbol());
}
//+------------------------------------------------------------------+
//| BookEvent function                                               |
//+------------------------------------------------------------------+
void OnBookEvent(const string &symbol)
{
  if(Symbol() == symbol)
  {
    func_time = GetMicrosecondCount();
    Print(__FUNCTION__, "; Time: ", MathAbs((func_time - st_time)/1000), " ms");
  }
}
void OnTick()
{
  func_time = GetMicrosecondCount();
  Print(__FUNCTION__, "; Time: ", MathAbs((func_time - st_time)/1000), " ms");
}
//+------------------------------------------------------------------+

Cioè, durante l'inizializzazione lo cronometro di un microsecondo,

e prima di ogni stampa, faccio di nuovo il trapano.

Idealmente, dovrebbe essere così

2020.02.04 21:28:01.316	Ticks_test_2 (GOLD-3.20,M1)	OnTick; Time: 1395 ms
2020.02.04 21:28:01.316	Ticks_test_2 (GOLD-3.20,M1)	OnBookEvent; Time: 1395 ms

Ma molto spesso risulta così (esposizioni log):

2020.02.04 21:28:11.133 Ticks_test_2 (GOLD-3.20,M1)     OnTick; Time: 11212 ms
2020.02.04 21:28:11.139 Ticks_test_2 (GOLD-3.20,M1)     OnBookEvent; Time: 11218 ms

2020.02.04 21:28:15.603 Ticks_test_2 (GOLD-3.20,M1)     OnTick; Time: 15682 ms
2020.02.04 21:28:15.609 Ticks_test_2 (GOLD-3.20,M1)     OnBookEvent; Time: 15688 ms

2020.02.04 21:28:29.521 Ticks_test_2 (GOLD-3.20,M1)     OnTick; Time: 29599 ms
2020.02.04 21:28:29.790 Ticks_test_2 (GOLD-3.20,M1)     OnTick; Time: 29868 ms
2020.02.04 21:28:29.790 Ticks_test_2 (GOLD-3.20,M1)     OnBookEvent; Time: 29868 ms

2020.02.04 21:28:33.109 Ticks_test_2 (GOLD-3.20,M1)     OnTick; Time: 33188 ms
2020.02.04 21:28:33.115 Ticks_test_2 (GOLD-3.20,M1)     OnBookEvent; Time: 33194 ms

2020.02.04 21:28:40.800 Ticks_test_2 (GOLD-3.20,M1)     OnTick; Time: 40878 ms
2020.02.04 21:28:40.807 Ticks_test_2 (GOLD-3.20,M1)     OnBookEvent; Time: 40885 ms

2020.02.04 21:28:41.891 Ticks_test_2 (GOLD-3.20,M1)     OnTick; Time: 41969 ms
2020.02.04 21:28:41.896 Ticks_test_2 (GOLD-3.20,M1)     OnBookEvent; Time: 41974 ms

2020.02.04 21:28:52.984 Ticks_test_2 (GOLD-3.20,M1)     OnTick; Time: 53063 ms
2020.02.04 21:28:52.991 Ticks_test_2 (GOLD-3.20,M1)     OnBookEvent; Time: 53070 ms

2020.02.04 21:28:54.457 Ticks_test_2 (GOLD-3.20,M1)     OnTick; Time: 54536 ms
2020.02.04 21:28:55.276 Ticks_test_2 (GOLD-3.20,M1)     OnBookEvent; Time: 55355 ms

2020.02.04 21:29:10.643 Ticks_test_2 (GOLD-3.20,M1)     OnTick; Time: 70722 ms
2020.02.04 21:29:10.650 Ticks_test_2 (GOLD-3.20,M1)     OnBookEvent; Time: 70729 ms

2020.02.04 21:29:14.674 Ticks_test_2 (GOLD-3.20,M1)     OnTick; Time: 74752 ms
2020.02.04 21:29:14.681 Ticks_test_2 (GOLD-3.20,M1)     OnBookEvent; Time: 74759 ms

2020.02.04 21:29:25.306 Ticks_test_2 (GOLD-3.20,M1)     OnTick; Time: 85384 ms
2020.02.04 21:29:25.313 Ticks_test_2 (GOLD-3.20,M1)     OnBookEvent; Time: 85390 ms

2020.02.04 21:29:30.468 Ticks_test_2 (GOLD-3.20,M1)     OnTick; Time: 90546 ms
2020.02.04 21:29:30.481 Ticks_test_2 (GOLD-3.20,M1)     OnBookEvent; Time: 90559 ms

2020.02.04 21:29:30.866 Ticks_test_2 (GOLD-3.20,M1)     OnTick; Time: 90944 ms
2020.02.04 21:29:30.874 Ticks_test_2 (GOLD-3.20,M1)     OnBookEvent; Time: 90951 ms

2020.02.04 21:29:36.680 Ticks_test_2 (GOLD-3.20,M1)     OnTick; Time: 96758 ms
2020.02.04 21:29:36.688 Ticks_test_2 (GOLD-3.20,M1)     OnBookEvent; Time: 96766 ms

2020.02.04 21:29:37.891 Ticks_test_2 (GOLD-3.20,M1)     OnTick; Time: 97968 ms
2020.02.04 21:29:37.910 Ticks_test_2 (GOLD-3.20,M1)     OnBookEvent; Time: 97987 ms

Quindi l'ora locale viene scritta nella stampa quando la stampa viene chiamata.

Ma non va bene con 4 secondi...