On Wed, Oct 18, 2017 at 12:08 AM, Mike Belopuhov <[email protected]> wrote: > 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?
Yes that is my understanding, it just bumps the delay. Adam > >> /* >> * 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 >>
