No entiendo muy bien por qué es imposible sortear estos lapsos de carga de la CPU. Probablemente sea incompetente para hacerlo.
Sin embargo, a continuación hay una prueba limpia que muestra el problema de la relevancia de los datos de precios en MT5. He proporcionado el código con comentarios. Brevemente, los ticks se toman a través de SymbolInfoTick/stack y se comprueban entre sí. En particular, para evitar lagunas y grandes desfases entre ticks idénticos de diferentes fuentes.
// Демонстрация лагов OnTick и OnBookEvent.inputuint inMinInterval = 1000; // Минимальное время (в мкс.) лага// Структура тика, которую удобно будет выводить в ArrayPrint.struct PRICE
{
double bid;
double ask;
bool onTick; // true - источник OnTick+SymbolInfoTick, false - источник OnBookEvent+MarketBookGetulong Interval; // Временной интервал между соседними записями.void Set( constdouble &dBid, constdouble &dAsk, constbool bTick )
{
staticulong PrevTime = ::GetMicrosecondCount();
constulong NewTime = ::GetMicrosecondCount();
this.bid = dBid;
this.ask = dAsk;
this.onTick = bTick;
this.Interval = NewTime - PrevTime;
PrevTime = NewTime;
}
// Записи одинаковые, если обе соответствующие цены совпадают.booloperator ==( const PRICE &Price ) const
{
return((this.bid == Price.bid) && (this.ask == Price.ask));
}
};
PRICE Prices[1000]; // Массив для записи тиков из разных источников.int Amount = 0; // Количество записанных тиков// Возвращает bid/ask-цены из стакана.bool GetCurrentPrices( double &bid, double &ask )
{
MqlBookInfo Bands[];
constbool Res = MarketBookGet(_Symbol, Bands);
if (Res)
for (int i = ArraySize(Bands) - 2; i >= 0; i--)
if (Bands[i].type == BOOK_TYPE_SELL)
{
ask = Bands[i].price;
bid = Bands[i + 1].price;
break;
}
return(Res);
}
// Если bid или ask стакана поменялся - записываем их.bool SaveNewTick_Book()
{
staticdouble PrevBid = 0;
staticdouble PrevAsk = 0;
double bid;
double ask;
constbool Res = !IsStopped() && GetCurrentPrices(bid, ask) && ((PrevBid != bid) || (PrevAsk != ask));
if (Res)
{
PrevBid = bid;
PrevAsk = ask;
Prices[Amount++].Set(bid, ask, false);
if (Amount == ArraySize(Prices)) // Если достигли конца массива - выходим.ExpertRemove();
}
return(Res);
}
// Записываем bid и askbool SaveNewTick_Tick()
{
MqlTick Tick;
constbool Res = !IsStopped() && SymbolInfoTick(_Symbol, Tick);
if (Res)
{
Prices[Amount++].Set(Tick.bid, Tick.ask, true);
if (Amount == ArraySize(Prices)) // Если достигли конца массива - выходим.ExpertRemove();
}
return(Res);
}
// Проверка на наличие багов и задержек.void Check()
{
if (Amount > 3)
{
if ((Prices[Amount - 1].onTick == Prices[Amount - 2].onTick) && // Три подряд записи из одного источника - баг.
(Prices[Amount - 2].onTick == Prices[Amount - 3].onTick))
Alert("BUG!");
elseif ((Prices[Amount - 1] == Prices[Amount - 2]) && // Если цены подряд идущих записей совпадают
(Prices[Amount - 1].Interval > inMinInterval)) // И временной интервал между ними большой - информируем.
{
Alert((Prices[Amount - 1].onTick ? "OnTick-lag! - " : "OnBook-lag! - ") + (string)Prices[Amount - 1].Interval + " mcs.");
ArrayPrint(Prices, _Digits, NULL, Amount - 4, 4); // Выводим подробно проблему.
}
}
}
intOnInit()
{
return(!MarketBookAdd(_Symbol)); // Подписались на стакан.
}
voidOnBookEvent( conststring &Symb )
{
if ((Symb == _Symbol) && SaveNewTick_Book()) // Если записали новые цены из стакана,
Check(); // проверяем.
}
voidOnTick()
{
if (SaveNewTick_Tick()) // Если записали цены тика,
Check(); // проверяем.
}
voidOnDeinit( constint )
{
MarketBookRelease(_Symbol); // Отписались от стакана.ArrayPrint(Prices, _Digits, NULL, 0, Amount); // Вывод всех записей.
}
Resultado (sólo un MT5-b2656 funcionando en la máquina, carga de CPU alrededor de cero, un gráfico, Tester no utilizado).
2020.10.2012:26:19.680 Test9 (AUDCAD,H1) Alert: OnTick-lag! - 9573 mcs.
2020.10.2012:26:19.680 Test9 (AUDCAD,H1) [bid] [ask] [onTick] [Interval]
2020.10.2012:26:19.680 Test9 (AUDCAD,H1) [0] 0.927770.92780true764782020.10.2012:26:19.680 Test9 (AUDCAD,H1) [1] 0.927770.92780false642020.10.2012:26:19.680 Test9 (AUDCAD,H1) [2] 0.927770.92781false505522020.10.2012:26:19.680 Test9 (AUDCAD,H1) [3] 0.927770.92781true9573// В OnTick пришел тик на 9 мс позже, чем он был в стакане.
...
2020.10.2012:26:33.899 Test9 (AUDCAD,H1) Alert: OnBook-lag! - 22153 mcs.
2020.10.2012:26:33.899 Test9 (AUDCAD,H1) [bid] [ask] [onTick] [Interval]
2020.10.2012:26:33.899 Test9 (AUDCAD,H1) [0] 0.927760.92783true3584032020.10.2012:26:33.899 Test9 (AUDCAD,H1) [1] 0.927760.92783false23612020.10.2012:26:33.899 Test9 (AUDCAD,H1) [2] 0.927760.92784true22155062020.10.2012:26:33.899 Test9 (AUDCAD,H1) [3] 0.927760.92784false22153// В стакан пришел тик на 22 мс позже, чем он был в OnTick.
Los frenos de SymbolInfoTick están cerrados. El resultado es el siguiente.
Si la CPU está sobrecargada (como Optimize ni siquiera en todos los núcleos), SymbolInfoTick puede tardar hasta decenas de milisegundos en completarse. No hay respuesta a por qué esta función más popular en el Terminal no se instantánea con regularidad. Si es posible, haz fotos de la misma. Y no hay que olvidar que incluso con carga cero de la CPU la función OnTick puede trabajar decenas de milisegundos más tarde que un tick que llega a la Terminal.
En definitiva, bastante triste, pero no puede preocupar a los que comercian primitivamente.
Los frenos de SymbolInfoTick están cerrados. El resultado es el siguiente.
Si la CPU está sobrecargada (como Optimize ni siquiera en todos los núcleos), SymbolInfoTick puede tardar hasta decenas de milisegundos en completarse. No hay respuesta a por qué esta función más popular en el Terminal no se instantánea con regularidad. Si es posible, haz fotos de la misma. Y no hay que olvidar que incluso con carga cero de la CPU la función OnTick puede trabajar decenas de milisegundos más tarde que un tick que llega a la Terminal.
En definitiva, bastante desafortunado, pero no puede molestar a los que comercian primitivamente.
Para los que comercian con lo "no primitivo": el hardware tiene que estar a la altura.
"ni siquiera en todos los núcleos" - ¿se refiere a "6/8"? es decir, 6 procesos, y cada uno de ellos carga al 100% un núcleo de la CPU durante la prueba? ¿Y sólo hay 4 núcleos físicos? ¿Y sinceramente se sorprenden de que en tal fondo la prueba "se retrase"?
Si este es realmente su nivel de comprensión, entonces: "Aprender, aprender y volver a aprender".
Si quieres violar una CPU con 16-20 hilos, compra una CPU con 20 núcleos físicos como mínimo.
Para los que comercian con lo "no primitivo": el hardware tiene que estar a la altura.
"ni siquiera en todos los núcleos" - ¿se refiere a "6/8"? es decir, a 6 procesos, y cada uno de ellos carga al 100% un núcleo de la CPU durante todo el tiempo de la prueba? ¿Y sólo hay 4 núcleos físicos? ¿Y sinceramente se sorprenden de que sobre ese fondo la prueba "se ralentice"?
Si este es realmente su nivel de comprensión, entonces: "Aprender, aprender y volver a aprender".
Si quieres violar una CPU con 16-20 hilos, compra una CPU con 20 núcleos físicos como mínimo.
Estoy seguro de que puedo demostrar que la aplicación de sus precios actuales es muy lenta. La carga de la CPU crea tal lentitud sólo por la implementación incorrecta de la función más importante en MQL5.
Estoy seguro de que puedo demostrar que su aplicación para obtener los precios actuales es muy lenta. La carga de la CPU sólo crea tales ralentizaciones debido a la implementación incorrecta de la función principal en MQL5.
Código de prueba:
voidOnTick()
{
MqlTick Tick;
ulong gstart=GetMicrosecondCount();
int count=10000;
for(int i=0; i<count; i++)
{
SymbolInfoTick(_Symbol, Tick);
}
ulong gend=GetMicrosecondCount()-gstart;
Print(count," iterations, total time ", DoubleToString(gend/1000.0,3)," ms; avr time: ",DoubleToString(gend/1000.0/count,3)," ms");
}
¿Cómo se hace eso?
Sólo reprodujo los frenos cuando los 6/8 Agentes estaban en marcha.
Sólo reprodujo los frenos cuando los 6/8 Agentes estaban en marcha.
Es decir, el problema cuando la CPU está cargada.
MQ-Demo, 20 gráficos, b2656. Sólo se está ejecutando el Terminal en la máquina, el Tester no se está ejecutando.
Sólo reprodujo los frenos cuando los 6/8 Agentes estaban en marcha.
Es decir, el problema es cuando la CPU está cargada.
¿Es una información nueva para usted?
¿Es una información nueva para usted?
No entiendo muy bien por qué es imposible sortear estos lapsos de carga de la CPU. Probablemente sea incompetente para hacerlo.
Sin embargo, a continuación hay una prueba limpia que muestra el problema de la relevancia de los datos de precios en MT5. He proporcionado el código con comentarios. Brevemente, los ticks se toman a través de SymbolInfoTick/stack y se comprueban entre sí. En particular, para evitar lagunas y grandes desfases entre ticks idénticos de diferentes fuentes.
Resultado (sólo un MT5-b2656 funcionando en la máquina, carga de CPU alrededor de cero, un gráfico, Tester no utilizado).
Por favor, confirme la reproducción.
Total intermedio para una máquina de descarga rápida.
Pregunta a los promotores.
Supongamos que SymbolInfoTick se ejecutó durante 5 ms. ¿Corresponderá el tick a la hora actual, o a 5 ms antes?
Los frenos de SymbolInfoTick están cerrados. El resultado es el siguiente.
Si la CPU está sobrecargada (como Optimize ni siquiera en todos los núcleos), SymbolInfoTick puede tardar hasta decenas de milisegundos en completarse. No hay respuesta a por qué esta función más popular en el Terminal no se instantánea con regularidad. Si es posible, haz fotos de la misma. Y no hay que olvidar que incluso con carga cero de la CPU la función OnTick puede trabajar decenas de milisegundos más tarde que un tick que llega a la Terminal.
En definitiva, bastante triste, pero no puede preocupar a los que comercian primitivamente.
Los frenos de SymbolInfoTick están cerrados. El resultado es el siguiente.
Si la CPU está sobrecargada (como Optimize ni siquiera en todos los núcleos), SymbolInfoTick puede tardar hasta decenas de milisegundos en completarse. No hay respuesta a por qué esta función más popular en el Terminal no se instantánea con regularidad. Si es posible, haz fotos de la misma. Y no hay que olvidar que incluso con carga cero de la CPU la función OnTick puede trabajar decenas de milisegundos más tarde que un tick que llega a la Terminal.
En definitiva, bastante desafortunado, pero no puede molestar a los que comercian primitivamente.
Para los que comercian con lo "no primitivo": el hardware tiene que estar a la altura.
"ni siquiera en todos los núcleos" - ¿se refiere a "6/8"? es decir, 6 procesos, y cada uno de ellos carga al 100% un núcleo de la CPU durante la prueba? ¿Y sólo hay 4 núcleos físicos? ¿Y sinceramente se sorprenden de que en tal fondo la prueba "se retrase"?
Si este es realmente su nivel de comprensión, entonces: "Aprender, aprender y volver a aprender".
Si quieres violar una CPU con 16-20 hilos, compra una CPU con 20 núcleos físicos como mínimo.
Para los que comercian con lo "no primitivo": el hardware tiene que estar a la altura.
"ni siquiera en todos los núcleos" - ¿se refiere a "6/8"? es decir, a 6 procesos, y cada uno de ellos carga al 100% un núcleo de la CPU durante todo el tiempo de la prueba? ¿Y sólo hay 4 núcleos físicos? ¿Y sinceramente se sorprenden de que sobre ese fondo la prueba "se ralentice"?
Si este es realmente su nivel de comprensión, entonces: "Aprender, aprender y volver a aprender".
Si quieres violar una CPU con 16-20 hilos, compra una CPU con 20 núcleos físicos como mínimo.
Estoy seguro de que puedo demostrar que la aplicación de sus precios actuales es muy lenta. La carga de la CPU crea tal lentitud sólo por la implementación incorrecta de la función más importante en MQL5.
Estoy seguro de que puedo demostrar que su aplicación para obtener los precios actuales es muy lenta. La carga de la CPU sólo crea tales ralentizaciones debido a la implementación incorrecta de la función principal en MQL5.
Código de prueba:
Pruébalo.