Timestamp Behavior

[mwebster]

Greetings,

I've been playing around with the timestamp recently and I'd like to throw out some of my findings to see if they're expected behavior or not.

One issue is that if you call Get Date/Time in Seconds, the minimum interval is ~1ms. Now this is much better than ~2009 where the minimum interval was ~14ms, if I recall correctly. Meaning, even if you call Get Date/Time in Seconds a million times in a second, you only get ~1000 updates.

The other oddities involve converting to double or extended and from double/extended back to timestamp. It seems that when converting to double, at least with a current day timestamp, your resolution is cut off at ~5e-7 (0.5us). This is expected given that you only have so many signficant digits in a double and a lot of them are eaten up by the ~3.4 billion seconds that have elapsed since 7:00PM 12-31-1903 (any story behind that start date, btw?) However, when you convert to extended, you get that same double-level truncation, no extra resolution is gained.

Now, when you convert from a double to a timestamp, you have that same 0.5us step size. When you convert an extended to a timestamp, you get an improved resolution of 2e-10 (0.2ns). However, the internal representation of the timestamp (which, as far as I know, is a 128-bit floating point) allows down to ~5E-20 (this is all modern era with 3.4 billion to the left of the decimal).

One other oddity, if you convert a timestamp to a date-time record instead of an extended number (which gets treated like a double as noted above), you once again get the 2e-10 step size in the fractional second field.

I've tried a few different things to "crack the nut" on a timestamp like flattening to string or changing to variant and back to extended, but I've been unable to figure out how to access the full resolution except via the control face itself.

Attached is one of my experimentation VI's. You can vary the increment size and see where the arrays actually start recording changes.

Ah, one final thing I decided to try, if I take the difference of two time stamps, the resulting double will resolve a difference all the way down to 5e-20, which is about the step size I figured the internal representation would hold.

I would like to be able to uncover the full resolution of the timestamp for various timing functions and circular buffer lookups, but I would like to be able to resolve the math down to, say 100MHz or 1e-8. I guess I can work around this using the fractional part of the date-time record, but it would be nice to be able to just use the timestamps directly without a bunch of intermediary functions.

Time Tester.viFetching info...

[ShaunR]

Some things perhaps you didn't know about the timestamp that may shed some light.

In 2009 it is also 1ms. The 14ms you are talking about is probably that you were using Windows XP where the timeslice was about 15 ms (windows 2000 was ~10ms). .

LabVIEW timestamps are 12 byte (96 bit not 128). The upper 4 bytes are not used and are always zero.

Edited September 28, 2012 by ShaunR

[Phillip Brooks]

Have you seen this post on the NI forums? High Resolution Relative Seconds

It was reported as having an open loop resolution of ~ 1.2u sec

W/R/T resolution of a timestamp, this is documented here: http://www.ni.com/white-paper/7900/en

You might try typcasting the timestamps as arrays of U64 and then performing addition and subtraction on those.

After performing the integer operations, the U64 that represents the fractional seconds can be converted back by multiplying it by 2^-64

http://forums.ni.com/t5/LabVIEW/Unable-to-replicate-frations-of-seconds-when-reading-a-timestamp/m-p/2116706#M687792

Edited September 28, 2012 by Phillip Brooks

[mwebster]

That High Resolution Relative Seconds looks like it could be just what the doctor ordered, but the whole number value appears to be linked, at least on my system, to the millisecond timer. I wonder what it's behavior is at rollover (I'm trying to move away from a millisecond timer based circular buffer now right now because of the headache in handling rollovers).

[mje]

  On 9/28/2012 at 5:20 PM, Phillip Brooks said:

You might try typcasting the timestamps as arrays of U64 and then performing addition and subtraction on those.

Technically you ought to typecast it to a cluster of {I64, U64}. The whole seconds element is a signed value allowing for dates prior to the epoch. The fractional seconds though is indeed an unsigned integer.

Indeed not all of the precision of the U64 is used, however this is likely a function of the timing source resolution not the format itself. My virtual machine here only reports significance in the highest three bytes, though I seem to remember my main desktop reported four bytes of resolution...

Phillip is correct in that the format is technically capable of a time resolution of 2^-64 = 5.4 x 10^-20 s = 54 zs. You'll be hard-pressed to find hardware that can pull off precision like that for quite some time.

[asbo]

  On 9/28/2012 at 3:30 PM, ShaunR said:

