20 replies to this topic

[escafandra]

La API de Winsows GetTickCount nos devuelve el número de microsegundos desde que se inició el sistema hasta 49.7 días. Este intervalo suele ser suficientemente amplio como para abarcar cualquier medida de tiempo en una aplicación. Pero contiene dos cosas que no son apetecibles:

1. La cuenta no comienza desde cero sino desde el inicio del sistema.

2. Si llegamos al valor de ‭4294967295‬ microsegundos ($FFFFFFFF) que representan los 49.7 días, obtendermos un acarreo que hay que tener en cuenta.

 
En un reciente proyecto multimedia, en el que la medida temporal era determinante hasta la precisión del microsegundo, solucioné los dos inconvenientes con una simple función que me permite poner a cero la cuenta de microsegundos teniendo en cuenta el acarreo y, además, me devuelve el número de microsegundos transcurridos desde la puesta a cero.
 
Esta es la versión C:

cpp

DWORD GetTickNow(BOOL Start = FALSE)
{
  static DWORD Old;
  if(Start) Old = GetTickCount();
 
  if(GetTickCount() < Old)
    return GetTickCount() - Old + 0xFFFFFFFF;
  return GetTickCount() - Old;
}

Y esta es la versión delphi:

delphi

function GetTickNow(Start: BOOL = FALSE): DWORD;
const
{$J+}
  Old: DWORD = 0;
{$J-}
begin
  if Start then Old:= GetTickCount();
 
  if GetTickCount() < Old then
    Result:= GetTickCount() - Old + $FFFFFFFF
  else Result:= GetTickCount() - Old;
end;

De esta forma, aunque el límite siguen siendo 49.7 días, lo es desde la puesta a cero. Si necesitáramos un intervalo mayor, podemos usar como valor de vuelta un QWORD (unsigned int64).

El uso es bien simple. Para poner a cero la cuenta:

delphi

GetTickNow(true);

 
Para obtener el tiempo desde la puesta a cero:

delphi

// Delphi
T:= GetTickNow;
// C/C++
T = GetTickNow();

Espero que sea de utilidad.


Saludos.

[Delphius]

Hola Carlos,

Hay un detalle que no logro entender del todo bien en la operatoria... Veo que invocas a GetTickCount unas 2 o 3 veces... ¿Es realmente necesario? ¿No podría directamente usarse una variable y usarla para los cálculos?

 

Por otra parte, recuerdo que Ian Marteens en su sitio web de Delphi recomendaba no usar GetTickCount y en su lugar emplear QueryPerfomanceFrecuency y QueryPerfomanceCounter para tener precisión. Aquí el artículo en cuestión. Desconozco si al día de hoy sigue siendo igual de válido este punto, o si es que GetTickCount habrá sido mejorada. La ayuda (MSDN) sugiere otros timers para mejorar precisión asi que es posible que no haya cambiado mucho.

 

Del enlace que pusiste a la API, ahí mismo se sugiere otra alternativa a GetTickCount para evitar el problemas del acarreo tras los 49.7 días: GetTickCount64. Tengo que admitir que es la primera vez que conozco esta versión de la API, y ni recordaba de que GetTickCount tuviera ese problema de los 49.7 días. Yo recordaba de las palabras de Ian que simplemente GetTickCount no es precisa.

 

Me pregunto yo, ¿Porqué no directamente usas esta versión de la API? ¿O hay alguna restricción o limitación del tipo técnica a considerar? La MSDN dice que GetTickCount64 es soportada desde W. Vista. No se si es por eso, o hay algo más.

Como yo ignoro muchos aspectos de las APIs y tu eres el experto imagino que debes tener tus razones.

 

Saludos,

[escafandra]

Hola Marcelo.

 

Uso llamadas repetidas a GetTickCount para no perder el acarreo que pudiera producirse en el transcurso de la función y devolver un tiempo exacto.

 

