Tiki in tempo reale - pagina 17
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
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.
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!
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.
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.
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.
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.
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.
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...
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.
Cioè, durante l'inizializzazione lo cronometro di un microsecondo,
e prima di ogni stampa, faccio di nuovo il trapano.
Idealmente, dovrebbe essere così
Ma molto spesso risulta così (esposizioni log):
Quindi l'ora locale viene scritta nella stampa quando la stampa viene chiamata.
Ma non va bene con 4 secondi...