Is anybody else getting bummed by the poor resolution in DateTime.Ticks. I mean I'm getting a difference of 0 ticks accross multiple frames which is causing me to lock down my frame rates for one.
The API documentation for the DateTime class specifies that a Tick is 0.0001 seconds. On a 2GHz CPU (single core) a CPU instruction occurs every 0.0000000005 seconds. That means a single Tick can contain 200000 CPU instructions. That seems like it's not
suitable timing short operations.
You could try with Miliseconds (and seconds). This would give you more acuracy. A milisecond in the above example only contains 2000 CPU instructions and may give you measurable results.
It would be helpful if you elaborate on what you're trying to achieve.
HTH.
-------------
Please mark a post as answer if it answers your question.
Visit my blog: http://jvdveen.blogspot.com
So wait! A millisecond has about 100 times better resolution than a Tick? Well I just assumed that Tick would be the lowest resolution. That would solve my problem, thanks.
I realize now I didn't phrase the question correctly. THe problem is the resolution of
DateTime.Now. I don't have that exact numbers on hand but the interval is something like 15 milliseconds. That's the bummer. I need something more accurate than what I'm getting: I need a high precision timer.
I tried changing from ticks to milliseconds but it didn't help the resolution problem.
I tried Environment.TickCount but it has the same problem. I either get 0 or 16 in difference values.
It could be that the problem is the timers that I am using, but it doesn't seem to make sense that it bounces around 0 and 16.
Here is a representative sample from the middle of the results. I think it illustrates the problem I am experiencing. I have max framerate at 300 by the way.
The behavior you seeing is to be expected since I am positive that DateTime.Now uses standard windows timer functions. Those functions still rely on timer interrupts (same as 20 years ago). Default interrupt rate for XP is 64 interrupts per second I believe.
It used to be 20 on win95, so things are much better now. If you were programming native application you would have access to high resolution timers (QueryPerformanceCounter) or you'd be able to set your own resolution for system timer up to 1ms. But since
we don't have access to native functions we must avoid relying on high precision timing in our applications. The way I am handling timing is by measuring time across multiple frames. Instead of measuring how long it takes to render one frame, you could measure
how many frames you render every second or half second and then inverse it to get time per frame.
I had the exact same idea this morning and rewrote my timer to measure the average time over 10 frames. It works much better than what I used to have. Still it would be nice to see this in SL4?
DDtMM
Member
90 Points
103 Posts
Lack of resolution in DateTime.Ticks
Aug 21, 2009 01:46 AM | LINK
Is anybody else getting bummed by the poor resolution in DateTime.Ticks. I mean I'm getting a difference of 0 ticks accross multiple frames which is causing me to lock down my frame rates for one.
Has anybody found a way around this?
mrjvdveen
Contributor
2285 Points
426 Posts
Re: Lack of resolution in DateTime.Ticks
Aug 21, 2009 07:45 AM | LINK
The API documentation for the DateTime class specifies that a Tick is 0.0001 seconds. On a 2GHz CPU (single core) a CPU instruction occurs every 0.0000000005 seconds. That means a single Tick can contain 200000 CPU instructions. That seems like it's not suitable timing short operations.
You could try with Miliseconds (and seconds). This would give you more acuracy. A milisecond in the above example only contains 2000 CPU instructions and may give you measurable results.
It would be helpful if you elaborate on what you're trying to achieve.
HTH.
Please mark a post as answer if it answers your question.
Visit my blog: http://jvdveen.blogspot.com
DDtMM
Member
90 Points
103 Posts
Re: Lack of resolution in DateTime.Ticks
Aug 21, 2009 02:36 PM | LINK
So wait! A millisecond has about 100 times better resolution than a Tick? Well I just assumed that Tick would be the lowest resolution. That would solve my problem, thanks.
Mog Liang -...
All-Star
21645 Points
2132 Posts
Microsoft
Re: Lack of resolution in DateTime.Ticks
Aug 25, 2009 09:52 AM | LINK
Hi DDtMM,
Did you fix the problem?
actually, according to the msdn document
Thanks,
Microsoft Online Community Support
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
mrjvdveen
Contributor
2285 Points
426 Posts
Re: Lack of resolution in DateTime.Ticks
Aug 25, 2009 11:21 AM | LINK
Mmmm, must have misread the document. [:$] Sorry about that.
Please mark a post as answer if it answers your question.
Visit my blog: http://jvdveen.blogspot.com
DDtMM
Member
90 Points
103 Posts
Re: Lack of resolution in DateTime.Ticks
Aug 25, 2009 03:13 PM | LINK
I realize now I didn't phrase the question correctly. THe problem is the resolution of DateTime.Now. I don't have that exact numbers on hand but the interval is something like 15 milliseconds. That's the bummer. I need something more accurate than what I'm getting: I need a high precision timer.
I tried changing from ticks to milliseconds but it didn't help the resolution problem.
I tried Environment.TickCount but it has the same problem. I either get 0 or 16 in difference values.
It could be that the problem is the timers that I am using, but it doesn't seem to make sense that it bounces around 0 and 16.
Mog Liang -...
All-Star
21645 Points
2132 Posts
Microsoft
Re: Lack of resolution in DateTime.Ticks
Aug 26, 2009 03:31 AM | LINK
Hi,
How do you get the interval? By default, there are 60 frames per second in silverlight, which means it's 15-16 millseconds between frames.
If we calculate interval in CompositionTarget.Rendering event, then we would get 15-16 millseconds timespan.
To be more accurate, we could use TimeSpan.Ticks property, check this sample
Microsoft Online Community Support
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
DDtMM
Member
90 Points
103 Posts
Re: Lack of resolution in DateTime.Ticks
Aug 26, 2009 12:48 PM | LINK
Here is a representative sample from the middle of the results. I think it illustrates the problem I am experiencing. I have max framerate at 300 by the way.
datetime.now.ticks:156250environment.tickscount16datetime.now.ticks:0environment.tickscount0
datetime.now.ticks:0environment.tickscount0
datetime.now.ticks:156250environment.tickscount16
datetime.now.ticks:0environment.tickscount0
datetime.now.ticks:312500environment.tickscount31
datetime.now.ticks:156250environment.tickscount16
datetime.now.ticks:156250environment.tickscount15
datetime.now.ticks:156250environment.tickscount16
datetime.now.ticks:156250environment.tickscount15
datetime.now.ticks:156250environment.tickscount16
datetime.now.ticks:156250environment.tickscount16
datetime.now.ticks:156250environment.tickscount15
datetime.now.ticks:156250environment.tickscount16
datetime.now.ticks:156250environment.tickscount16
datetime.now.ticks:156250environment.tickscount15
datetime.now.ticks:156250environment.tickscount16
datetime.now.ticks:156250environment.tickscount15
datetime.now.ticks:156250environment.tickscount16
datetime.now.ticks:156250environment.tickscount16
datetime.now.ticks:0environment.tickscount0
datetime.now.ticks:156250environment.tickscount15
datetime.now.ticks:156250environment.tickscount16
datetime.now.ticks:156250environment.tickscount16
datetime.now.ticks:156250environment.tickscount15
datetime.now.ticks:156250environment.tickscount16
sl.ayer
Participant
1693 Points
288 Posts
Re: Lack of resolution in DateTime.Ticks
Aug 26, 2009 10:45 PM | LINK
The behavior you seeing is to be expected since I am positive that DateTime.Now uses standard windows timer functions. Those functions still rely on timer interrupts (same as 20 years ago). Default interrupt rate for XP is 64 interrupts per second I believe. It used to be 20 on win95, so things are much better now. If you were programming native application you would have access to high resolution timers (QueryPerformanceCounter) or you'd be able to set your own resolution for system timer up to 1ms. But since we don't have access to native functions we must avoid relying on high precision timing in our applications. The way I am handling timing is by measuring time across multiple frames. Instead of measuring how long it takes to render one frame, you could measure how many frames you render every second or half second and then inverse it to get time per frame.
DDtMM
Member
90 Points
103 Posts
Re: Lack of resolution in DateTime.Ticks
Aug 26, 2009 10:52 PM | LINK
I had the exact same idea this morning and rewrote my timer to measure the average time over 10 frames. It works much better than what I used to have. Still it would be nice to see this in SL4?