Re: Need help from a python wizard

[Clark B. Wierda via devel]

On Mon, Dec 4, 2017 at 5:51 PM, Hal Murray via devel <devel@ntpsec.org>
wrote:

>
> days = int(last) / 86400
> seconds = last - days*86400
>
> I've kludged some printing.
> days is a float, for example: 17504.9482755
>
> is int/int supposed to result in an int or a float?
>
> I expected it to be an int.  This code used to work.  Trying by hand, I get
> an int...
>
>
>
There is a change in the way this is handled by Python between 2 and 3.

You can force integer arithmetic with "//" like 3 // 2 which will result in
1.

It looks like you are trying to get the days and the leftover seconds
(int(last) % 86400).  Also if last is a string value it might be returning
a numeric equivalent of zero.  The actual error is likely not using
"int(last)" in the second case.

However, if I understand the intent, the correct Python solution is "days,
seconds = divmod(int(last), 86400)".

Again, assuming I'm not making an embarrassing omission, the code should
look something like:


last = ntp.ntpc.lfptofloat(entry.last)
if self.now:
lstint = int(self.now - last + 0.5)
stats = "%7d" % lstint
else:
# direct mode doesn't have a reference time
MJD_1970 = 40587 # MJD for 1 Jan 1970, Unix epoch
days, lstint = divmod(int(last), 86400)
stats = "%5d %5d" % (days + MJD_1970, lstint)


If that is not the issue, I will be glad to take a real look at this in
running code.

Regards,
Clark B. Wierda
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Use of pool servers reveals unacceptable crash rate in async DNS

[Clark B. Wierda]

On Mon, Jun 27, 2016 at 3:47 PM, Hal Murray <hmur...@megapathdsl.net> wrote:

>
> cbwie...@gmail.com said:
> > How are pool entries added when the service decides it needs more?
>
> There is some background stuff that roughly says "need more?", and if so
> fires off the DNS lookup.
>
>
> > Would it be possible to leverage this code for adding all servers
> specified
> > by name?
>
> Probably not directly, but it wouldn't be hard for the server code to use
> more than one address if that was desired.  Maybe it should be "servers"
> rather than "server".  Do you have an example where that would be useful?
>
> If you don't have lots of servers, you probably don't want to switch to
> using
> "pool" since that path will probably keep banging away at the DNS looking
> for
> more servers.
>
>
I'm not looking to change the operation of the server or pool directive.

I was thinking of setting up associations using the DNS lookup code.  If
the mechanism for adding new pool servers was blocking on the DNS call but
asynchronous to the rest of the daemon, I was figuring to call the lookup
with the name provided by the server directive.  The only real difference
between a specified server and a pool server is that you don't delete the
specified server.

I'm definitely not looking to bang on DNS servers any more than I have to.

Clark B. Wierda
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: The new refclock directive is implemented and documented

[Clark B. Wierda]

On Mon, Jun 27, 2016 at 2:49 AM, Gary E. Miller  wrote:

>
> Since you opened the door...
>
> > |shm| T | Shared Memory Driver
> > |gpsd   | T | GPSD NG client protocol
>
> I think that leads to confusion since they both, at least for now,
> come from gpsd.  And until the gpsd_json driver has sane, documented,
> defaults, I fear that people will try it first with gpsd.
>
> Maybe: gpsd_shm, and gpsd_json.  Or: shm and json.
>
> There could be other gpsd variants in the future.
>
> RGDS
> GARY
>


I agree with the later comments on shm.  This isn't necessarily specific to
GPSD, so just shm is correct.

IIRC, GPSD NG uses JSON over a socket.  Is this restricted to GPSD, or is
the JSON general enough to be used by any similar source?

If the protocol is specific enough that we can assume GPSD, I think gpsd is
correct.  I will agree with Gary about the possibility for confusion.
Documentation will help, but the possibility will remain.

