MT5 e la velocità in azione - pagina 45

Nuovo commento
 
Andrey Khatimlianskii:

No, ho dei virtualizzatori che girano su CentOS. Ma non sono competente per continuare questo dialogo.

Si tratta comunque di una doppia virtualizzazione.

CentOS -> VirtualBox -> Windows 7


Anche la riduzione a 2 core quando la CPU è a 8, cambia drasticamente il comportamento e le risorse allocate del threadsheduler.

Questi 2 core dovranno essere assegnati agli inevitabili 1000 threads anche con Windows 7 troncato. Quindi il terminale è garantito per avere un aumento della latenza.

 
Renat Fatkhullin:

Beh, lei è un maestro di stress test di corsa senza controllare la correlazione e la ragionevolezza.

Naturalmente la misurazione al microsecondo richiede risorse per poter misurare intervalli di 1000 volte inferiori al millisecondo.

Se occasionalmente avete bisogno di misurare intervalli in modo super accurato, allora usate i microsecondi. E vi costerà 0 microsecondi.

Come si fa a usare i microsecondi quando sono quelli che ti rallentano? Ecco un totale di 20 chiamate. Un quarto di millisecondo su un numero così ridicolo di chiamate per vari compiti pratici.

2020.10.06 00:50:44.491 Alert: Time[Test6.mq5 15: for(inti=0;i<20;i++)GetMicrosecondCount();] = 254 mсs.
2020.10.06 00:50:44.491 Alert: Time[Test6.mq5 20: for(inti=0;i<20;i++)GetTickCount();] = 19 mсs.

Su un VPS soffocato, l'overclock del timer di sistema tramite timeBeginPeriod è pieno di pericoli. Aumenterete semplicemente l'overhead della CPU:

Altrimenti, avreste già da tempo reso GetTickCount/GetTickCount64 preciso nel sistema operativo e vi sareste rallegrati della precisione gratuita. Ma no, dovrete pagare per la precisione di questo timer.


GetTickCount non è in alcun modo inferiore in velocità. Sono passato ad usarlo su un VPS lento invece di GetMicrosecondsCount. Il carico è sceso dal 50% al 2% su uno scambio reale.

2020.10.06 00:50:44.491 Alert: Time[Test6.mq5 26: for(inti=0;i<20;i++)winmm::timeGetTime();] = 13 mсs.
 
fxsaber:

Come si fa a usare i microsecondi quando sono loro a rallentare?! Qui ci sono solo 20 chiamate. Un quarto di millisecondo su un numero così ridicolo di chiamate per vari compiti pratici.

E ho queste 20 chiamate:

   ulong ticks=GetMicrosecondCount();
   for(int i=0; i<20; i++)
      GetMicrosecondCount();
   Print("GetMicrosecondCount: ",GetMicrosecondCount()-ticks);

   ticks=GetMicrosecondCount();
   for(int i=0; i<20; i++)
      GetTickCount();
   Print("GetTickCount: ",GetMicrosecondCount()-ticks);


2020.10.06 01:04:44.068 5555 (CAT.NYSE,M5)      GetMicrosecondCount: 1
2020.10.06 01:04:44.068 5555 (CAT.NYSE,M5)      GetTickCount: 0


GetTickCount non è in alcun modo inferiore in velocità. Sono passato ad usarlo su un VPS lento invece di GetMicrosecondsCount. Il carico è sceso dal 50% al 2% su uno scambio reale.

Non credo che la sostituzione di GetMicrosecondsCount -> GetTickCount darà in un programma reale. Sia teoricamente che praticamente non ci sono prove.

In uno stress test su queste due funzioni, si può facilmente trarre un tale risultato. State concludendo voi stessi che il 48% del carico della CPU è stato misurato in microsecondi? E questo non è uno stress test? Certo che lo è.


Riguardo all'accelerazione del timer multimediale - si tratta di nuovo di stress test senza guardare alla degradazione complessiva delle prestazioni. L'overclocking del task shuffler aumenta l'overhead del sistema operativo.

 
Renat Fatkhullin:

Ancora doppia virtualizzazione.

CentOS -> VirtualBox -> Windows 7


Anche la riduzione a 2 core quando la CPU è a 8, cambia drasticamente il comportamento e le risorse allocate del threadsheduler.

Questi 2 core dovranno essere assegnati agli inevitabili 1000 threads anche con Windows 7 troncato. Quindi il terminale è garantito per avere un aumento della latenza.

