>> >> On Tue, Oct 17, 2017 at 7:43 PM, Mike Belopuhov <[email protected]> >> >> wrote: >> >> > >> >> > Looks like your acpitimer takes a bit too much to obtain the value >> >> > and exceeds the threshold that we've imposed. Adam, I'd like to >> >> > commit the diff below but unsure how many successes should we >> consider >> >> > before accepting the value. >> >> >> >> That is a very good question, i am am sorry i don't >> >> have any information on number of failed/successful attempts, so i >> can >> >> not >> >> offer any great insights. >> >> >> > >> > He had 0/3. I've decided to go for 2 out of 3 as a success for now, >> but >> > increased the threshold to 50. We'll see what drift values these >> systems >> > will be observing. >> > >> > Joe, could you please update tsc.c to rev1.3 and if tsc will be picked >> up >> > as a timecounter by the system (sysctl -n kern.timecounter.hardware) >> see >> > what clock drift your system is going to develop in about a day >> > (cat /var/db/ntpd.drift). >> >> Clock drift is at -16.829. Other amd64 boxes here are at -10.408 and >> -0.812. >> > > That's acceptable if it's not much worse than it was before... > Do you have the old number? You can switch to acpitimer and > run it for a day with "kern.timecounter.hardware=acpitimer0".
After a day with acpitimer0, drift is -15.565. Not a very big difference. Thanks, -- Joe Gidi [email protected] "You cannot buy skill." -- Ross Seyfried