Tienes mucha razón en hacer la observación de APIs alternativas más precisas o que minimizan el acarreo. Elegí usar GetTickCount porque la precisión de unos pocos milisegundos (~10 a 16ms) me bastaba y no quería usar aritmética de 64bits en una App de 32bits que no me aportaba más precisión a la necesitada. Lo que si me resultaba molesto era el inicio de cuenta y el acarreo. Por eso implementé GetTickNow.

 

Las alternativas propuestas por M$ son correctas. Si te fijas, ellos mismos proponen QueryPerformanceFrequency y QueryPerformanceCounter además de GetTickCount64. Esta última tiene la misma resolución que su versión 32bits (~10 ms) pero con un acarreo enormemente mayor.

 

La elección depende de la precisión realmente necesitada. En mi caso se trataba de sincronizar fotogramas en relación al tiempo total transcurrido de video. Teniendo en cuenta que la frecuencia más alta de 60fps corresponden a un lapso de 16 ms, la precisión de GetTickCount era suficiente.

 

 

Saludos.

[Delphius]

Muchas gracias por la aclaración amigo.

Vaya, eso de que aún usando GetTickCount64 tenemos el límite de 49 años pero con más acarreo es una sorpresa. No había visto que más abajo estaba la nota en la doc.

Con razón sugiere que se usen las API QueryPerfomance.

 

Sabía que habría alguna motivación y razón de tu parte para no ir por más precisión. Ahora entiendo.

Yo me he acostumbrado a seguir el consejo de Ian Marteens cuando lo necesito asi que me resultó "raro" encontrarme con tu propuesta.

 

Saludos,

[escafandra]

El tema es que no hay un método mejor o peor. El bueno es el que te hace falta en un momento dado y te complica menos la vida. GetTickCount suele ser suficiente para casi todos los casos y su aritmética es simple. Es un caso parecido al uso de float, double u otros tipos más precisos para aritmética de punto flotante.

 

Al final siempre va a estar el límite del tamaño en bits del tipo usado, que generará un acarreo. El tema es conocerlo y ajustarse a la necesidad real, como tú has dicho varias veces.   

 

 

Saludos.

[egostar]

El tema es que no hay un método mejor o peor. El bueno es el que te hace falta en un momento dado y te complica menos la vida. GetTickCount suele ser suficiente para casi todos los casos y su aritmética es simple. Es un caso parecido al uso de float, double u otros tipos más precisos para aritmética de punto flotante.
 
Al final siempre va a estar el límite del tamaño en bits del tipo usado, que generará un acarreo. El tema es conocerlo y ajustarse a la necesidad real, como tú has dicho varias veces.   
 
 
Saludos.

Es como la eterna discusión de que motor de base de datos usar.... 

 

Como siempre yo digo depende, depende, depende

 

Quiero decir, la mejor base de datos es la que hace lo que necesitas, ni mas ni menos. 

 

Saludos

[Delphius]

El tema es que no hay un método mejor o peor. El bueno es el que te hace falta en un momento dado y te complica menos la vida. GetTickCount suele ser suficiente para casi todos los casos y su aritmética es simple. Es un caso parecido al uso de float, double u otros tipos más precisos para aritmética de punto flotante.

 

Al final siempre va a estar el límite del tamaño en bits del tipo usado, que generará un acarreo. El tema es conocerlo y ajustarse a la necesidad real, como tú has dicho varias veces.   

 

 

Saludos.

 

A lo que apunto es que de que me sirve la versión 64 si al final tenemos el mismo período de tiempo (49 días) y se ve afectado por lo haga QueryUnbiasedInterruptTime. No supone gran cambio realmente.

Lo de compararlo con flotantes no es tan exacto en realidad. Pasar de single a double es un gran cambio, y lo mismo a extended. La precisión que nos da esos decimales y el rango numérico crece de manera exponencial. Obviamente que estos tipos tienen sus límites, su precisión a estos decimales, y que la aritemética de punto flotante requiere de ciertas consideraciones técnicas como por ejemplo que no todos los números son representables (sino aproximados) y hay que trabajar con márgenes de error de tolerancia absoluta y/o relativa.

 