If this is general enough, it could lead to confusion when another source
uses this refclock, but I am unsure of the correct name.  Using socket
comes to mind, but that has its own problems.

Clark Wierda
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: The new refclock directive is implemented and documented

[Clark B. Wierda]

On Mon, Jun 27, 2016 at 12:21 AM, Eric S. Raymond  wrote:

> The new refclock directive is implemented and documented.  This has
> had some large consequences.
>
>
Great!

I'll echo Hal on the desirability to be less specific when we can.

I think we should try to have the options be as descriptive as possible.

Candidates I would expect are delay, offset, mode, and edge.

These may require inconsistent mapping from Classic, but that update is
required anyway and should only happen once.

Clark Wierda
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Use of pool servers reveals unacceptable crash rate in async DNS

[Clark B. Wierda]

A question:

How are pool entries added when the service decides it needs more?

Would it be possible to leverage this code for adding all servers specified
by name?  The DNS cost would be the same.  This only difference is the name
used for the query.

Once a server is associated, the IP is used.  There should be no impact on
the time calculations after an association is provisioned.

Clark B. Wierda

On Sun, Jun 26, 2016 at 9:13 PM, Hal Murray <hmur...@megapathdsl.net> wrote:

>
> Possible crazy idea...
>
> How about we never kill the DNS helper thread.  Just let it sit there in
> case
> it gets more work to do.  The only cost is a bit of memory.
>
> Or maybe only do that if we are locking stuff into memory.
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Figures of merit for time servers

[Clark B. Wierda]

Looks like a good time for this question:

What are the figures of merit that we should be tracking when monitoring
the quality of servers using NTP for exchange?

I understand that these values will factor differently with different user
groups, but the characteristics we can measure should be fairly consistent.

I also understand there are "reported" (offset, error/dispersion, jitter,
wander) and "derived" (90% variability in observed value of foo, external
view of relative time) values.

Based on Gary's message (I hope it was Gary), we should use the same terms
to reference the same "thing".  We should be precise in that usage and
avoid the softer terms.

I want to thank Hal for the Monitoring NTP servers message.  That is a
great starting point.  I plan to create a time server that is using GPIO
PPS as the baseline and watching the rest of the space.  I can use the
created logs.

Once I have some data, I can figure out a good way to display it and
iterate from there.

Regards,
Clark B. Wierda
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Fwd: [gpsd-dev] Draft Stratum 1 Microserver HOWTO is up

[Clark B. Wierda]

Previous attempt to devel@ntpsec.org bounced, but everything looks good now.

I apologize to those that already received this.

Clark B. Wierda

-- Forwarded message --
From: Clark B. Wierda <cbwie...@gmail.com>
Date: Sun, May 22, 2016 at 2:10 PM
Subject: Re: [gpsd-dev] Draft Stratum 1 Microserver HOWTO is up
To: gpsd-...@nongnu.org, devel@ntpsec.org
Cc: "Eric S. Raymond" <e...@thyrsus.com>


Just a few general thoughts:

It might be easier to follow if the "clockmaker" sequence is presented
separately from the "manual" sequence.  Likely, this would be different
parts of the same document.

Any discussion of fudge factors beyond any defaults in the code (if PPS is
reliable, they are not needed) and performance tuning is applicable to any
installation and should be a separate document.  The Timeservice document
related to GPSD already exists and discusses many of these items.

The main sequences noted above should document the "happy path".  Handling
the problem should go to a Troubleshooting section with more detailed
information.  This will reduce the opportunity to confuse the naive user
that is the target of this document.