Sono arrivato anch'io a questa conclusione, grazie per la conferma.VirtualBox è il male.
E soprattutto fate attenzione ai vps, su una tale implementazione, ce ne sono un sacco.
Solo sistema operativo puro su hardware, e preferibilmente Linux.
Anche se attraverso wine, stessa virtualizzazione, ma la GUI del terminale vola senza un solo ritardo.
E GetMicrosecondsCount gira senza alcun ritardo.

 
Renat Fatkhullin:

E ho queste 20 chiamate:

Beh, anche per me sono zero microsecondi! Solo sulla mia macchina di casa.

Non credo che la sostituzione di GetMicrosecondsCount -> GetTickCount possa funzionare in un programma reale. Sia teoricamente che praticamente non ci sono prove.

Nello stress test, potete facilmente disegnare tali errori usando queste due funzioni. State concludendo voi stessi che il 48% del carico della CPU è stato misurato in microsecondi? E questo non è uno stress test? Certo che lo è.

Questo thread mi ha spinto a scrivere una libreria Benchmark in modo da poter semplicemente inserire un controllo di runtime nel sorgente. E ne ha approfittato abbastanza ampiamente, rivelando ed eliminando un sacco di cose brutte.

Quindi, gli Expert Advisor scritti con tale modifica (più precisamente 20 EAs in parallelo) influenzano il computer di casa del 1,5%. Ma il VPS è 50+%. Quando ho iniziato a scavare, ho visto che il timer dei microsecondi sta rallentando. Corrispondentemente, dove non sono stati generati avvisi sulle macchine domestiche, il VPS fallisce.


