On Tue, Oct 17, 2017 at 20:11 +0800, Adam Steen 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). > My original code was loosely base on the links you gave me in my inital thread > about a tsc based timer. [0] > > > Any particular reason you've picked the > > minimum frequency out of all? > > I pick the minimum mostly due to the lines 773-775 [1] and line 834 [2] > of tsc.c in the linux kernel and it was cleaner code than doing an average. > > > Should we consider increasing the > > threshold as well? > > Linux uses a 10% leeway [3], either side of the expected value. I think that, > increasing the threadhold would be worth testing, i didn't play with the > figure > much, as it seemed to just work for me. > 10% would be quite a bit more than 20 or 50.. > Or do we need todo something similar to [4], but adapted to our code. > This would just bump the delay 5 times, right? Or do you think it might be more than that? > /* > * Check whether PIT failed more than once. This > * happens in virtualized environments. We need to > * give the virtual PC a slightly longer timeframe for > * the HPET/PMTIMER to make the result precise. > */ > > Please let me know if you would like me to look into and test > somethings further. > > Adam > > [0] https://marc.info/?l=openbsd-misc&m=150148792804747&w=2 > [1] > http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L773 > [2] > http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L834 > [3] > http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L841 > [4] > http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L852 >