Likewise, I think we should like the scope in the primary sections to the
Raspberry Pi.  There are at least 5 variants there (at least 2 of which
will not accept the GPS HAT).  [I'd actually be tempted to write to the RPi
2B as that is likely to be the most common while avoiding the issues with
the RPi 3B.  The special case would be handled as noted above with special
section on the differenecs.]  There are many documents on the 'Net that
reference another document as a baseline and only document the changes.
The Raspberry Pi is likely to remain the majority player in this space for
the foreseeable future.  Some of the other devices in this space are going
to be work-alike or work-similar.  Most users who are going to be trying
something like an ODroid, or Banana, are likely to be able to handle the
needed adjustments themselves.  Something further afield, like the
Beaglebone, will be different enough to add significantly to the complexity
in handling.

Finding the IP of the Pi would be one of those things that could go in a
separate section if it doesn't "just work".  Just adding a keyboard and
monitor long enough to find the address is likely to work for most people.
Much beyond that is going to be risking confusion to the target audience.

I'm reminded of the NTPsec motto and I think we should apply that here.
The main sequence should be as simple as possible.  I think the sections
could be something like Introduction, Scripted/Automated/clockmaker,
Manual, Troubleshooting, Special Cases, References.

I know this is late in the process for this kind of input, but I hope this
is still useful in some way.

Regards,
Clark B. Wierda
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Draft Stratum 1 Microserver HOWTO is up

[Clark B. Wierda]

On Fri, May 20, 2016 at 4:16 PM, Eric S. Raymond  wrote:

>
> Current inventory, for those interested.  Machines are named after elements
> because two letters is all that will fit on the stickers that will fit on
> my micro-SD cards.
>
> ar - Pi 3, soon to be mated to an Adafruit HAT
> au - Pi 2, mated to the SKU 424254 HAT
> fe - Pi 3, mated to an Adafruit HAT
> cu - Po 2, mated to an Uputronics HAT
>
>
Eric, does the Uputronics HAT come assembled?

Clark
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

NTP Pool (was Re: Draft Stratum 1 Microserver HOWTO is up)

[Clark B. Wierda]

On Fri, May 20, 2016 at 1:30 PM, Hal Murray  wrote:

> [pool limit of 100 ms]
>
> e...@thyrsus.com said:
> > That's weird.  Why would they have a precision requirement *above*
> RFC5905's
> > "A few tens of milliseconds"?  You'd think they'd want it to be below
> that.
>
> If you want time in the range of 10s of ms, you need to select the servers
> you use.  With something like the pool, you are likely to get a server on
> the other side of the country with associated routing quirks.
>
> I think the goal of the pool project has always been good-enough rather
> than great accuracy.  100 seems like a reasonable cutoff point to me.  What
> did you have in mind?
>
> Another consideration is that there is only one monitoring station.
>

>From reading their documentation, they monitor the pool candidates and
report on their merit.  The availability of the metrics could be better,
but they are trying to ensure a minimum.  Their goal is related to
human-scale time.  Also, I think their focus is spreading the load.

BTW, I was getting within 5ms using generic ublox-7 puck (no PPS) on an old
laptop. USB PPS (GR-601W) was reliably under 1ms.

Clark
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Draft Stratum 1 Microserver HOWTO is up

[Clark B. Wierda]

I will try to get a cycle of these this weekend.

I have BBB, ODroid-C2, RPi 3B, RPi 2B, and RPi 1B.

I have the Adafruit Hat kit ready to build, a ublox-7, and a GR-601W.

I can send in the fudges for all the above after verification in the RPi
environment.

Aside:
I was reading the requirements for the NTP Pool Project and they have very
soft precision targets (>100ms). I was thinking that just about any USB GPS
puck should be able to deliver this.  This would simplify the process for
many users.

Clark B. Wierda
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: [gpsd-dev] New 0.5 draft of the SemPiTernal HOWTO

[Clark B. Wierda]

On Thu, May 5, 2016 at 9:24 PM, Norton Allen <al...@huarp.harvard.edu>
wrote:

