I beg to differ, in several ways.
First, let's stipulate that systems rarely stay up for one year, let alone five
years. I do extensive long-duration vpp soak-testing, but at that I don't test
beyond 6 months. I'm looking for data plane stability, and for memory leaks.
When we chose f64 timing over 15 years ago, we believed that a 53-bit f64
mantissas were accurate enough as a practical matter. I haven't seen anything
to make me change my mind about that.
Two independent system clocks do very well to synchronize to an NTP reference
at better-than-1ms accuracy. Protocol timers are at the millisecond level. TCP
typically uses a 100ms clock tick. An uncertainty of 7ns after one year is not
a significant issue IMO.
If you look at clib_time_now_internal(...), you won't find any floating-point
division. We multiply cpu ticks by seconds_per_clock - computed very
infrequently in clib_time_verify_frequency(...) - and add an FP offset. I doubt
that gcc manages to generate a multiply-add instruction - I haven't looked -
but it certainly could do that.
The "rdtsc" instruction is more expensive than the arithmetic required to
process its output.
For these reasons, I wouldn't bother hand-rolling a scheme to solve the f64
53-bit mantissa non-problem.
Just to ask, what kind of periodic timer are you building which seems to demand
better than 10ns accuracy? Under load, the vpp graph dispatch cycle time is a
few hundred microseconds. Unless these timers are purely intramural - within a
single node dispatch function invocation - external forces will conspire to
make ultra-precise timing less than spectacularly useful.
HTH... Dave
-----Original Message-----
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Christian Hopps
Sent: Tuesday, May 28, 2019 9:49 AM
To: Dave Barach (dbarach) <dbar...@cisco.com>
Cc: Prashant Upadhyaya <praupadhy...@gmail.com>; vpp-dev@lists.fd.io
Subject: f64 vs u64 time values [Re: [vpp-dev] Regarding vlib_time_now]
I've been wondering how much thought/measurements went into choosing
floating-point vs integers for tracking/managing time in VPP?
Intuitively I worry that the floating-point operations are more costly than
integer and I worry about the overhead of vlib doing conversions (including
divisions) all the time from the integer CPU clock value.
Also I worry about precision. I just did a back of the napkin calculations for
a 4GHz CPU, and it will start losing precision after 26 days uptime (2^53 / 4e9
/ 3600 / 24 == 26.06...). So after 1 year uptime the precision is reduced to
7ns and that value then doubles (halves the precision) each year after.
For now I am using clib_cpu_time_now() and local u64 values to calculate
periodic timer stuff within my packet processing routine. I wonder how much
more expensive using vlib and the inherent divisions for converting to f64s
here would be?
Thanks,
Chris.
Dave Barach via Lists.Fd.Io <dbarach=cisco....@lists.fd.io> writes:
> Vlib_time_now(...) works reasonably hard to return the same time on all
> worker threads:
>
> /*
> * Note when we let go of the barrier.
> * Workers can use this to derive a reasonably accurate
> * time offset. See vlib_time_now(...)
> */
> vm->time_last_barrier_release = vlib_time_now (vm);
>
>
> always_inline f64
> vlib_time_now (vlib_main_t * vm)
> {
> return clib_time_now (&vm->clib_time) + vm->time_offset; }
>
> /*
> * Recompute the offset from thread-0 time.
> * Note that vlib_time_now adds vm->time_offset, so
> * clear it first. Save the resulting idea of "now", to
> * see how well we're doing. See show_clock_command_fn(...)
> */
> {
> f64 now;
> vm->time_offset = 0.0;
> now = vlib_time_now (vm);
> vm->time_offset = vlib_global_main.time_last_barrier_release - now;
> vm->time_last_barrier_release = vlib_time_now (vm);
> }
>
> See also the "show clock" command.
>
> There should be no need to re-solve this problem yourself.
>
> Thanks...
>
> -----Original Message-----
> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Prashant
> Upadhyaya
> Sent: Tuesday, May 28, 2019 7:48 AM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Regarding vlib_time_now
>
> Hi,
>
> I suppose vlib_time_now can return different times on different workers.
> If I want to have some global notion of time between workers (and possibly
> main thread), what would be the best way, please suggest.
>
> I thought of passing the vm of main thread for the above usecase, from
> workers, while calling vlib_time_now but that seems like a
> spectacularly bad idea as the code inside modifies some variables
> related to time inside the vm (and therefore looks like one must pass
> the correct vm from the correct thread)
>
> Is it ok to use a combination of os_cpu_clock_frequency() and
> clib_cpu_time_now ?
>
> Regards
> -Prashant
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#13159):
> https://lists.fd.io/g/vpp-dev/message/13159
> Mute This Topic: https://lists.fd.io/mt/31820577/1826170
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [cho...@chopps.org]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13163): https://lists.fd.io/g/vpp-dev/message/13163
Mute This Topic: https://lists.fd.io/mt/31821738/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
