On Thu, Oct 19, 2017 at 08:25 -0400, Joe Gidi wrote: > >> 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". > Thanks, > > -- > > Joe Gidi > [email protected] > > "You cannot buy skill." -- Ross Seyfried >
