Funcionó con precisión tanto a las 10:00 como a las 14:05
2017.01.2610:00:00.000 Time_sync_forts (URKA-3.17,H1) Local time sync is done. Symbol = RTS-3.17 Sync hour = 10 Sync min = 0 Sync sec = 0 Sync ms = 0 2017.01.2614:05:00.005 Time_sync_forts (URKA-3.17,H1) Local time sync is done. Symbol = RTS-3.17 Sync hour = 14 Sync min = 5 Sync sec = 0 Sync ms = 5
Añadido
Creo que voy a quitar BR para que todo pase automáticamente durante 3 meses :)
¿Y alguna idea de cómo "fastidiar" la compensación nocturna, dado que la subasta puede empezar a las 19-00, y luego a las 19-05?
Se ha hecho un trabajo muy minucioso. Dado que la sincronización horaria mediante el método sugerido se basa en tener en cuenta el valor del ping, tengo una pregunta.
Al solicitar el identificador TERMINAL_PING_LAST, el terminal da (según la documentación de MQL) el"Último valor conocido del ping al servidor comercial en microsegundos".
¿Qué es, su valor es estable y qué tamaño tiene? Durante muchos años he visto esta característica en los archivos de registro, pero ahora puedo ver los pings en la lista de servidores directamente en el terminal. Y son muy estables. ¿Qué es?
Sólo dos variantes que puedo imaginar.
1) Es una característica de red utilizada por los routers para analizar las trayectorias de los paquetes IP, que se obtiene mediante el protocolo de red ICMP y que, en realidad, sólo tiene en cuenta la propagación de la señal de hardware. En el caso particular de las mediciones de ping entre un ordenador cliente y un servidor, se trata de un ida y vuelta entre sus NIC. Los paquetes con este protocolo no suelen llegar a las aplicaciones, no es necesario https://ru.wikipedia.org/wiki/ICMP.
2. duplica el tiempo de viaje de la señal desde la aplicación en el servidor hasta la aplicación en el cliente.
ICMP Название: Уровень (по модели OSI): Семейство: Спецификация: ICMP (англ. — протокол межсетевых управляющих сообщений[1]) — сетевой протокол, входящий в стек протоколов TCP/IP. В основном ICMP используется для передачи сообщений об ошибках и других исключительных ситуациях, возникших при передаче данных, например, запрашиваемая услуга...
Se ha hecho un trabajo muy minucioso. Dado que la sincronización horaria mediante el método sugerido se basa en tener en cuenta el valor del ping, tengo una pregunta.
Al solicitar el identificador TERMINAL_PING_LAST, el terminal da (según la documentación de MQL) el"Último valor conocido del ping al servidor comercial en microsegundos".
¿Qué es, su valor es estable y qué tamaño tiene? Durante muchos años he visto esta característica en los archivos de registro, pero ahora puedo ver los pings en la lista de servidores directamente en el terminal. Y son muy estables. ¿Qué es?
Sólo dos variantes que puedo imaginar.
1) Es una característica de red que los routers utilizan para analizar las rutas de los paquetes IP, que se obtiene mediante el protocolo de red ICMP y que, en realidad, sólo tiene en cuenta la propagación de la señal de hardware. En el caso particular de las mediciones de ping entre un ordenador cliente y un servidor, se trata de un ida y vuelta entre sus NIC. Los paquetes con este protocolo no suelen llegar a las aplicaciones, no es necesario https://ru.wikipedia.org/wiki/ICMP.
2. duplica el tiempo de viaje de la señal desde la aplicación en el servidor hasta la aplicación en el cliente.
¿Alguien tiene una pista?
Sólo los desarrolladores pueden responder a esta pregunta con seguridad.
Me basaba en el segundo.
>Esto es el doble del tiempo de viaje de la señal desde la aplicación en el servidor hasta la aplicación en el cliente.
Y la sesión de la mañana y después de ambos despeja.
Todo funciona "como un reloj" :)
2017.01.3010:00:00.000 Time_symc_forts (URKA-3.17,H1) Local time sync is done. Symbol = Si-3.17 Sync hour = 10 Sync min = 0 Sync sec = 0 Sync ms = 0 2017.01.3014:05:00.002 Time_symc_forts (URKA-3.17,H1) Local time sync is done. Symbol = Si-3.17 Sync hour = 14 Sync min = 5 Sync sec = 0 Sync ms = 2 2017.01.3019:00:00.003 Time_symc_forts (URKA-3.17,H1) Local time sync is done. Symbol = Si-3.17 Sync hour = 19 Sync min = 0 Sync sec = 0 Sync ms = 3
2017.01.3010:00:00.000 Time_symc_forts (URKA-3.17,H1) Local time sync is done. Symbol = Si-3.17 Sync hour = 10 Sync min = 0 Sync sec = 0 Sync ms = 0 2017.01.3014:05:00.002 Time_symc_forts (URKA-3.17,H1) Local time sync is done. Symbol = Si-3.17 Sync hour = 14 Sync min = 5 Sync sec = 0 Sync ms = 2 2017.01.3019:00:00.003 Time_symc_forts (URKA-3.17,H1) Local time sync is done. Symbol = Si-3.17 Sync hour = 19 Sync min = 0 Sync sec = 0 Sync ms = 3
Añadido
Sólo espero que la puja comience en 19-05
Añadido
Para Sergey
https://www.mql5.com/ru/forum/166646
Sólo por diversión, enciéndelo si no te importa, veamos con qué precisión se sincroniza la hora:
//+------------------------------------------------------------------+ //| Delta Time Server.mq5 | //+------------------------------------------------------------------+ struct _SYSTEMTIME { short year; short mon; short day_of_week; short day; short hour; short min; short sec; short msc; };
Para iniciar sesión y usar el sitio web MQL5.com es necesario permitir el uso de Сookies.
Por favor, active este ajuste en su navegador, de lo contrario, no podrá iniciar sesión.
Ha iniciado sesión. La autenticación de dos factores se ha desactivado. Vuelva a configurarla y escanee un nuevo código QR, o continúe con la autenticación de dos factores desactivada.
Por favor, envíe aquí las instrucciones sobre cómo abrir una cuenta real en BCS.
Para no tener que rebuscar cada vez, lo he puesto en mi perfil.
Alexey Kozitsyn:
Gracias, ya lo he hecho yo.Спасиб
Haciendo una coincidencia, hay diferencias, pero no significativas.
En mi opinión, la función de registrar los ticks de las órdenes en el historial no funciona correctamente (las operaciones están bien).
Haré 300 líneas y publicaré el archivo de comparación.
Añadido
Compruébalo, puede que me haya equivocado
Funcionó con precisión tanto a las 10:00 como a las 14:05
2017.01.26 14:05:00.005 Time_sync_forts (URKA-3.17,H1) Local time sync is done. Symbol = RTS-3.17 Sync hour = 14 Sync min = 5 Sync sec = 0 Sync ms = 5
Añadido
Creo que voy a quitar BR para que todo pase automáticamente durante 3 meses :)
Así que eso es todo.
Y la sesión de la mañana y después de ambos despeja.
Se ha hecho un trabajo muy minucioso. Dado que la sincronización horaria mediante el método sugerido se basa en tener en cuenta el valor del ping, tengo una pregunta.
Al solicitar el identificador TERMINAL_PING_LAST, el terminal da (según la documentación de MQL) el"Último valor conocido del ping al servidor comercial en microsegundos".
¿Qué es, su valor es estable y qué tamaño tiene? Durante muchos años he visto esta característica en los archivos de registro, pero ahora puedo ver los pings en la lista de servidores directamente en el terminal. Y son muy estables. ¿Qué es?
Sólo dos variantes que puedo imaginar.
1) Es una característica de red utilizada por los routers para analizar las trayectorias de los paquetes IP, que se obtiene mediante el protocolo de red ICMP y que, en realidad, sólo tiene en cuenta la propagación de la señal de hardware. En el caso particular de las mediciones de ping entre un ordenador cliente y un servidor, se trata de un ida y vuelta entre sus NIC. Los paquetes con este protocolo no suelen llegar a las aplicaciones, no es necesario https://ru.wikipedia.org/wiki/ICMP.
2. duplica el tiempo de viaje de la señal desde la aplicación en el servidor hasta la aplicación en el cliente.
¿Alguien tiene una pista?
Se ha hecho un trabajo muy minucioso. Dado que la sincronización horaria mediante el método sugerido se basa en tener en cuenta el valor del ping, tengo una pregunta.
Al solicitar el identificador TERMINAL_PING_LAST, el terminal da (según la documentación de MQL) el"Último valor conocido del ping al servidor comercial en microsegundos".
¿Qué es, su valor es estable y qué tamaño tiene? Durante muchos años he visto esta característica en los archivos de registro, pero ahora puedo ver los pings en la lista de servidores directamente en el terminal. Y son muy estables. ¿Qué es?
Sólo dos variantes que puedo imaginar.
1) Es una característica de red que los routers utilizan para analizar las rutas de los paquetes IP, que se obtiene mediante el protocolo de red ICMP y que, en realidad, sólo tiene en cuenta la propagación de la señal de hardware. En el caso particular de las mediciones de ping entre un ordenador cliente y un servidor, se trata de un ida y vuelta entre sus NIC. Los paquetes con este protocolo no suelen llegar a las aplicaciones, no es necesario https://ru.wikipedia.org/wiki/ICMP.
2. duplica el tiempo de viaje de la señal desde la aplicación en el servidor hasta la aplicación en el cliente.
¿Alguien tiene una pista?
Sólo los desarrolladores pueden responder a esta pregunta con seguridad.
Me basaba en el segundo.
>Esto es el doble del tiempo de viaje de la señal desde la aplicación en el servidor hasta la aplicación en el cliente.
Así que eso es todo.
Y la sesión de la mañana y después de ambos despeja.
Todo funciona "como un reloj" :)
2017.01.30 14:05:00.002 Time_symc_forts (URKA-3.17,H1) Local time sync is done. Symbol = Si-3.17 Sync hour = 14 Sync min = 5 Sync sec = 0 Sync ms = 2
2017.01.30 19:00:00.003 Time_symc_forts (URKA-3.17,H1) Local time sync is done. Symbol = Si-3.17 Sync hour = 19 Sync min = 0 Sync sec = 0 Sync ms = 3
Añadido
Solo espero que la puja comience a las 19-05
Todo funciona "como un reloj" :)
2017.01.30 14:05:00.002 Time_symc_forts (URKA-3.17,H1) Local time sync is done. Symbol = Si-3.17 Sync hour = 14 Sync min = 5 Sync sec = 0 Sync ms = 2
2017.01.30 19:00:00.003 Time_symc_forts (URKA-3.17,H1) Local time sync is done. Symbol = Si-3.17 Sync hour = 19 Sync min = 0 Sync sec = 0 Sync ms = 3
Añadido
Sólo espero que la puja comience en 19-05
Añadido
Para Sergey
https://www.mql5.com/ru/forum/166646
Sólo por diversión, enciéndelo si no te importa, veamos con qué precisión se sincroniza la hora:
//| Delta Time Server.mq5 |
//+------------------------------------------------------------------+
struct _SYSTEMTIME
{
short year;
short mon;
short day_of_week;
short day;
short hour;
short min;
short sec;
short msc;
};
_SYSTEMTIME loc_time;
#import "kernel32.dll"
void GetLocalTime(_SYSTEMTIME &sys_time);
bool SetLocalTime(_SYSTEMTIME &sys_time);
#import
//---
MqlTick tick;
MqlDateTime sv_time;
int tick_msc,ping,time_server,time_local,delta=0,mdelta[10],n=0;
//+------------------------------------------------------------------+
//| Expert tick function |
//+------------------------------------------------------------------+
void OnTick()
{
loc_time.year=0;
GetLocalTime(loc_time);
if(loc_time.year>0)
{
if(!SymbolInfoTick(_Symbol,tick)) { Print("error SymbolInfoTick: ",GetLastError()); return; }
ping=TerminalInfoInteger(TERMINAL_PING_LAST)/1000;
tick_msc=int(tick.time_msc%1000);
TimeToStruct(tick.time,sv_time);
time_server=(sv_time.sec+sv_time.min*60)*1000+tick_msc;
time_local=(loc_time.sec+loc_time.min*60)*1000+loc_time.msc;
delta=AvgDelta(time_server-time_local);
Print(
"ping : ",ping,
" | time server: ",sv_time.hour,":",sv_time.min,":",sv_time.sec,",",tick_msc,
" | time local: ",loc_time.hour,":",loc_time.min,":",loc_time.sec,",",loc_time.msc,
" | delta ms: ",delta,
" | min max delta: ",mdelta[ArrayMaximum(mdelta)]," : ",mdelta[ArrayMinimum(mdelta)],
"");
}
}
//+------------------------------------------------------------------+
int AvgDelta(int d)
{
int avgd=0;
mdelta[n]=d;
n++; if(n>=10) n=0;
for(int i=0;i<10;i++) avgd+=mdelta[i];
return(avgd/10);
}
//+------------------------------------------------------------------+