10-01-2010 09:02 AM
can someone tell me the best way to tell elapsed time in seconds.would it be option a or b?
In option b I do not understand output elapsed time? Can someone explain it too me please
Solved! Go to Solution.
10-01-2010 09:17 AM
Hm, let me think: Time goes "forward" therefore the time should "increase". So it makes sense to take the second timestamp and subtract the first one, not the other way round, does it?
I think this explains your surprise in approach b.
You should take a) if you need time elapsed for short times, b) if you have longer times (hours/days and more).
hope this helps,
Norbert
10-01-2010 09:29 AM
Ah, messed up with the order:
a) for long times
b) for short.....
Sorry about the confusion,
Norbert
10-01-2010 09:32 AM
Hello,
The difference between your option (a) and (b) is as below:
(a) you are geting time stamp of current time before and after of process and substract it to find elapsed time in between.. I will suggest you to convert time stamp data type to double before substracting..
(b) you are geting millisecond from tick count timer before and after of process and substract it to find elapsed time in between.. and in last multiplication is by 1000 to convert it to second..
In my opinion I will prefer (a)
Thanks
HS
10-01-2010 09:37 AM
Hey Nobert,
I was confused after seeing your first reply.. certainly if you start millisecond timer for long period result will be too long ..
Yeah if your process is too short then millisecond timer is good option ..
Thanks
HS
10-01-2010 09:46 AM
thanks this clear things up..
10-01-2010 10:20 AM
Nobody mentioned what "long" and "short" means here. 😄
The tick count is a U32 and is thus good for about 49 days before it rolls over. Any time difference below ~49 days will be accurate.
Taking a tick count is very efficient. It is best to display the result as milliseconds, no division needed. I love integers! 😉
Resolution is milliseconds, which is sufficient on Windows (shorter times are probably meaningless). Still there is also a version available that has much better resolution. Substitute if desired.
The time stamp carries more baggage (more complex datatype) and is directly in seconds. It is probably overkill for benchmarking.
Considering average system up-times (monthly reboots due to system updates, etc). The plain tick count is sufficient for virtually any timing task you need.
10-01-2010 10:42 AM
Hey altenbach,
I certainly agree with you and will explain your days calculation based on data type for information to others who need it :
U32 is Long Unsigned Integer having 32 bits of storage so maximum value it can have will be 4294967295..
so tick count (ms) can count upto 4294967295 milliseconds so converting this millisecond into days will be approximate 49.7 days .. safer side 49 days ..
Regards
HS
03-14-2011 02:57 PM
Hi altenbach,
I can see how you figure the tick count is good for 49 days, but when does this tick count start? Is it when the application first launches? Just curious, because if it is at some arbitrary time, then one will never know when the time will rollover. I have alway been hesitant to use this VI to calculate elapsed time because I thought that there would be no way to tell of when it is going to rollover, although I knew that once it did I was good for ~49 days. But just the fact that it could rollover at any moment made me avoid using it. I am hoping to you will be able to shed some light on this VI so that I can use it for elapsed time. Thanks for your time
03-14-2011 03:18 PM
I believe the msec tick count starts when the PC is booted.
-AK2DM