Yo Dan!
On Mon, 04 Jul 2016 19:27:50 -0500
Dan Drown wrote:
> Quoting "Gary E. Miller" :
> > Good stuff, but I find no mention of GPIO timestamping..
>
> pps-gpio takes the timestamp in the kernel interrupt handler.
Thanks for the confirmation. That was also my understanding.
RGDS
GARY
---
Yo Achim!
On Tue, 05 Jul 2016 21:58:12 +0200
Achim Gratz wrote:
> Gary E. Miller writes:
> > I looked for any GPIO timestamp counter in those docs. I could not
> > find it. Got a page number? Or maybe see where the gpio driver
> > reads such a thing?
>
> There is no hardware timestamping,
Gary E. Miller writes:
> I looked for any GPIO timestamp counter in those docs. I could not find
> it. Got a page number? Or maybe see where the gpio driver reads such a
> thing?
There is no hardware timestamping, the GPIO just raise interrupts. But
there is one single system time counter on t
Yo Hal!
On Tue, 05 Jul 2016 12:19:18 -0700
Hal Murray wrote:
> g...@rellim.com said:
> > The big thing for NTP and gpsd would be the 64 bit math. Both do a
> > lot of 64 bit math.
>
> You can do 64 bit arithmetic without using 64 bit pointers.
Yes, Linux on Intel can have a 64 bit kernel,
g...@rellim.com said:
> The big thing for NTP and gpsd would be the 64 bit math. Both do a lot of
> 64 bit math.
You can do 64 bit arithmetic without using 64 bit pointers.
Somebody mentioned that the plan is have one boot file that runs on all
Raspberry Pis. Are things setup so that user co
Yo Achim!
On Tue, 05 Jul 2016 07:35:40 +0200
Achim Gratz wrote:
> Gary E. Miller writes:
> > Nothing at all about GPIO or timestamping.
> >
> > Did I miss something?
>
> Maybe the fact that all the GPIO registers and the timestamp counter
> are on the VC4 side of the SoC. The Linux kernel ju
strom...@nexgo.de said:
> On another tangent back to NTP, I'm wondering if it wouldn't make sense to
> offload the timestamp filtering at least to the VC4. Most NTP boxes would
> run headless anyway, so there'd be 16 processors sitting idle for that sort
> of thing.
Not likely. That sort of wo
Gary E. Miller writes:
> Nothing at all about GPIO or timestamping.
>
> Did I miss something?
Maybe the fact that all the GPIO registers and the timestamp counter are
on the VC4 side of the SoC. The Linux kernel just reads those when it
gets interrupted by the VC4, the ARM subsystem doesn't have
> On Jul 4, 2016, at 7:19 PM, Gary E. Miller wrote:
>
>> There seems to be nothing up yet for the BCM2837 (Pi3), but it's
>> basically just replacing the A7 cluster in the BCM2836 with an A8
>> cluster.
>
> Yeah, I'm wondering why the dealy in Linux kernel for 64 bit A8?
>
In one of the posts
Quoting "Gary E. Miller" :
Good stuff, but I find no mention of GPIO timestamping..
pps-gpio takes the timestamp in the kernel interrupt handler.
The code is here:
http://lxr.free-electrons.com/source/drivers/pps/clients/pps-gpio.c?v=4.6#L60
To do this, the GPIO peripheral in the BCM2835 i
Yo Achim!
On Mon, 4 Jul 2016 08:43:40 + (UTC)
Achim Gratz wrote:
> Gary E. Miller rellim.com> writes:
> > > The BCM SoC actually is a media processor with an ARM subsystem
> > > and not the other way around as typically found elsewhere. The
> > > timestamp counter and all I/O is provided b
> On Jul 3, 2016, at 3:40 PM, Gary E. Miller wrote:
>
> Yo Achim!
>
> On Sun, 03 Jul 2016 12:10:44 +0200
> Achim Gratz wrote:
>
>> Eric S. Raymond writes:
>>> Gary E. Miller :
Anyone got a guess what the equivalent RasPi setting to turn off
power saving would be?
>>>
>>> turbo=
Gary E. Miller rellim.com> writes:
> > The BCM SoC actually is a media processor with an ARM subsystem and
> > not the other way around as typically found elsewhere. The timestamp
> > counter and all I/O is provided by the VC4.
>
> Got a citation for that?
[MIND THE LINEBREAKS]
https://www.rasp
Yo Achim!
On Sun, 03 Jul 2016 23:20:10 +0200
Achim Gratz wrote:
> Gary E. Miller writes:
> >> No. That used to be "force_turbo=1", but is not needed anymore.
> >
> > As of what kernel? I notice RasPi's have all sorts of weird kernel
> > versions and patchsets.
>
> I've not kept notes, but
Gary E. Miller writes:
>> No. That used to be "force_turbo=1", but is not needed anymore.
>
> As of what kernel? I notice RasPi's have all sorts of weird kernel
> versions and patchsets.
I've not kept notes, but the first Raspbian installation from about two
years ago already didn't need it (unt
Yo Achim!
On Sun, 03 Jul 2016 12:10:44 +0200
Achim Gratz wrote:
> Eric S. Raymond writes:
> > Gary E. Miller :
> >> Anyone got a guess what the equivalent RasPi setting to turn off
> >> power saving would be?
> >
> > turbo=1 in /boot/config.txt, I think. See also
>
> No. That used to be
Eric S. Raymond writes:
> Gary E. Miller :
>> Anyone got a guess what the equivalent RasPi setting to turn off
>> power saving would be?
>
> turbo=1 in /boot/config.txt, I think. See also
No. That used to be "force_turbo=1", but is not needed anymore. You
simply define the maximum (and perhaps m
Yo Eric!
On Thu, 30 Jun 2016 05:51:56 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > Anyone got a guess what the equivalent RasPi setting to turn off
> > power saving would be?
>
> turbo=1 in /boot/config.txt, I think. See also
>
> https://www.raspberrypi.org/blog/introducing-turbo-mo
Yo Hal!
On Thu, 30 Jun 2016 02:15:36 -0700
Hal Murray wrote:
> g...@rellim.com said:
> > I took another look, and realized I misunderstood the y axis. And
> > that you are plotting loopstats and I'm looking at offsets. So not
> > the bad I thought.
>
> I can't figure out what that means.
g...@rellim.com said:
> I took another look, and realized I misunderstood the y axis. And that you
> are plotting loopstats and I'm looking at offsets. So not the bad I
> thought.
I can't figure out what that means.
I was plotting the offset column from loopstats.
> To get apples and apples,
Gary E. Miller :
> Anyone got a guess what the equivalent RasPi setting to turn off
> power saving would be?
turbo=1 in /boot/config.txt, I think. See also
https://www.raspberrypi.org/blog/introducing-turbo-mode-up-to-50-more-performance-for-free/
--
http://www.catb.org/~esr/";>E
Yo Hal!
On Wed, 29 Jun 2016 22:21:41 -0700
Hal Murray wrote:
> > Local clock frequency offset, as opposed to local clock time
> > offset.
>
> Most NTP documentation calls that drift. Its magnitude is not very
> interesting when discussing quality of time. Changes over time can
> be interes
> Local clock frequency offset, as opposed to local clock time offset.
Most NTP documentation calls that drift. Its magnitude is not very
interesting when discussing quality of time. Changes over time can be
interesting. It's usually much more interesting to look at the clock offset.
There a
Yo Hal!
On Wed, 29 Jun 2016 21:35:49 -0700
Hal Murray wrote:
> g...@rellim.com said:
> > Wow. I thought something was wrong. My local clock offset
> > (peerstats file) has always been hanging around 100ppm. Stable to
> > ±1ppm so I figured that was normal.
>
> > After reboot the local cloc
g...@rellim.com said:
> Wow. I thought something was wrong. My local clock offset (peerstats file)
> has always been hanging around 100ppm. Stable to ±1ppm so I figured
> that was normal.
> After reboot the local clock offset started at 9ppm and has been slowyly
> going down, now under 2ppm.
Yo Hal!
On Wed, 29 Jun 2016 15:28:29 -0700
Hal Murray wrote:
> g...@rellim.com said:
> >> I'm not sure why you would expect performance to be identical.
> > Because thhey use the same kernel generated time stamp and PLL
> > algorithm.
>
> There are two chunks of PPS code in the kernel with
g...@rellim.com said:
>> I'm not sure why you would expect performance to be identical.
> Because thhey use the same kernel generated time stamp and PLL algorithm.
There are two chunks of PPS code in the kernel with separate RFCs. One is
getting the time stamp. The other is doing the PLL. Th
On Wed, Jun 29, 2016 at 12:31:32PM -0700, Hal Murray wrote:
> matthew.sel...@twosigma.com said:
> > We tested booting with "nohz=off intel_idle.max_cstate=0" and it made a
> > difference in our production clocks.
>
> Interesting. Thanks.
>
> How did you decide to go there?
The "nohz=off" hint
Yo Matthew!
On Wed, 29 Jun 2016 16:38:40 -0400
Matthew Selsky wrote:
> Measuring on this server via ntpq -p we were seeing offsets of +/-
> 3us without either of these two kernel parameters. With nohz=off,
> the offsets were +/- 1us. With both kernel parameters we see
> offsets too small for n
Yo Matthew!
On Wed, 29 Jun 2016 16:38:40 -0400
Matthew Selsky wrote:
> > Can you quantify the individual effects? And is that kernel PPS,
> > KPPS in ntpsec, or just PPS in ntpsec?
>
> We're using a GPS PCIe card with OCXO HQ with a daemon that writes to
> SHM and then ntpd reads from the SH
On Wed, Jun 29, 2016 at 12:31:56PM -0700, Gary E. Miller wrote:
> Yo Matthew!
>
> On Wed, 29 Jun 2016 14:55:23 -0400
> Matthew Selsky wrote:
>
> > On Wed, Jun 29, 2016 at 11:48:08AM -0700, Hal Murray wrote:
> > > > Can you quantify the better? I would have expected identical...
> > >
> > > D
Yo Hal!
> > > Did you look at the graph?
> > > http://users.megapathdsl.net/~hmurray/ntpsec/glypnod-pps-kernel.png
>
> Yeah, your 'No kernel' was aweful. If that is your baseline then you
> got something really, really, wrong. The scale on the 'kernel PLL'
> was too small to really tell, but
Yo Hal!
On Wed, 29 Jun 2016 11:48:08 -0700
Hal Murray wrote:
> I'm not sure why you would expect performance to be identical.
Because thhey use the same kernel generated time stamp and PLL algorithm.
> Dave
> Mills and crew went to a lot of effort to get code into various
> kernels, including
Yo Matthew!
On Wed, 29 Jun 2016 14:55:23 -0400
Matthew Selsky wrote:
> On Wed, Jun 29, 2016 at 11:48:08AM -0700, Hal Murray wrote:
> > > Can you quantify the better? I would have expected identical...
> >
> > Did you look at the graph?
> > http://users.megapathdsl.net/~hmurray/ntpsec/glypn
matthew.sel...@twosigma.com said:
> We tested booting with "nohz=off intel_idle.max_cstate=0" and it made a
> difference in our production clocks.
Interesting. Thanks.
How did you decide to go there?
Did you try those 2 changes separately? Was that with PPS or just a typical
system?
Are you
On Wed, Jun 29, 2016 at 11:48:08AM -0700, Hal Murray wrote:
> > Can you quantify the better? I would have expected identical...
>
> Did you look at the graph?
> http://users.megapathdsl.net/~hmurray/ntpsec/glypnod-pps-kernel.png
>
> I'm not sure why you would expect performance to be identical
> Can you quantify the better? I would have expected identical...
Did you look at the graph?
http://users.megapathdsl.net/~hmurray/ntpsec/glypnod-pps-kernel.png
I'm not sure why you would expect performance to be identical. Dave Mills
and crew went to a lot of effort to get code into various
Yo Hal!
On Wed, 29 Jun 2016 03:21:40 -0700
Hal Murray wrote:
> So I pulled over the sources and built a kernel with NO_HZ turned off
> and NTP_PPS turned on.
I'm interested.
> The next project is to figure out why it works so much better, or
> rather why the normal ntpd can't do a lot better.
http://users.megapathdsl.net/~hmurray/ntpsec/glypnod-pps-kernel.png
If you turn on flag3 for a PPS driver on a Linux system, you get this error
message:
06-20T12:25:32 ntpd[988]: refclock_params: kernel PLL (hardpps, RFC 1589) not
implemented
I poked around a bit. Those options are in drivers/
39 matches
Mail list logo
