Jump to page: 1 2
Thread overview
getUTCtime() increases irregularly
Apr 04, 2007
david
Apr 04, 2007
Frits van Bommel
Apr 04, 2007
david
Apr 04, 2007
Frits van Bommel
Apr 04, 2007
Sean Kelly
Apr 05, 2007
Manfred Nowak
Apr 05, 2007
Manfred Nowak
Apr 08, 2007
david
Apr 05, 2007
KlausO
April 04, 2007
Hello,

I was just playing with a slow down class, when I noticed
getUTCtime() from std.date works a bit unexpected:

import std.stdio;
import std.date : getUTCtime;

int main(char[][] args)
{
	for (int i=0;i<500;i++)
		writefln(getUTCtime());
	return 0;
}

results in (shortened version, for obvious reasons):

1175692021281
1175692021281
1175692021281
1175692021281
1175692021281
1175692021281
1175692021281
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021296
1175692021312
1175692021312
1175692021312
1175692021312
1175692021312
1175692021312
1175692021312
1175692021312
1175692021312
1175692021312
1175692021312
1175692021312
1175692021312

So, it increases as well in large increments
and also in irregular ones, namely
15 and 16 milliseconds.

Since I found nothing in the phobos docs,
how can I access the current time at a more
precise level?

david
April 04, 2007
david wrote:
> I was just playing with a slow down class, when I noticed
> getUTCtime() from std.date works a bit unexpected:
> 
> import std.stdio;
> import std.date : getUTCtime;
> 
> int main(char[][] args)
> {
>     for (int i=0;i<500;i++)
>         writefln(getUTCtime());
>     return 0;
> }
> 
> results in (shortened version, for obvious reasons):
> 
[snip]
> 
> So, it increases as well in large increments
> and also in irregular ones, namely
> 15 and 16 milliseconds.
> 
> Since I found nothing in the phobos docs,
> how can I access the current time at a more
> precise level?

The precision of the clock is operating-system dependent AFAIK. (including the version of the OS and obviously the type of machine it's running on)
D can't make it more accurate than the OS is willing to provide :(.

(Your post header indicates you're running Windows)
On Windows, there are (at least) two functions to get the current time: one returns it as a SYSTEMTIME structure, one as a FILETIME structure. It looks like std.date uses GetSystemTime; you could try to see if GetFileTime is more accurate. (no idea why it would be, but you could try...)
Try this:
---
import std.c.windows.windows : GetSystemTimeAsFileTime, FILETIME;
import std.date;

d_time currentFileTime() {
    FILETIME ft;
    GetSystemTimeAsFileTime(&ft);
    return std.date.FILETIME2D_time(ft);
}
---
(Coded with no access to a Windows computer, so completely untested. I just had the std.date source and pages referenced from http://msdn2.microsoft.com/en-us/library/ms725479.aspx to work with)
April 04, 2007
Frits van Bommel schrieb:
> david wrote:
>> I was just playing with a slow down class, when I noticed
>> getUTCtime() from std.date works a bit unexpected:
>>
>> import std.stdio;
>> import std.date : getUTCtime;
>>
>> int main(char[][] args)
>> {
>>     for (int i=0;i<500;i++)
>>         writefln(getUTCtime());
>>     return 0;
>> }
>>
>> results in (shortened version, for obvious reasons):
>>
> [snip]
>>
>> So, it increases as well in large increments
>> and also in irregular ones, namely
>> 15 and 16 milliseconds.
>>
>> Since I found nothing in the phobos docs,
>> how can I access the current time at a more
>> precise level?
> 
> The precision of the clock is operating-system dependent AFAIK. (including the version of the OS and obviously the type of machine it's running on)
> D can't make it more accurate than the OS is willing to provide :(.
> 
> (Your post header indicates you're running Windows)
> On Windows, there are (at least) two functions to get the current time: one returns it as a SYSTEMTIME structure, one as a FILETIME structure. It looks like std.date uses GetSystemTime; you could try to see if GetFileTime is more accurate. (no idea why it would be, but you could try...)
> Try this:
> ---
> import std.c.windows.windows : GetSystemTimeAsFileTime, FILETIME;
> import std.date;
> 
> d_time currentFileTime() {
>     FILETIME ft;
>     GetSystemTimeAsFileTime(&ft);
>     return std.date.FILETIME2D_time(ft);
> }
> ---
> (Coded with no access to a Windows computer, so completely untested. I just had the std.date source and pages referenced from http://msdn2.microsoft.com/en-us/library/ms725479.aspx to work with)

Thanks for the idea,
but as you thought the precision is the same,
d_time currentFileTime()
{
    FILETIME ft;
    GetSystemTimeAsFileTime(&ft);
    return std.date.FILETIME2d_time(&ft);
}
yields the same result as getUTCtime().
(And for that matter, as a direct GetSystemTime().)
April 04, 2007
david wrote:
> Frits van Bommel schrieb:
>> (Your post header indicates you're running Windows)
>> On Windows, there are (at least) two functions to get the current time: one returns it as a SYSTEMTIME structure, one as a FILETIME structure. It looks like std.date uses GetSystemTime; you could try to see if GetFileTime is more accurate. (no idea why it would be, but you could try...)
[snip code]
> 
> Thanks for the idea,
> but as you thought the precision is the same,
> d_time currentFileTime()
> {
>     FILETIME ft;
>     GetSystemTimeAsFileTime(&ft);
>     return std.date.FILETIME2d_time(&ft);
> }
> yields the same result as getUTCtime().
> (And for that matter, as a direct GetSystemTime().)

Yeah, it's probably just because your Windows version didn't set whatever timer source it uses to >= 1000 ticks/second. Understandable, since short timer ticks probably have a negative effect on performance.

I also wouldn't be surprised to find out that different versions of the same OS used differently sized timer ticks (getting shorter with more recent versions since CPUs keep getting faster and performance penalties may drop because of it).
Or for that matter, if the size of a tick can be different on two machines running on the same version of the same OS if one machine doesn't have a particular (better) timer source in the hardware that the other does, or if the OS decides that a faster computer can handle shorter timer ticks...
April 04, 2007
Frits van Bommel wrote:
> 
> Yeah, it's probably just because your Windows version didn't set whatever timer source it uses to >= 1000 ticks/second. Understandable, since short timer ticks probably have a negative effect on performance.

Right.  I think the Windows system clock has a resolution of around 10ms.  However, I believe there are ways to obtain higher-resolution timing information, either using realtime features, the multimedia API, or by some other means.  I couldn't name actual API calls offhand though.



Sean
April 05, 2007
Sean Kelly wrote

> I believe there are ways to obtain higher-resolution timing information

What about this:

import std.stdio;
import internal.trace: QueryPerformanceCounter;

int main(char[][] args)
{
    	long t;
	for (int i=0;i<500;i++){
    	    	QueryPerformanceCounter( &t);
		writefln(t);
    	}
	return 0;
}


-manfred
April 05, 2007
Sean Kelly schrieb:
> Frits van Bommel wrote:
>>
>> Yeah, it's probably just because your Windows version didn't set whatever timer source it uses to >= 1000 ticks/second. Understandable, since short timer ticks probably have a negative effect on performance.
> 
> Right.  I think the Windows system clock has a resolution of around 10ms.  However, I believe there are ways to obtain higher-resolution timing information, either using realtime features, the multimedia API, or by some other means.  I couldn't name actual API calls offhand though.
> 
> 
> 
> Sean

You mean the timeXXX-API e.g.
 timeBeginPeriod
 timeEndPeriod
 timeGetSystemTime
April 05, 2007
"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:ev2nlr$cfa$1@digitalmars.com...
> Sean Kelly wrote
>
>> I believe there are ways to obtain higher-resolution timing information
>
> What about this:
>
> import std.stdio;
> import internal.trace: QueryPerformanceCounter;
>
> int main(char[][] args)
> {
>    long t;
> for (int i=0;i<500;i++){
>        QueryPerformanceCounter( &t);
> writefln(t);
>    }
> return 0;
> }
>
>
> -manfred

std.perf.HighPerformanceCounter uses the same Windows API but will convert to seconds, milliseconds, and microseconds for you.  It's cross-platform, too, using gettimeofday on *nix platforms.

Unfortunately if David is looking to use this as a timestamp, i.e. in files, the value you get from QPC doesn't represent any useful amount of time IIRC. It's just a counter incremented by the processor from the time the computer starts.


April 05, 2007
Jarrett Billingsley wrote

> Unfortunately if David is looking to use this as a timestamp

In the OP it says:

| playing with a slow down class

-manfred
April 05, 2007
"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:ev3jhs$28o4$1@digitalmars.com...
> Jarrett Billingsley wrote
>
>> Unfortunately if David is looking to use this as a timestamp
>
> In the OP it says:
>
> | playing with a slow down class
>
> -manfred

I... don't know what that is.


« First   ‹ Prev
1 2