En el caso de las GetTickCount, si ambas tienen la misma resolución entre 10 y 16ms y al final de una u otra ambas sufren el defecto de los 49 días, ¿para que la doc de GetTickCount sugiere ir por GetTickCount64?

 

¿O es que yo estoy entendiendo mal lo que dice el apartado Note de la doc de GetTickCount64?

 

Ian en su artículo aclara que se le puede dar uso a GetTickCount sin problemas para varias situaciones, claro está que para ciertas acciones un tanto más críticas o que requieran de una precisión fina hay que buscar algo más elaborado.

Eso no lo niego.

 

Saludos,

[escafandra]

A lo que apunto es que de que me sirve la versión 64 si al final tenemos el mismo período de tiempo (49 días) y se ve afectado por lo haga QueryUnbiasedInterruptTime. No supone gran cambio realmente.
Lo de compararlo con flotantes no es tan exacto en realidad. Pasar de single a double es un gran cambio, y lo mismo a extended. La precisión que nos da esos decimales y el rango numérico crece de manera exponencial. Obviamente que estos tipos tienen sus límites, su precisión a estos decimales, y que la aritemética de punto flotante requiere de ciertas consideraciones técnicas como por ejemplo que no todos los números son representables (sino aproximados) y hay que trabajar con márgenes de error de tolerancia absoluta y/o relativa.
 
En el caso de las GetTickCount, si ambas tienen la misma resolución entre 10 y 16ms y al final de una u otra ambas sufren el defecto de los 49 días, ¿para que la doc de GetTickCount sugiere ir por GetTickCount64?
 
¿O es que yo estoy entendiendo mal lo que dice el apartado Note de la doc de GetTickCount64?
 
Ian en su artículo aclara que se le puede dar uso a GetTickCount sin problemas para varias situaciones, claro está que para ciertas acciones un tanto más críticas o que requieran de una precisión fina hay que buscar algo más elaborado.
Eso no lo niego.
 
Saludos,

 
Cuando hago la comparación con tipos de coma flotante me refiero a la precisión y no al acarreo, comparando GetTickCount con QueryPerformanceFrequency y QueryPerformanceCounter. No tengo claro que GetTickCount64 tenga el límite en 49 días. Si calculamos los días que da como máximo un DWORD ($FFFF FFFF) son 49,71026961805556 días. Un QWORD nos daría 584942421,57 años. En cualquier caso se puede hacer una función que devuelva un QWORD a partir de GetTickCount controlando el acarreo, la pregunta es si tiene sentido...

 

La precisión en ms de GetTickCount y GetTickCount64 es idéntica por lo que no tiene mucho sentido usar la versión 64 a no ser que pensemos en tiempos mayores de 49 días y asumamos que el acarreo de GetTickCount64 es en 584.942.421 años. ¿Alguien se anima a comprobar el resultado de la cuenta de GetTickCount64 pasados 50 días con el PC en marcha? Así salimos de dudas .

 

 

Saludos.

[Delphius]

Si, entiendo el punto. Lo que me llama la atención es lo que leo en la documentación de la API GetTickCount64:

 

 

To obtain the time the system has spent in the working state since it was started, use the QueryUnbiasedInterruptTime function.

 

Note  The QueryUnbiasedInterruptTime function produces different results on debug ("checked") builds of Windows, because the interrupt-time count and tick count are advanced by approximately 49 days. This helps to identify bugs that might not occur until the system has been running for a long time. The checked build is available to MSDN subscribers through the Microsoft Developer Network (MSDN) Web site.

 

Ahí mismo dice que si desea obtener el timpo del sistema desde que se ha iniciado que se use QueryUnbiasedInterruptTime.

Pero en la nota misma dice que sufre el mismo "problema" de los 49 días.

 

