Yo MIKE!
On Wed, 29 Aug 2018 02:32:42 + (UTC)
MIKE MAJOR via devel wrote:
> I have submitted 2 MR to NTPsec/www. Am I correct in assuming the
> following? 1. You are aware of the MRs.
> 2. You are busy preparing for a release.
> 3. You'll get to them after the release.
> I have some other
Hi everyone,
I have submitted 2 MR to NTPsec/www. Am I correct in assuming the following?
1. You are aware of the MRs.
2. You are busy preparing for a release.
3. You'll get to them after the release.
I have some other commits in my own fork to turn into MR. I'm waiting to create
more MR until
>Yo Achim!
>
>On Tue, 28 Aug 2018 19:28:32 +0200
>Achim Gratz via devel wrote:
>
>> Gary E. Miller via devel writes:
>> > We probably need to work with linuxpps, but we may have an easier
>> > time working with the folks that maintain the Raspberry Pi fork.
>> > The last time I asked for a dtb cha
On Tue, Aug 28, 2018 at 11:54:42AM -0700, Hal Murray via devel wrote:
> It makes us look sloppy. We worked hard to get (almost) no warnings. We
> should maintain that reputation.
>
> Also, we should document the new warnings the linker gives about tempnam from
> the python library.
Python fi
On 08/28/2018 05:56 PM, Gary E. Miller via devel wrote:
> if "PYTHONPATH" in os.environ:
> -print("--- PYTHONPATH is set, "
> - "this may mask or cause library-related problems ---")
> +print("--- PYTHONPATH is not set, "
> + "loadi
Yo All!
A bug in the PYTHONPATH detection. I get this on building:
[...]
Waf: Entering directory `/u/local/src/NTP/ntpsec/build/main'
--- PYTHONPATH is not set, loading the Python ntp library may be troublesome --
[...]
But my PYTHONPATH is set properly:
ntpsec # echo $PYTHONPATH
/usr/local/li
Yo All!
> I'm getting warnings on git head:
>
> [129/129] Linking build/main/ntptime/ntptime
> /usr/local/lib/python2.7/config/libpython2.7.a(posixmodule.o): In
> function
> `posix_tmpnam': /usr/local/src/Python-2.7.12/./Modules/posixmodule.c:7631:
> warning: the use of `tmpnam_r' is dangerous,
Yo All!
I'm getting warnings on git head:
[129/129] Linking build/main/ntptime/ntptime
/usr/local/lib/python2.7/config/libpython2.7.a(posixmodule.o): In function
`posix_tmpnam':
/usr/local/src/Python-2.7.12/./Modules/posixmodule.c:7631: warning: the use of
`tmpnam_r' is dangerous, better use `m
Yo Achim!
On Tue, 28 Aug 2018 22:56:37 +0200
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> >> So do I, in fact I run between 140ns to 240ns of "average jitter"
> >> pretty consistently across five machines (three different rasPi and
> >> two TinkerBoard).
> >
> > I was talk
Gary E. Miller via devel writes:
>> So do I, in fact I run between 140ns to 240ns of "average jitter"
>> pretty consistently across five machines (three different rasPi and
>> two TinkerBoard).
>
> I was talking Standard Deviation, a bit better measure of the jiter.
As you should know, the jitter
Yo Achim!
On Tue, 28 Aug 2018 21:43:03 +0200
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> >> That doesn't really matter, it is still about three orders of
> >> magnitude improvement over what we get today for the error that
> >> matters.
> >
> > Ah no. Lukas says 200 ns.
Achim Gratz via devel writes:
> I _think_ the uBlox-6 timing modules have it too, but I need to check
> the documentation. These may possibly not be implemented with hardware
> timers.
Just got confirmation that the modules used in Lukas' thesis were in
fact the ones we talked about earlier: The
Gary E. Miller via devel writes:
>> That doesn't really matter, it is still about three orders of
>> magnitude improvement over what we get today for the error that
>> matters.
>
> Ah no. Lukas says 200 ns. I can easily get under 1,000 ns. Sometimes
> down to 400 ns with care.
So do I, in fact
e...@thyrsus.com said:
> These warnings are spurious. They mean we need to find out how to declare to
> the NetBSD compiler that msyslog() is syslog-like, but that's all.
Or disable the %m warning option on NetBSD. I think it's -Wformat
There are 93 warnings with my configure setup and all b
Yo Achim!
On Tue, 28 Aug 2018 19:45:32 +0200
Achim Gratz via devel wrote:
> > The time from clock_gettime() is very coarse. Not up to our needs.
> > On a Raspberry Pi 3B+ running 64 bit kernel the granularity is only
> > 52 ns.
>
> That doesn't really matter, it is still about three orders o
Eric S. Raymond via devel writes:
>> Of course, this doesn't work on systems that don't have systemd. Is there a
>> commonly used way to do this?
>
> I've seen it done under System V init with a shell wrapper that runs a
> daemon in background, nohupping it and directing stderr to a logfile.
Tha
Hal Murray via devel writes:
> systemd has the option to support code that doesn't fork/daemonize. Taking
> advantage of that could clean up some of our code.
You'd need to start up as daemon using another program or possibly a
shell script if you're not using systemd. The complexity of that wi
MLewis via devel writes:
> A number of the ublox M8 series have a Timemark feature.
I can't stress it enough apparently: _all_ uBlox-8 have that feature.
Whether you can (easily) use it depends on whether the two pins are
not used for one of their alternate functions and if they're broken out
to b
[off-topic:
Hal, your replies break threading. Can you please stop
doing that?]
Hal Murray via devel writes:
> Could somebody please review this discussion. I'm trying to catch up. I can
> follow most of the details, but I'm missing the big picture.
The big picture is getting less noisy mea
MLewis via devel writes:
> "Strictly speaking, the PPS pulse isn�t even necessary for this process.
> One could
> simply generate a pulse on the external interrupt line once per second at a
> known
> time. "
Yes, and if you use both measurements to eliminate the interrupt
latency, then random
Gary E. Miller via devel writes:
> Yes, thus the need for the PPS timestamp AND the TM2 timestamp.
All that NTP needs is a pair of measurements that show the difference of
the local and external view of time, at roughly 1 second intervals. PPS
is not required to get that sort of result.
> The ti
MLewis via devel writes:
> The PPS becomes irrelevant.
> The PPS has all of the interrupt lag. Why introduce all that variable error.
Yes. It is still there however to be used independently if one wishes
to do that, but ntpd currently lacks the facilities to process multiple
sources into a single
Yo Achim!
On Tue, 28 Aug 2018 19:28:32 +0200
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> > We probably need to work with linuxpps, but we may have an easier
> > time working with the folks that maintain the Raspberry Pi fork.
> > The last time I asked for a dtb change it to
Gary E. Miller via devel writes:
> We probably need to work with linuxpps, but we may have an easier time
> working with the folks that maintain the Raspberry Pi fork. The last
> time I asked for a dtb change it took one day to get in git head.
The only thing that linuxpps would be the correct ta
Hal Murray via devel :
>
> systemd has the option to support code that doesn't fork/daemonize. Taking
> advantage of that could clean up some of our code.
>
> That would break the -w option.
>
> Of course, this doesn't work on systems that don't have systemd. Is there a
> commonly used way t
Hal Murray via devel :
>
> What's the story?
>
> I'm catching up after being off line for several weeks. I updated a NetBSD
> box to 8.0 and now it produces lots and lots of warnings that I expect would
> get fixed before a release.
>
> Most are complaining about %m. Sample:
> ../../libntp
Hal,
I know some of that.
And I think I understand some more.
On 28/08/2018 4:06 AM, Hal Murray via devel wrote:
Could somebody please review this discussion. I'm trying to catch up. I can
follow most of the details, but I'm missing the big picture.
What GPS device is involved? Is there a h
On 28-08-18 10:06, Hal Murray via devel wrote:
Could somebody please review this discussion. I'm trying to catch up. I can
follow most of the details, but I'm missing the big picture.
What GPS device is involved?
U-blox.
Is there a handy board?
e.g. https://www.csgshop.com/product.php?i
> systemd is explicitly and intentionally Linux only.
Yup/thanks. But the forking code within ntpd.c is sufficiently ugly that I
think it's worth considering alternatives.
Do any non-Linux systems have a clean way to handle this problem?
If not, could we invent one? That is, would the extra
On 08/28/2018 02:32 AM, Hal Murray via devel wrote:
> systemd has the option to support code that doesn't fork/daemonize. Taking
> advantage of that could clean up some of our code.
systemd is explicitly and intentionally Linux only. NTPsec could perhaps
have a compile-time ("configure") option
Could somebody please review this discussion. I'm trying to catch up. I can
follow most of the details, but I'm missing the big picture.
What GPS device is involved? Is there a handy board? What does it actually
do? I'm guessing it time stamps an input pin. (Some other GPS unit does
tha
systemd has the option to support code that doesn't fork/daemonize. Taking
advantage of that could clean up some of our code.
That would break the -w option.
Of course, this doesn't work on systems that don't have systemd. Is there a
commonly used way to do this?
--
These are my opinions.
32 matches
Mail list logo