Ma anche questo non è stato sufficiente. Grazie a questo ramo, è stato sviluppato un meccanismo di scatto, la cui base è questa.

  ulong Snapshot( const uint &RefreshTime, const MAGIC_TYPE &Magic, bool HistoryInit = false )
  {
    if (SNAPSHOT::SnapshotLifeTime() < RefreshTime)
      return(0);
// ....

  ulong SnapshotLifeTime( void ) const
  {
    static const bool IsTester = ::MQLInfoInteger(MQL_TESTER);

    return(IsTester ? ULONG_MAX : (::GetMicrosecondCount() - this.TimeData)); // Обязуем любой вызов снепшота в Тестере делать полноценным.
  }

Questa è la base di tutte le istantanee: se è passato meno del tempo specificato dall'ultima istantanea, non facciamo nulla. È questo approccio che permette di risparmiare significativamente sulle risorse.

Naturalmente, il tempo di aggiornamento è breve - di default è di un millisecondo. Questo è il motivo per cui viene utilizzato un timer a microsecondi.


La lentezza di questo timer ha causato il collasso del meccanismo di snapshot, in quanto ha preso uno snapshot completo un ordine/due volte più spesso che su una macchina completa.


Questo è il tipo di torta dei freni a microsecondi. Ma quando sono passato al timer al millisecondo (invece di 16ms), tutto ha iniziato a volare, anche su VPS lenti.

Riguardo all'accelerazione del timer multimediale - si tratta di nuovo di stress test senza considerare la degradazione complessiva delle prestazioni. L'overclock del taskmaster aumenta l'overhead del sistema operativo.

Chi se ne frega di queste teorie quando in pratica i guadagni sono colossali. Forse, influisce su alcuni giochi. Ma sul VPS è stato un risparmio.

 
fxsaber:

Beh, sono zero microsecondi anche per me! Solo sulla mia macchina di casa.

Questo thread mi ha spinto a scrivere una libreria Benchmark in modo da poter semplicemente inserire un controllo di runtime nel sorgente. E ne ha approfittato abbastanza ampiamente, rivelando ed eliminando un sacco di cose brutte.

Quindi, gli Expert Advisor scritti con tale modifica (più precisamente 20 EAs in parallelo) influenzano il computer di casa del 1,5%. Ma il VPS è 50+%. Quando ho iniziato a scavare, ho visto che il timer dei microsecondi sta rallentando. Corrispondentemente, dove non sono stati generati avvisi sulle macchine domestiche, il VPS fallisce.


Ma anche questo non è stato sufficiente. Grazie a questo ramo, è stato sviluppato un meccanismo di scatto, la cui base è questa.

Questa è la base di tutte le istantanee: se è passato meno del tempo specificato dall'ultima istantanea, non facciamo nulla. È questo approccio che permette di risparmiare significativamente sulle risorse.

Naturalmente, il tempo di aggiornamento è breve - di default è di un millisecondo. Questo è il motivo per cui viene utilizzato un timer a microsecondi.


Quindi, a causa della lentezza di questo timer il meccanismo di snapshot si è bloccato perché lo snapshot completo è stato preso molto più spesso che su una macchina completa.


Questo è il tipo di torta dei freni a microsecondi. Ma quando sono passato al timer al millisecondo (invece di 16ms), tutto ha iniziato a volare, anche su VPS lenti.

Non mi importa di queste teorie, purché i benefici pratici siano enormi. Forse influisce su alcuni giochi. Ma sul VPS è stato un risparmio.

Guardate come è stato detto in modo meraviglioso:

Sono passato ad usarlo su un VPS lento invece di GetMicrosecondsCount. Il carico è sceso dal 50% al 2% sul commercio reale.

La conclusione era inevitabile "tutto a causa dei microsecondi di misurazione dei freni, ecco cos'è l'accelerazione".

E improvvisamente si scopre che "io stesso ho fatto dei calcoli di un ordine di grandezza maggiore a causa di un errore logico". E GetMicrosecondsCount era solo un trigger per questo errore.

La rielaborazione di GetTickCount è un fix/crack per questo errore e il codice del fix non è stato mostrato. Perché non è solo la sostituzione di GetMicrosecondsCount -> GetTickCount?

Perché non poteva essere detto subito?


La logica sembra essere stata accelerata dall'apparente bootstrapping della contabilità (saltando da microsecondi a millisecondi) e dalla riduzione multipla della creazione di snapshot.
 
Sto ancora pensando se fotografare SymbolInfoTick per evitarlo. 
2020.10.05 12:52:35.963         Alert: Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: ::SymbolInfoTick(_Symbol,Tick)] = 599 mсs.
2020.10.05 12:52:45.904         Alert: Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: ::SymbolInfoTick(_Symbol,Tick)] = 245 mсs.
2020.10.05 12:52:45.904         Alert: Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: ::SymbolInfoTick(_Symbol,Tick)] = 470 mсs.
2020.10.05 12:52:45.904         Alert: Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: ::SymbolInfoTick(_Symbol,Tick)] = 722 mсs.
2020.10.05 12:52:45.904         Alert: Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: ::SymbolInfoTick(_Symbol,Tick)] = 901 mсs.
2020.10.05 12:52:45.905         Alert: Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: ::SymbolInfoTick(_Symbol,Tick)] = 1726 mсs.
2020.10.05 12:53:00.123         Alert: Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: ::SymbolInfoTick(_Symbol,Tick)] = 864 mсs.
2020.10.05 12:53:03.218         Alert: Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: ::SymbolInfoTick(_Symbol,Tick)] = 112 mсs.
2020.10.05 12:53:04.493         Alert: Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: ::SymbolInfoTick(_Symbol,Tick)] = 2134 mсs.
2020.10.05 12:53:10.013         Alert: Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: ::SymbolInfoTick(_Symbol,Tick)] = 1826 mсs.
2020.10.05 12:53:13.119         Alert: Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: ::SymbolInfoTick(_Symbol,Tick)] = 114 mсs.
2020.10.05 12:53:18.008         Alert: Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: ::SymbolInfoTick(_Symbol,Tick)] = 116 mсs.
2020.10.05 12:53:20.010         Alert: Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: ::SymbolInfoTick(_Symbol,Tick)] = 1095 mсs.
2020.10.05 12:55:55.033         Alert: Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: ::SymbolInfoTick(_Symbol,Tick)] = 359 mсs.

Questo su una macchina che macina 20 EAs con 1,5% di CPU. Che LatencyMon mostra che tutto è a posto.

Qualcosa nell'architettura di MT5 sta dando questi ritardi a tutti gli EA in esecuzione allo stesso tempo. E nessuno per me.

 
Renat Fatkhullin:

La conversione in GetTickCount è una correzione/crack per questo bug, e il codice di correzione non è stato mostrato. Perché non è solo la sostituzione di GetMicrosecondsCount -> GetTickCount?

Perché non poteva essere detto subito?

Le discussioni con me, però, si distinguono per la presenza di ciò che viene mostrato. Nulla è nascosto, al contrario è pubblicato apertamente.

C'è certamente un test di stress. Non c'era altro modo per mostrarlo visivamente.


Immaginate una funzione a forma di matrioska. Viene presa una misura della matrioska esterna. Allo stesso tempo, si prendono le misure anche delle bambole di nidificazione interne. Di conseguenza, a causa della frenata di microsecondi, le bambole esterne annidate mostrano cifre selvagge sui loro tempi di esecuzione, il che provoca una raffica di avvisi di un tipo. Ovviamente, 10 microsecondi per una chiamata a GetMicrosecondsCount è terribilmente costoso. Così ho affrettato gli avvisi.