Al final Moco$oft nos dice que GetTickCount64 soluciona el dilema de los 49 días, y se la puede usar en lugar de GetTickCount. Pero nos recomienda otra, que tiene el mismo problema.

¿Que debo pensar? ¿Usamos GetTickCount64 o que? ¿Cuál aconsejan y cual no?

 

Saludos,

[escafandra]

Si, entiendo el punto. Lo que me llama la atención es lo que leo en la documentación de la API GetTickCount64:

 

 

Ahí mismo dice que si desea obtener el timpo del sistema desde que se ha iniciado que se use QueryUnbiasedInterruptTime.

Pero en la nota misma dice que sufre el mismo "problema" de los 49 días.

 

Al final Moco$oft nos dice que GetTickCount64 soluciona el dilema de los 49 días, y se la puede usar en lugar de GetTickCount. Pero nos recomienda otra, que tiene el mismo problema.

¿Que debo pensar? ¿Usamos GetTickCount64 o que? ¿Cuál aconsejan y cual no?

 

Saludos,

 

M$ es muy escueto en mucha información y en ocasiones difícil de entender. Estoy acostumbrado a realizar pruebas y encontrar que son dispares a la información dada. En este caso no me importa mucho puesto que ningún vídeo durará 50 días, pero si sería interesante saber el verdadero límite y me parece que o se hace la prueba de los 50 días o no lo sabremos con exactitud.

 

 

Saludos.

[Delphius]

M$ es muy escueto en mucha información y en ocasiones difícil de entender. Estoy acostumbrado a realizar pruebas y encontrar que son dispares a la información dada. En este caso no me importa mucho puesto que ningún vídeo durará 50 días, pero si sería interesante saber el verdadero límite y me parece que o se hace la prueba de los 50 días o no lo sabremos con exactitud.

 

 

Saludos.

 

Lograr hacer esa prueba va a a ser duro... De existir un video que dure 50 días ocuparía varios Teras, y no creo que tengamos nosotros los de a pie algo de esa capacidad.

Es algo impracticable para nosotros.

 

Es bastante probable que sea lo que tu dices amigo. Con GetTickCount incluso aún siendo de 49 días es bastante...  y ni pensar en la cifra que le calculaste que nos permite la versión 64.

 

Esas cosas de la documentación que nos dejan ese sabor a que se lian... Al menos hay doc, y no como otras APIs que ni documentan

 

Saludos,

[escafandra]

Pues esta es la aplicación que nos va a salvar 


Saludos.

Attached Files

•  GetTickCount.rar   157.69KB   4 downloads

[Delphius]

¿No tendrás alguna máquina del tiempo que nos lleve 49 días al futuro?  

 

Si alguien tiene una máquina miedo vieja a la que no tiene drama en dejarla encendida 50 días, bajo un iceberg que la mantenga fria, que haga la prueba. Salta, Argentina está descartado... nos están cortando la luz muy seguido y está más caliente que el infierno   

 

Saludos,

[escafandra]

Es bastante probable que sea lo que tu dices amigo. Con GetTickCount incluso aún siendo de 49 días es bastante...  y ni pensar en la cifra que le calculaste que nos permite la versión 64.

 

Simplemente creo que hicieron un copia-pega de la nota sin saber muy bien lo que hacían.

 

 

Si alguien tiene una máquina miedo vieja a la que no tiene drama en dejarla encendida 50 días, bajo un iceberg que la mantenga fria, que haga la prueba. Salta, Argentina está descartado... nos están cortando la luz muy seguido y está más caliente que el infierno 

 
No seamos dramáticos, en realidad basta con no reiniciar el PC durante 50 días, basta con hibernarlo tras el trabajo. La cuenta sigue funcionando.


Saludos.

[sir.dev.a.lot]

con M$ Windows bastara .... en menos de 15 Dias se reiniciara  , ya sea por Actualizaciones o por cualquier programa tercero que se instale....

 

El sistema Operativo ayudara....

 

Saludos!

[escafandra]

¿No tendrás alguna máquina del tiempo que nos lleve 49 días al futuro?  

