First, why are we adjusting the clock rate?
The CPU clock read via RDTSC (x86_64) derives from a fairly cheap oscillator which drifts (changes frequency) over time. Integrated over a respectable period of time, the resulting frequency errors lead to errors in policy enforcement. “6am to midnight” eventually means 6:15 am to 12:15 am if a putative clock rate of 4gGz is actually 3.995 gHz and we don’t correct the clock rate. See also “show clock verbose” The algorithm in time.c uses the system’s idea of “now” to derive the current CPU frequency, uses exponential smoothing to slew vpp’s idea of the CPU frequency. If a particular candidate rate sample jumps by too much, we ignore it and print a message. It wouldn’t be completely unreasonable to suppress the messages since they end up in syslog. FWIW... Dave From: Prasanth G <pgajarampa...@gmail.com> Sent: Friday, September 17, 2021 2:02 AM To: Dave Barach <v...@barachs.net> Cc: lgudi...@ciena.com; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Rejecting large frequency change Hi Dave, I am seeing this with VPP 21.01. Yes NTP is on and the print starts filling up the log. I see fixes made in this area in time.h and time.c addressing the algorithm. Questions: 1. "Vpp has to continuously adjust its idea of the current clock rate" -- How long could this be? Seconds, minutes or hours? 2. Is the warning suggesting a problem (with few expected failures around this event that rely on timers) or information displayed to the user that the clock rate is being adjusted? What is the outcome expected with entities of the system relying on timers whenever this happens? Thanks, Prashant On Fri, Aug 6, 2021 at 5:08 AM Dave Barach <v...@barachs.net <mailto:v...@barachs.net> > wrote: Which version of vpp are you running? Which Linux kernel is involved? What kind of hardware? Lastly, did you just start running NTP on the system? Yes, of course it means something: every N seconds, vpp calculates its idea of the current clock frequency by asking the kernel [via the clock_gettime ( CLOCK_REALTIME) syscall] what time it is. It asks the CPU for the current clock tick [on x86_64, via “RDTSC”]. Some arithmetic later, we have a new clock rate for the processor. We can’t simply believe the new clock rate, because e.g. NTP synchronization can change the kernel reference clock by minutes or hours. Every timer in the system breaks catastrophically if vpp’s idea of the CPU clock rate is seriously wrong. After a suitable number of experiments, we decided to reject frequency changes of more than one percent. Vpp has to continuously adjust its idea of the current clock rate, otherwise long-running timers won’t be accurate enough. See .../src/vppinfra/time.c:clib_time_verify_frequency() and .../src/vppinfra/time.h:clib_time_now_internal() for details. From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > On Behalf Of Gudimetla, Leela Sankar via lists.fd.io <http://lists.fd.io> Sent: Thursday, August 5, 2021 11:31 PM To: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> Subject: [vpp-dev] Rejecting large frequency change Hello, We have started seeing the below warning message coming continuously. Traffic is running on several vhost-ports and physical ports. These messages are coming even after a restart with a slow rate. VPP clib_warning: clib_time_verify_frequency:248: Rejecting large frequency change of 1.01% Does this mean something ? Thanks, Leela sankar
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20157): https://lists.fd.io/g/vpp-dev/message/20157 Mute This Topic: https://lists.fd.io/mt/84701132/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