LabVIEW timestamps are 12 byte (96 bit not 128). The upper 4 bytes are not used and are always zero.

I've never looked at the actual bitwise representation of a timestamp, how sure are you of this? I've read the whitepaper Phillip linked before and that pretty much cemented a 16-byte representation. Their interpretation examples seem to contest what you're saying.

[ShaunR]

  On 9/28/2012 at 9:50 PM, asbo said:

I've never looked at the actual bitwise representation of a timestamp, how sure are you of this? I've read the whitepaper Phillip linked before and that pretty much cemented a 16-byte representation. Their interpretation examples seem to contest what you're saying.

Hmmm. Not sure where I got that from. Certainly in the LabVIEW Timestamp Whitepaper I just found it shows it is indeed 128 bit so I;m obviously wrong. But I have recollections of it being 12 bytes as it was one of the improvements (adding a timestamp) to the Transport.lib (which after some research I made 12 bytes). Since then it's just stuck as one of those anomalies to my expectations since 12 is a bizarre number.

[Ton Plomp]

  On 9/28/2012 at 2:44 PM, mwebster said:

One issue is that if you call Get Date/Time in Seconds, the minimum interval is ~1ms. Now this is much better than ~2009 where the minimum interval was ~14ms, if I recall correctly. Meaning, even if you call Get Date/Time in Seconds a million times in a second, you only get ~1000 updates.

The 14 ms is an OS limitation (for WinXP that has an internal timer that has an update rate just above 50 Hz).

If I use Get Current Time is has a resolution of 1 uSec. When converting this to double you'll have rounding issues limiting you to 0.5 uSec.

Technically a timestamp can store much greater resolution. If you go subtracting almost similar timestamps (like your TS1 and TS2) you'll better use Cluster substraction:

Ton

[asbo]

  On 9/28/2012 at 10:27 PM, ShaunR said:

Hmmm. Not sure where I got that from. Certainly in the LabVIEW Timestamp Whitepaper I just found it shows it is indeed 128 bit so I;m obviously wrong. But I have recollections of it being 12 bytes as it was one of the improvements (adding a timestamp) to the Transport.lib (which after some research I made 12 bytes). Since then it's just stuck as one of those anomalies to my expectations since 12 is a bizarre number.

I'd be interested to know more about that, if not only out of academic interest.

  On 9/29/2012 at 9:45 AM, Ton Plomp said:

Technically a timestamp can store much greater resolution. If you go subtracting almost similar timestamps (like your TS1 and TS2) you'll better use Cluster substraction:

I assume if you cast back to a timestamp, you'll lose the benefit of that extra precision because it goes back to a formatted value?

[mwebster]

  On 9/29/2012 at 9:45 AM, Ton Plomp said:

The 14 ms is an OS limitation (for WinXP that has an internal timer that has an update rate just above 50 Hz).

If I use Get Current Time is has a resolution of 1 uSec. When converting this to double you'll have rounding issues limiting you to 0.5 uSec.

Technically a timestamp can store much greater resolution. If you go subtracting almost similar timestamps (like your TS1 and TS2) you'll better use Cluster substraction:

On Win7, I get ~1ms.

Also, for (very) closely spaced time stamps, you can subtract them directly and get the ~50 zeptoseconds. For further spaced ones your method would be preferable if you wanted the maximum resolution as the raw subtractions casts the result to a double.

I don't know why I didn't think to try a direct typecast. I completely forgot that primitive existed (almost every cast I do is when converting from variant or flattened string).

Asbo:

The full resolution is retained if you cast to a timestamp using the reverse method. The formatting is just a control/indicator property. You can set the number of displayed decimal places out to 20 to get the full range.

Of course, now I'm concerned about the year 292 billion problem...

[Yair]

  On 9/28/2012 at 2:44 PM, mwebster said:

...seconds that have elapsed since 7:00PM 12-31-1903 (any story behind that start date, btw?)

Yes. LV uses that epoch (which is actually the first midnight of 1904, UTC), because that's the time format the Mac used and LV was first developed on the Mac. My understanding was that the reason the Mac used that as an epoch was because it made leap year calculations very simple - just check for divisibility by four. Years divisible by 100 are excluded in this calculation, which is why it starts from 1904 (no need to handle this for positive dates). 2000 was also divisible by 100, but it's also divisible by 400, so it was a leap year and the next year that would break the code was 2100. I'm assuming whoever designed the code decided to sacrifice past and future years for the sake of practicality.