Problema resuelto. Aproveché un PC del trabajo que no se apaga nunca y coloqué un programa contador similar al mostrado en este hilo al que añadí una alerta de acarreo. Los contadores llegaron al la cuenta 0000-0000-FFFF-FFFF y se produjo acarreo en ambas APIs. El resultado no es el que esperaba, de modo que GetTickCount64 no lleva la cuenta en un int64 sino en un int32.

Tras esta prueba no que que narices pensaban los de Microsoft cuando escribieron la API GetTickCount64 
 
 
Saludos.

[Delphius]

Problema resuelto. Aproveché un PC del trabajo que no se apaga nunca y coloqué un programa contador similar al mostrado en este hilo al que añadí una alerta de acarreo. Los contadores llegaron al la cuenta 0000-0000-FFFF-FFFF y se produjo acarreo en ambas APIs. El resultado no es el que esperaba, de modo que GetTickCount64 no lleva la cuenta en un int64 sino en un int32.

Tras esta prueba no que que narices pensaban los de Microsoft cuando escribieron la API GetTickCount64 
 
 
Saludos.

 

¿Entonces yo estaba en lo cierto cuando decía que al final la versión 64 tenía el mismo período de tiempo?

Resulta ser que da lo mismo entonces usar una u otra. ¡Moco$oft haciendo honor otra vez a su apodo!

 

Salvo.... que te hayas equivocado y usarle DWORD y no QWORD cuando llamaste a la versión 64, o que por error en ambos contadores llamaste al de 32. Pero como se que eres cuidadoso, es muy poco probable esta pifia.

 

Saludos,

[escafandra]

¿Entonces yo estaba en lo cierto cuando decía que al final la versión 64 tenía el mismo período de tiempo?

Resulta ser que da lo mismo entonces usar una u otra. ¡Moco$oft haciendo honor otra vez a su apodo!

 

Salvo.... que te hayas equivocado y usarle DWORD y no QWORD cuando llamaste a la versión 64, o que por error en ambos contadores llamaste al de 32. Pero como se que eres cuidadoso, es muy poco probable esta pifia.

 

Saludos,

 

Estabas en lo cierto. Esa nota de M$ no era un simple corta-pega sino realidad.

 

Saludos.

[escafandra]

Me precipité al publicar el resultado. El PC donde puse el contador tuvo un reinicio que no advertí al estar cercano a cumplir la fecha de los 49 días lo que interpreté como un fin de cuenta sin acarreo.
 
Introduje una modificación en el código para que mostrase la palabra ACARREO si este ocurriese, de forma que tras un reinicio no aparecería la palabra. Coloqué el contador en otro PC cercano a cumplir la fecha pero no hizo falta esperar pues ya había pasado de los 49 días.
 
GetTickCount64 sobrepasa el límite de un DWORD sigue contando como era de esperar, así que M$ en su explicación metió la gamba y la API trabaja como se esperaba. De todas formas seguiré mirando el contador una temporada más mientras no se reinicie el PC

 

 

Saludos.

[Delphius]

Me precipité al publicar el resultado. El PC donde puse el contador tuvo un reinicio que no advertí al estar cercano a cumplir la fecha de los 49 días lo que interpreté como un fin de cuenta sin acarreo.
 
Introduje una modificación en el código para que mostrase la palabra ACARREO si este ocurriese, de forma que tras un reinicio no aparecería la palabra. Coloqué el contador en otro PC cercano a cumplir la fecha pero no hizo falta esperar pues ya había pasado de los 49 días.
 
GetTickCount64 sobrepasa el límite de un DWORD sigue contando como era de esperar, así que M$ en su explicación metió la gamba y la API trabaja como se esperaba. De todas formas seguiré mirando el contador una temporada más mientras no se reinicie el PC

 

 

Saludos.

 

De todas formas Moco$oft debería hacer la documentación como la gente. Porque no se entiende muy mucho que digamos...

 

Saludos,