Date: Wed, 6 Feb 2013 14:54:34 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org Subject: Re: SD card -image- for the beaglebone Message-ID: <19C1F505-69C3-4DAB-8FE0-A34B30F08582@bsdimp.com> In-Reply-To: <1360177280.93359.611.camel@revolution.hippie.lan> References: <510A4F5B.7000407@g7iii.net> <1359646574.93359.327.camel@revolution.hippie.lan> <510AE1D6.8010203@g7iii.net> <1360124308.93359.557.camel@revolution.hippie.lan> <5112115D.5040709@g7iii.net> <1360158409.93359.590.camel@revolution.hippie.lan> <52928DD2-AA41-4B3C-A22A-1F755832D220@bsdimp.com> <1360177280.93359.611.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 6, 2013, at 12:01 PM, Ian Lepore wrote: > On Wed, 2013-02-06 at 07:57 -0700, Warner Losh wrote: >> On Feb 6, 2013, at 6:46 AM, Ian Lepore wrote: >>=20 >>> On Wed, 2013-02-06 at 08:16 +0000, Iain Young wrote: >>>> On 06/02/13 04:18, Ian Lepore wrote: >>>>=20 >>>>> Check out what I taught my beaglebone to do today... >>>>>=20 >>>>> root@bb:/ # ntpq -p >>>>> remote refid st t when poll reach delay offset = jitter >>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> oPPS(0) .PPS. 0 l 4 16 377 0.000 0.399 = 0.008 >>>>> +dvb.hippie.lan .GPS. 1 u 55 64 377 1.411 0.666 = 0.126 >>>>> +tflex.hippie.la .GPS. 1 u 15 64 377 0.901 1.867 = 0.904 >>>>> +paranoia.hippie .PPS. 1 u 61 64 377 0.396 0.426 = 0.025 >>>>> xutcnist2.colora .ACTS. 1 u 71 64 376 34.136 -11.277 = 4.656 >>>>> xnist1.symmetric .ACTS. 1 u 63 64 377 59.880 12.327 = 2.113 >>>>> -ntp.your.org .CDMA. 1 u 4 64 377 51.185 -4.212 = 4.215 >>>>> xntp1.conectiv.c .IRIG. 1 u 51 64 377 99.067 17.784 = 3.445 >>>>>=20 >>>>> It turns out the chip has nice timer hardware that can latch the >>>>> freeruning timercounter in response to the PPS signal. That = allows for >>>>> a PPS driver that doesn't use interrupts at all. The timecounter = code >>>>> has a specific interface for such hardware, but there isn't much = example >>>>> code in the base for how to use it. Soon there'll be more. :) >>>>>=20 >>>>> I'll attach a patch in case anyone else wants to play with this. = To use >>>>> it, apply the patch, add "options PPS_SYNC" to the kernel config, = and >>>>> choose which timer pin you want to put the pps on. The attached = patch >>>>> uses the timer4 pin, which is exposed on the P8 connector as pin = #7. >>>>> You can use any of the timer4-timer7 pins, just set the one you = want to >>>>> use to "input" in the dts and the driver will use it. >>>>=20 >>>> Thanks for that, looks great, and very interesting. I'll do more = than >>>> play with it (well when the 8 Gig card arrives anyway!) >>>>=20 >>>> First thought, extending for multiple PPS :) [Because I can :P] >>>>=20 >>>=20 >>> This kind of no-interrupt PPS driver that's tied closely to the = system >>> timecounter can only handle a single PPS signal. (There's only one >>> system timer, and it has just one trigger pin.) Connecting more = than >>> one PPS is still going to require an interrupt-driven gpio solution. >>>=20 >>> Even though there are four timers on the chip that have an external >>> trigger input wired to a pin, it's basically impossible with the = current >>> freebsd timing code to combine triggered-capture of the pps pulse = time >>> with traditional interrupt handling to harvest the captured counter. >>> When you try to do this, you occasionally end up with a sequence = where >>> the hardware latches the counter, then the timekeeping code switches = to >>> a new set of timehands before the interrupt handler is invoked, then = you >>> end up grabbing a latched counter value that matches up with the = wrong >>> set of timehands, and you get a measurement jump equal to the timer = tick >>> period. (I know most people don't care about these details, but = it's >>> actually nice to get them in writing somewhere searchable for future >>> reference.) >>=20 >> Yes, this is an edge case that is a whole in the current no-lock = algorithm... >>=20 >>> I've never configured a system for multiple PPS inputs, that'll be = an >>> interesting thing to play with. I need to learn more about our gpio >>> framework (such as it is) and see if it's possible to put in a nice >>> generic PPS driver that uses it. >>=20 >> The current time keeping stuff assumes you have *THE* source of time = in the PPS. Having multiple sources requires more sophisticated = techniques than the simple FLL/PLL loop the kernel implements, since you = effectively have to construct a paper clock. >=20 > Ntpd already does some clock combining stuff, and it's possible to = tell > ntpd to pass steering info to the kernel, rather than doing a kcbind() > in the ntpd refclock driver and then having ntpd monitor the kernel's > steering. =20 True. But ntpd will pick the best and steer to that rather do something = more sophisticaed. > I don't think ntpd goes all the way to a paper timescale, at least not > the older code I'm familiar most with.=20 No, it doesn't. >> If you are creating a measurement system, and not just pacing system = time to a good, solid reference frequency, then you'll have to have time = counters that can latch the signals independently, and have some sort of = interrupt/poll routine that harvests the data for later analysis. The = analysis and construction of paper clocks ranges from "easy, but with = so-so results" all the way to "extremely hard, but with extremely good = results." The devil is in the details, and usually in the details of = what you do when one or more signals go away... >=20 > Well, besides running a little roll-your-own clock ensemble system, a > more mundane use of multiple PPS inputs would be simple failover for > ntpd. At least, I think in theory it should work fine to configure = ntpd > with multiple refclocks and if one goes bad it can continue with = others. You could do that, but the daemon to control the rollover would need to = be in userland. The kernel certainly has no notion of failure = criteria... I doubt your theory though. I've never had multiple ref clock work out = well. Ever. Maybe the newer ntpd copes better, but the experiments I ran = about 10 years ago were at best abject failures. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19C1F505-69C3-4DAB-8FE0-A34B30F08582>