Discontinuous time jumps are bad, mkay? NTP doesn’t want to jump the clock, but will if you tell it to, or rather, if you allow it to, and it finds itself in a situation where that might be better than the alternative.
NTP *wants* to adjust your clock very, very gradually. This is called “slewing” the clock. But if your clock is WAAAY OFF, then adjusting it slowly could take a long time. Effectively “forever”. By default, if your clock is more than 600 sec ‘off’, NTP will jump the clock. You can disable this with ‘-x 0’ on the command line. Otherwise, the maximum possible slew rate for the clock is 500ppm Ref: http://doc.ntp.org/archives/4.2.8-series/clock/ "As a result, the clock can take 33 minutes to amortize each second the clock is outside the acceptable range. During this interval the clock will not be consistent with any other network clock and the system cannot be used for distributed applications that require correctly synchronized network time.” See also: http://doc.ntp.org/reflib/memos/memo96b.pdf http://doc.ntp.org/archives/4.2.8-series/debug/#large-delay-variations > On Sep 17, 2021, at 1:02 AM, Prashant Gajarampalli <pgajarampa...@gmail.com> > wrote: > > 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> 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 <vpp-dev@lists.fd.io> On Behalf Of Gudimetla, Leela > Sankar via lists.fd.io > Sent: Thursday, August 5, 2021 11:31 PM > To: 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 (#20154): https://lists.fd.io/g/vpp-dev/message/20154 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] -=-=-=-=-=-=-=-=-=-=-=-
