On Sun, Aug 27, 2017 at 09:45:52PM -0700, Mike Larkin wrote:
> On Mon, Aug 28, 2017 at 08:02:35AM +0800, Adam Steen wrote:
> > On Fri, Aug 25, 2017 at 12:43:44PM +0200, Mike Belopuhov wrote:
> > > On Fri, Aug 25, 2017 at 00:40 -0700, Mike Larkin wrote:
> > > > On Thu, Aug 24, 2017 at 12:39:33PM +0800, Adam Steen wrote:
> > > > > On Thu, Aug 24, 2017 at 2:35 AM, Mike Larkin <mlar...@azathoth.net> 
> > > > > wrote:
> > > > > > On Wed, Aug 23, 2017 at 09:29:15PM +0800, Adam Steen wrote:
> > > > > >>
> > > > > >> Thank you Mike on the feedback on the last patch, please see the 
> > > > > >> diff
> > > > > >> below, update with your input and style(9)
> > > > > >>
> > > > > >> I have continued to use tsc as my timecounter and 
> > > > > >> /var/db/ntpd.driff
> > > > > >> has stayed under 10.
> > > > > >>
> > > > > >> cat /var/db/ntpd.drift
> > > > > >> 6.665
> > > > > >>
> > > > > >> ntpctl -s all
> > > > > >> 4/4 peers valid, constraint offset -1s, clock synced, stratum 3
> > > > > >>
> > > > > >> peer
> > > > > >>    wt tl st  next  poll          offset       delay      jitter
> > > > > >> 144.48.166.166 from pool pool.ntp.org
> > > > > >>     1 10  2    4s   32s        -3.159ms    87.723ms    10.389ms
> > > > > >> 13.55.50.68 from pool pool.ntp.org
> > > > > >>     1 10  3   11s   32s        -3.433ms    86.053ms    18.095ms
> > > > > >> 14.202.204.182 from pool pool.ntp.org
> > > > > >>     1 10  1   14s   32s         1.486ms    86.545ms    16.483ms
> > > > > >> 27.124.125.250 from pool pool.ntp.org
> > > > > >>  *  1 10  2   12s   30s       -10.275ms    54.156ms    70.389ms
> > > > > >>
> > > > > >> Cheers
> > > > > >> Adam
> > > > > >
> > > > > > IIRC you have an x220, right?
> > > > > >
> > > > > > If so, could you try letting the clock run for a bit (while using 
> > > > > > tsc
> > > > > > timecounter selection) after apm -L to drop the speed? (make sure
> > > > > > apm shows that it dropped).
> > > > > >
> > > > > > Even though my x230 supposedly has a constant/invar TSC (according 
> > > > > > to
> > > > > > cpuid), the TSC drops from 2.5GHz to 1.2GHz when apm -L runs, which
> > > > > > causes time to run too slowly when tsc is selected there.
> > > > > >
> > > > > > -ml
> > > > > >
> > > > >
> > > > > Yes, x220
> > > > > (bios: LENOVO version "8DET69WW (1.39 )" date 07/18/2013)
> > > > > (cpu: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz)
> > > > >
> > > > > I took some measurements to before starting the test.
> > > > >
> > > > > note: the laptop has been up for a few days with apm -A set via 
> > > > > rc.conf.local
> > > > > and sysctl kern.timecounter.hardware as tsc via sysctl.conf and mostly
> > > > > idle.
> > > > >
> > > > > cat /var/db/ntpd.drift
> > > > > 6.459
> > > > >
> > > > > apm -v
> > > > > Battery state: high, 100% remaining, unknown life estimate
> > > > > A/C adapter state: connected
> > > > > Performance adjustment mode: auto (800 MHz)
> > > > >
> > > > > 6 hours ago i ran apm -L, verified it was running slowly (800 MHz),
> > > > > and got the following results
> > > > >
> > > > > The clock appears correct (comparing to other computers)
> > > > >
> > > > > apm -v
> > > > > Battery state: high, 100% remaining, unknown life estimate
> > > > > A/C adapter state: connected
> > > > > Performance adjustment mode: manual (800 MHz)
> > > > >
> > > > > cat /var/db/ntpd.drift
> > > > > 6.385
> > > > >
> > > > > ntpctl -s all
> > > > > 4/4 peers valid, constraint offset 0s, clock synced, stratum 4
> > > > >
> > > > > peer
> > > > >    wt tl st  next  poll          offset       delay      jitter
> > > > > 203.23.237.200 from pool pool.ntp.org
> > > > >     1 10  2  153s 1505s       -25.546ms    73.450ms     2.644ms
> > > > > 203.114.73.24 from pool pool.ntp.org
> > > > >     1 10  2  253s 1560s        -1.042ms    75.133ms     0.752ms
> > > > > 192.189.54.33 from pool pool.ntp.org
> > > > >  *  1 10  2  204s 1558s        31.644ms    70.910ms     3.388ms
> > > > > 54.252.165.245 from pool pool.ntp.org
> > > > >     1 10  2  238s 1518s         0.146ms    73.005ms     2.025ms
> > > > >
> > > > > I will leave the laptop in lower power mode over the weekend and see
> > > > > what happens.
> > > > >
> > > >
> > > > No need, I think you've convinced me that it works :)
> > > 
> > > But does it actually work on x230 as well?  I'm surprised to learn
> > > that you've observed TSC frequency change on Ivy Bridge.  I was
> > > under impression that everything since at least Sandy Bridge (x220)
> > > has constant and invariant TSC as advertised.
> > > 
> > > Adam, I've readjusted and simplified your diff a bit.  The biggest
> > > change is that we can select the reference tc based on it's quality
> > > so there's no need to have acpitimer and acpihpet specific functions
> > > and variables.
> > > 
> > > There's one big thing missing here: increasing the timecounter
> > > quality so that OS can pick it.  Something like this:
> > > 
> > > https://github.com/mbelop/src/commit/99d6ef3ae95bbd8ea93c27e0425eb65e5a3359a1
> > > 
> > > I'd say we should try getting this in after 6.3 unlock unless there
> > > are objections.  Further cleanup and testing is welcome of course.
> > > 
> > 
> > Hi all
> > 
> > I wanted to post the complicated patch, along with Mike's qaulity
> > changes for completeness sake, see the diff below.
> > 
> > I have been running this since Saturday morning with no
> > problems.
> > 
> > Cheers
> > Adam
> > 
> 
> This diff works fine on the x230. And although there is no hpet inside
> vmm/vmd, if you pick tsc anyway, it seems to have less time drift than
> the 8254/PIT. So, that's good. It's not perfect but it's better.
> 
> mikeb, do you want to get this in? the diff reads ok to me.
> 
> -ml
> 

Meh didn't read your earlier comments. Yes, after unlock is better.

-ml

Reply via email to