I encountered the same problem on the VPP16.09 version. I also saw another
question on the link:
https://jira.fd.io/browse/VPP-153?jql=text%20~%20%22timing_wheel_insert%22%20ORDER%20BY%20lastViewed%20ASC
Someone gave the answer, but did not understand why it was done? And why is
this happening? What is the nature of the problem? Has the problem been
resolved in VPP19.01?
The implementation of VPP16.09 is as follows:
void clib_time_verify_frequency (clib_time_t * c)
{
f64 now_reference = unix_time_now ();
f64 dtr = now_reference - c->last_verify_reference_time;
f64 dtr_max;
u64 dtc = c->last_cpu_time - c->last_verify_cpu_time;
f64 round_units = 100e5;
c->last_verify_cpu_time = c->last_cpu_time;
c->last_verify_reference_time = now_reference;
/*
* Is the reported reference interval non-positive,
* or off by a factor of two - or 8 seconds - whichever is larger?
* Someone reset the clock behind our back.
*/
dtr_max = (f64)(2ULL<<c->log2_clocks_per_frequency_verify) /
(f64)(1ULL<<c->log2_clocks_per_second);
dtr_max = dtr_max > 8.0 ? dtr_max : 8.0;
if (dtr <= 0.0 || dtr > dtr_max)
{
c->log2_clocks_per_frequency_verify = c->log2_clocks_per_second;
return;
}
c->clocks_per_second = flt_round_nearest ((f64) dtc / (dtr * round_units)) *
round_units;
c->seconds_per_clock = 1 / c->clocks_per_second;
/* Double time between verifies; max at 64 secs ~ 1 minute. */
if (c->log2_clocks_per_frequency_verify < c->log2_clocks_per_second + 6)
c->log2_clocks_per_frequency_verify += 1;
}
The implementation of VPP18.01 is as follows:
clib_time_verify_frequency (clib_time_t * c)
{
f64 now_reference = unix_time_now ();
f64 dtr = now_reference - c->last_verify_reference_time;
f64 dtr_max;
u64 dtc = c->last_cpu_time - c->last_verify_cpu_time;
f64 new_clocks_per_second, delta;
c->last_verify_cpu_time = c->last_cpu_time;
c->last_verify_reference_time = now_reference;
/*
* Is the reported reference interval non-positive,
* or off by a factor of two - or 8 seconds - whichever is larger?
* Someone reset the clock behind our back.
*/
dtr_max = (f64) (2ULL << c->log2_clocks_per_frequency_verify) /
(f64) (1ULL << c->log2_clocks_per_second);
dtr_max = dtr_max > 8.0 ? dtr_max : 8.0;
if (dtr <= 0.0 || dtr > dtr_max)
{
c->log2_clocks_per_frequency_verify = c->log2_clocks_per_second;
return;
}
if (PREDICT_FALSE (c->round_to_units == 0.0))
{
f64 next_pow10, est_round_to_units;
/*
* Compute the first power of ten which is greater than
* 0.1% of the new clock rate. Save the result, and use it
* to round future results, so we don't end up calculating
* silly-looking clock rates.
*/
est_round_to_units = ((f64) dtc / dtr) * 0.001;
next_pow10 = ceil (log10 (est_round_to_units));
c->round_to_units = pow (10.0, next_pow10);
}
/*
* Reject large frequency changes, another consequence of
* system clock changes particularly with old kernels.
*/
new_clocks_per_second =
flt_round_nearest ((f64) dtc / (dtr * c->round_to_units))
* c->round_to_units;
delta = new_clocks_per_second - c->clocks_per_second;
if (delta < 0.0)
delta = -delta;
if (PREDICT_FALSE ((delta / c->clocks_per_second) > .01))
{
clib_warning ("Rejecting large frequency change of %.2f%%",
(delta / c->clocks_per_second) * 100.0);
c->log2_clocks_per_frequency_verify = c->log2_clocks_per_second;
return;
}
c->clocks_per_second =
flt_round_nearest ((f64) dtc / (dtr * c->round_to_units))
* c->round_to_units;
c->seconds_per_clock = 1 / c->clocks_per_second;
/* Double time between verifies; max at 64 secs ~ 1 minute. */
if (c->log2_clocks_per_frequency_verify < c->log2_clocks_per_second + 6)
c->log2_clocks_per_frequency_verify += 1;
}
Note:I don't understand the difference between the two, and whether such a
change will solve this problem?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11862): https://lists.fd.io/g/vpp-dev/message/11862
Mute This Topic: https://lists.fd.io/mt/10640607/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
