Dave Barach (dbarach) <[email protected]> writes:
I beg to differ, in several ways.
Actually, I was just hoping to get some of the info you give below to counter my worries. Not, necessarily to disagree with the choice. :)
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.
This; however, I can't agree to stipulate. There are plenty of dedicated use devices that one should expect to stay up for more than a year. My mail server is much more complex than a dedicated-use network device might be, and it has regularly had greater than one year uptimes over the last couple decades. But what you're saying below sort of makes this point of disagreement unimportant.
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.
For protocols using millisecond timing, yes.
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.
Your right, I had noticed it was multiplication by a fraction originally, and then converted it into division in my memory. :)
The "rdtsc" instruction is more expensive than the arithmetic required to process its output.
I must get some savings while processing packets by not having to access/update the time value in vlib_main though, right?
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.
Paced tunnel packets on high speed links. So timing considerations -- a 10GHz link can send a 1514 MTU (1548B) Ethernet frame every ~1230ns, a 40GHz link every ~308ns, and a 100GHz link every ~123ns. Probably can't get all the way to the 100GHz performance right now, but I want to get as close as I can. :) Thanks, Chris.
HTH... Dave -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Christian Hopps Sent: Tuesday, May 28, 2019 9:49 AM To: Dave Barach (dbarach) <[email protected]> Cc: Prashant Upadhyaya <[email protected]>; [email protected] 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 <[email protected]> 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: [email protected] <[email protected]> On Behalf Of Prashant Upadhyaya Sent: Tuesday, May 28, 2019 7:48 AM To: [email protected] 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: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
signature.asc
Description: PGP signature
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13164): https://lists.fd.io/g/vpp-dev/message/13164 Mute This Topic: https://lists.fd.io/mt/31821738/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