Il timer libero di millisecondi ha iniziato a dare 0µs, 1000µs o 2000µs. Questo ha ridotto notevolmente il numero di avvisi e ha ridotto la frenata sulle chiamate di funzioni del timer.


A giudicare dalla logica, l'accelerazione è stata ottenuta con un bootstrapping esplicito della contabilità (saltando da microsecondi a millisecondi) e riducendo la creazione di istantanee di un multiplo.


E con le istantanee è fantastico. Il loadout, rispetto alla macchina di casa (microsecondi lì), non è grande. Ma se lo si confronta con quello che c'era sul VPS, è come il cielo e la terra.


SZZ ora stiamo parlando della fattibilità di avere in MQL timer millisecondi, che, purtroppo, non esiste. Non è possibile fare snapshot su VPS senza di esso.

 
fxsaber:
Sto ancora considerando lo snapshot SymbolInfoTick per evitare questo tipo di cose.

Questo su una macchina che macina 20 EAs all'1,5% di CPU. Che LatencyMon mostra che tutto è a posto.

Qualcosa nell'architettura di MT5 sta dando questi ritardi a tutti gli EA in esecuzione allo stesso tempo. E nessuno per me.

Ecco il mio codice e il tempo di risposta stabile: non centinaia o migliaia di microsecondi su 20 grafici in parallelo

   MqlTick Tick;
   ulong   ticks=GetMicrosecondCount();
   
   SymbolInfoTick(_Symbol,Tick);
   Print("SymbolInfoTick: ",GetMicrosecondCount()-ticks);


2020.10.06 02:14:18.234	5555 (CADJPY,H1)	SymbolInfoTick: 2
2020.10.06 02:14:18.765	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:19.063	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:19.180	5555 (CADJPY,H1)	SymbolInfoTick: 2
2020.10.06 02:14:19.180	5555 (EURCAD,H1)	SymbolInfoTick: 1
2020.10.06 02:14:19.245	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:19.523	5555 (CHFJPY,H1)	SymbolInfoTick: 1
2020.10.06 02:14:19.659	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:20.037	5555 (CADCHF,H1)	SymbolInfoTick: 2
2020.10.06 02:14:20.037	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:20.137	5555 (EURMXN,H1)	SymbolInfoTick: 2
2020.10.06 02:14:20.138	5555 (EURNOK,H1)	SymbolInfoTick: 2
2020.10.06 02:14:20.226	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:20.227	5555 (CHFJPY,H1)	SymbolInfoTick: 2
2020.10.06 02:14:20.525	5555 (AUDNZD,H1)	SymbolInfoTick: 1
2020.10.06 02:14:20.645	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:20.919	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:21.123	5555 (EURNZD,H1)	SymbolInfoTick: 1
2020.10.06 02:14:21.129	5555 (EURAUD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:21.234	5555 (EURNOK,H1)	SymbolInfoTick: 1
2020.10.06 02:14:21.441	5555 (EURAUD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:22.299	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:22.383	5555 (AUDNZD,H1)	SymbolInfoTick: 2

Quanti core hai e che tipo di processore? i7-2600?

Un altro stress test nascosto con milioni di richieste in parallelo?


Essere più trasparente. Solo perché hai postato un paio di semplici chiamate _B non è una prova delle tue altre affermazioni. Lei dimentica bruscamente il codice e la descrizione reale delle condizioni non appena fa delle affermazioni stravaganti.

Non avete bisogno di immaginare nulla nella vostra mente - raccontate e mostrate ciò che effettivamente chiamate e testate. Non un risultato strappato di "eseguito uno stress test sconosciuto e in attesa di un avviso per mostrare il mondo", ma esattamente il codice completo del test.

Ci sono anche domande sulla biblioteca di misura stessa. C'è un sacco di roba inutile, comprese le spese generali.

 
fxsaber:

Ora stiamo parlando dell'utilità di avere un timer di millisecondi in MQL, che purtroppo non esiste. Non si può scattare su UPU senza di esso.

C'è un timer di millisecondi molto tempo fa: EventSetMillisecondTimer()

Документация по MQL5: Работа с событиями / EventSetMillisecondTimer
Документация по MQL5: Работа с событиями / EventSetMillisecondTimer
  • www.mql5.com
Указывает клиентскому терминалу, что для данного эксперта или индикатора необходимо генерировать события таймера с периодичностью менее одной секунды. нужно получать события таймера чаще, чем один раз в секунду. Если вам достаточно обычного таймера с периодом более 1 секунды, то используйте EventSetTimer(). В тестере стратегий используется...
1...383940414243444546474849505152...94
Nuovo commento