From: joshua.clayton@uniwest.com (Joshua Clayton)
To: linux-arm-kernel@lists.infradead.org
Subject: rtc test 2
Date: Wed, 18 Nov 2015 09:38:03 -0800 [thread overview]
Message-ID: <3458577.MLHbIx9t1o@jclayton-pc> (raw)
In-Reply-To: <564A1679.9070700@uniwest.com>
> On Monday, November 16, 2015 09:46:33 AM Steve Eagan wrote:
>
> I agree, setting to the opposite extreme is a good idea
>
> On Friday, November 13, 2015 03:45:56 PM Joshua Clayton wrote:
> > rtc on 109 was set to the maximum adjustment value 273420 parts per
> > billion.
> > synchronized at 3:39:00 pm Today.
> > I'll check it again on Monday to see how far it has drifted.
> > Monday November 16 at 7:42:00 on my PC clock, the rtc on109 reads 07:40:36
> >
> > My expectation was that the time would be ahead, instead it is 1 minute 24
> > seconds behind. Perhaps I misunderstand which way the adjustment pushes
> > the
> > clock?
> >
> > On the bright side, the effect is pronounced. It seemws to support the
> > idea
> > that it is doing something.
> >
> > Any thoughts on a value to try next? My first thought is to set to the
> > opposite extreme... Going ahead with that.
> >
> > OK then. Setting adjust to
> >
> > root at evi:~# cat /sys/class/rtc/rtc0/device/adjust
> > -277760
> > root at evi:~# cat /sys/class/rtc/rtc0/device/d
> > 0xc0
> >
> > Monday November 16 at 7:51:00 Clock syncronized to my PC clock.
Tested rtc this morning
November 18 7:45:00 AM, instrument 109 shows November 18 7:45:03
So the adjusment has made the clock fast. The adjustment is in the opposite direction previously thought.
3 seconds * 1 billion / 172440 seconds = 17397 parts per billion
I am going to try another setting:
if the setting -277760 yields 17397....
I'm kind of in a boggle.
-277760 + 17397 would be -260363... the closest available value is -260400
synchronized November 18 09:33:00
root at evi:~# cat /sys/class/rtc/rtc0/device/d
0xc4
root at evi:~# cat /sys/class/rtc/rtc0/device/adjust
-260400
Since my understanding of the math involved was upside down, I have little confidence in the above figures (except the empirical numbers),
but the testing will continue.
One thing to think about: The closer we get, the longer it will take to make a good measurement. Data is only available at one second
granularity
--
Joshua Clayton
Software Engineer
UniWest
122 S. 4th Avenue
Pasco, WA 99301
(509) 544-0720
next parent reply other threads:[~2015-11-18 17:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2038851.J2zvFTXF8S@jclayton-pc>
[not found] ` <6767947.aE8xIVpPRR@jclayton-pc>
[not found] ` <564A1679.9070700@uniwest.com>
2015-11-18 17:38 ` Joshua Clayton [this message]
[not found] ` <006901d12230$a8641180$f92c3480$@uniwest.com>
2015-11-18 19:03 ` rtc test 2 Joshua Clayton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3458577.MLHbIx9t1o@jclayton-pc \
--to=joshua.clayton@uniwest.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox