The meaning of the time delta values is unnecessarily complicated

[joshuaehill]

The default hardware timer on most (non-x86) platforms is constructed using the results of the clock_gettime function. In such cases, the high-order 32-bits is a number of seconds, and the low-order 32 bits is a number of nanoseconds since the start of the current second.

The meaning of the difference of two such 64-bit values is opaque whenever samples happen to include a "nanosecond wrap around", and the lower order 32-bits of the older value is greater than the lower order 32 bits of the newer time value. In such a situation, the standard borrowing behavior of subtraction yields an artificially large value apparent value.

As it turns out, such values can be detected and unambiguously converted into a nanosecond count, but it seems much easier to simply make the internal format of the time sample in this case into a simple number of nanoseconds since the UNIX time epoch, at which point the deltas are also always a number of nanoseconds. As an additional benefit, this makes the interpretation of the meaning of delta2 and delta3 more natural, as well.

[joshuaehill]

As an aside, Theseus has a tool for rendering deltas of this form into nanoseconds. This gives a good view into the sort of processing that a tester needs to do in order to convert deltas of this form to nanosecond deltas.

[smuellerDD]

Am Sonntag, dem 07.03.2021 um 15:50 -0800 schrieb Joshua E. Hill:

The default hardware timer on most (non-x86) platforms is constructed using the results of the clock_gettime function. In such cases, the high-order 32- bits is a number of seconds, and the low-order 32 bits is a number of nanoseconds since the start of the current second. The meaning of the difference of two such 64-bit values is opaque whenever samples happen to include a "nanosecond wrap around", and the lower order 32-bits of the older value is greater than the lower order 32 bits of the newer time value. In such a situation, the standard borrowing behavior of subtraction yields an artificially large value apparent value.

Agreed.

As it turns out, such values can be detected, and so all values can be converted into an unambiguous nanosecond count, but it seems much easier to simply make the internal format of the delta a simple number of nanoseconds since the UNIX time epoch, at which point the deltas are always a number of nanoseconds. As an additional benefit, this makes the interpretation of the meaning of delta2 and delta3 more natural, as well.

The Jitter RNG does not rely on the presence of an exact time stamp. All it needs is the presence of a fast running counter with high resolution. Commonly a high-resolution timer provides this concept. But a different approach is entirely possible as it was introduced with the "internal timer" which is merely a counter that is incremented very fast and is large enough for the Jitter RNG to work with. That said, the Jitter RNG calculates the delta (i.e. the first discrete derivative) of two adjacent absolute counter values / time stamp values. The Jitter RNG does not care whether the resulting value is truly a nanosecond timer or whether a wrap-around is detected. All that is important is that the variations of the deltas (i.e. the second discrete derivative) fluctuates in a non-predictable fashion. Thanks Stephan

[joshuaehill]

I understand that this doesn't actually effect the operation of the library, but it does complicate evaluation of it. The necessary change to uncomplicate the evaluation is both easy, and it likely has the same general performance. My proposal is simply to alter jitterentropy-base-user.h so that

                tmp = (uint32_t)time.tv_sec;
                tmp = tmp << 32;
                tmp = tmp | (uint32_t)time.tv_nsec;

becomes

                tmp = ((uint64_t)time.tv_sec & 0xFFFFFFFF) * 1000000000UL;
                tmp = tmp + (uint64_t)time.tv_nsec;

[smuellerDD]

Ok, if this helps your assessment, I see no issue in applying it.

Applied. Thanks.