devel@ntpsec.org said:
>> You don't need the RTC. You can get the initial time over the net.
> But the time I can get from the DS3231 RTC after outages should have
> drifted in microseconds, or tens of or hundreds of. So very fast sync to
> TOS by pps-client once booted and GPS solution provided
Hello,
On 26/11/2017 3:13 PM, Hal Murray wrote:
I think it should do what you want if you set it up with only a localclock.
(no normal servers)
I think I found it.
Similar use case as when the reference is System Time disciplined by PTP.
The local clock driver can also be used when an external
devel@ntpsec.org said:
> - pps-client installed as expected. One gets the Stretch source and
> compiles the kernel as part of that.
It would be interesting to poke around in pps-client to see what it actually
does.
There are two ways to use PPS. One is to to capture the data and then feed
th
Nice. Thanks.
You don't need the RTC. You can get the initial time over the net.
> - (if I understand properly) pps-client takes a pair of GPIO pins and
> calibrates latency, so its PPS adjustment is more accurate.
Any numbers?
I've thought of doing something like
sleep until a bit after
I thought people working on having a Rasp Pi as a Time Server
would/should be aware of pps-client.
My Rasp Pi 3 is running software (pps-client) that uses GPS PPS and
seems to be meeting the goal of maintaining system time to +/- 1 us.
How I got there:
- I got a Raspberry Pi 3 running Raspbia
On Sat, Nov 25, 2017 at 01:26:18AM -0800, Hal Murray via devel wrote:
> (gdb) bt
> #0 0x76ebf104 in futex_wake (private=0, processes_to_wake=2147483647,
> futex_word=0x76eaf618) at ../sysdeps/unix/sysv/linux/futex-internal.h:231
> #1 __pthread_once_slow (once_control=0x76eaf618, init_routine
On Sat, Nov 25, 2017 at 05:09:02AM -0800, Hal Murray wrote:
>
> k...@roeckx.be said:
> > This means that when we initialize a global variable we use the
> > pthread_once() function, which internally uses the futex to do that. It's
> > not using threads itself, it's just making sure that if you use
Hal Murray via devel :
>
> > It is important to specify -g on the command line to allow NTP to correct
> > the clock on boot. However, if Restart=yes is set, a malicious (or broken)
> > server could send the incorrect time, trip the panic threshold, and when
> > ntpd restarts, serve it the incorr
Hal Murray via devel writes:
> I finally figured out that systemd-timesyncd was also running and messing
> with the clock. It's all downhill from there.
That problem has been noted elsewhere:
https://unix.stackexchange.com/questions/305643/ntpd-vs-systemd-timesyncd-how-to-achieve-reliable-ntp-s
> It is important to specify -g on the command line to allow NTP to correct
> the clock on boot. However, if Restart=yes is set, a malicious (or broken)
> server could send the incorrect time, trip the panic threshold, and when
> ntpd restarts, serve it the incorrect time (which would be accepted
> There aren't any uses in our code. Whether we can remove it is a question.
> Have you identified where it's generated.
I think it's in wafhelpers/check_pthread.py
If you are thinking about that area, please consider issue #412
https://gitlab.com/NTPsec/ntpsec/issues/412
--
These are my o
Hal Murray :
> > > '-DPYTHONDIR="/usr/local/lib/python2.7/site-packages"',
> > > '-DPYTHONARCHDIR="/usr/local/lib64/python2.7/site-packages"',
> > > '-DHAVE_PYEXT=1', '-DHAVE_PYTHON_H=1'
> > Yeah, that's boilerplate for use by Python extensions written in C.
>
> I haven't found any uses in our c
12 matches
Mail list logo