> On 5/5/2016 5:17 PM, Gary E. Miller wrote:
>
>> On Thu, 5 May 2016 16:48:26 -0400
>> Frank Nicholas<fr...@nicholasfamilycentral.com>  wrote:
>>
>> > >communicates with ntpd via SHM.  It's not clear why refclock 20
>>>> > >should survive thaat transition when gpsd is already better at
>>>> > >adapting to weird sentence inventories than it is.
>>>>
>>> >
>>> >How portable is “SHM”? **
>>>
>>
> I know SHM is not portable to QNX, which has shm_open() POSIX 1003.1. I am
> still hoping to work on getting gpsd+PPS-SHM working, but have been
> sidetracked by other work. But that leaves me with refclock #46, and it
> sounds from the discussion here as though that is essentially deprecated.
> And yes, my intent is to get both time and position, which is why gpsd is
> in the mix.



RefClock 46 is NOT deprecated.  This is actually a preferred solution as it
should be more portable than SHM.


> Rather than bump up to shm_open(), I'd like to add sockets.  Chronyd
>> uses sockets as an optional alternative to SHM.  This is more flexible,
>> more secure, and allows the consumer to wait for data instead of
>> polling.  Any process that can write to SHM can smash the clock.  It
>> does make things like ntpshmmon impossible.
>>
>

> sockets sounds like a good option.
>
> Agreed

Clark B. Wierda
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Pi HOWTO

[Clark B. Wierda]

On Wed, May 4, 2016 at 2:08 AM, Hal Murray <hmur...@megapathdsl.net> wrote:

>
> e...@thyrsus.com said:
> > Given the geometry it looks like it will handle a single HAT with the lid
> > on, though.
> 
> I've seen one "case" that was 2 sheets of plastic and 4 posts in the
> corners.
>  That left all sorts of room for cables to go in/out the sides.  I don't
> remember where I saw it.
>
>
There is a case like that from GeauxRobot available through Amazon.  I have
the extension that allows 4 Pis to be mounted in a single frame.  This was
the case used for the cluster I was showing at Penguicon.

Clark B Wierda
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: RaspbPi HOWTO

[Clark B. Wierda]

On Tue, May 3, 2016 at 12:39 PM, Hal Murray <hmur...@megapathdsl.net> wrote:

> e...@thyrsus.com said:
> > Accordingly, I'll be extending the breadth of the HOWTO to cover more
> > hardware - not just two additional HATs but the Odroid C2 as well and
> > probably the BeagleBone Black later.
>
> Could you please say a bit more about that area?
>
> 
> I took a quick scan at the Odroid C2 web pages.  It has a 40 pin header,
> but
> I didn't find any claims about Pi compatibility.  Does anybody know if it
> takes any of the Pi GPS HATs?
>

>From the Technical Detail tab for the Odroid C2:
Please note that pins #37, #38 and #40 are not compatible with Raspberry Pi
B+ 40pin header. Those pins are dedicated for Analog input function.
Also note that all the GPIO ports are 3.3Volt. But the ADC inputs are
limited to 1.8Volt.

The GPS Hat should just work.  The GPS Hat will also provide an RTC for
both the ODroid and the RPi.

Regards,
Clark B. Wierda
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: RaspbPi HOWTO

[Clark B. Wierda]

On Tue, May 3, 2016 at 9:05 AM, Eric S. Raymond <e...@thyrsus.com> wrote:

> 
> Accordingly, I'll be extending the breadth of the HOWTO to cover more
> hardware - not just two additional HATs but the Odroid C2 as well and
> probably the BeagleBone Black later.
> --
> http://www.catb.org/~esr/;>Eric S. Raymond
>

I'm looking forward to that document once it settles.  Then I will be
trying it against anything I have that might work.

I have RPi1, RPi2, RPi3, BBB, and O-Droid C2.  I also have an old Chumby
that I will try, but just for the challenge.

I have an Adafruit Ultimate GPS Breakout coming that I intend to try on the
BBB.  I have a few GPS devices of the handheld and mouse USB variety that I
intend to try as well.

Cheers,
Clark B Wierda
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel