Eric S. Raymond esr at thyrsus.com :
>Gary E. Miller via devel :
>> > So there is nothing you recommend be merged at this time?
>>
>> I sorta wish NTPsec had a staging area like the Linux kernel does.
>>
>> There is value to a small and clean u-blox driver fully integrated
>> into NTPsec. But wi
>Gary E. Miller gem at rellim.com wrote
Thank you for the comments, I have replies for each point:
>Yo Udo!
>
>On Sun, 24 Nov 2019 09:23:19 +0100
>Udo van den Heuvel via devel wrote:
>
>> I cam across this ublox ntpsec refclock:
>> https://gitlab.com/trv-n/ntpsec-ublox
>> Would it be usable for
On Fri, 29 Nov 2019 21:18:50 -0500, you wrote:
>On Wed, 27 Nov 2019 22:08:48 -0500, Trevor N.
>wrote:
>...
>>I have already begun collecting F9T data with gpsd-3.19 (kernel PPS
>>enabled) through shm on the latest ntpsec. I'll post 1-day output as
>>soon as it's available.
>>
>The results at
>Hal Murray hmurray at megapathdsl.net wrote:
>Fri Dec 6 11:47:41 UTC 2019
>
>I just pushed it.
>
>Default is no change. If you add --disable-fuzz to your configure line,
>almost all that code goes away.
>
>The "almost" is because ifdef-s don't work in bison input. So "tinker tick
>" still gets
>Message: 3
>Date: Tue, 11 Feb 2020 00:33:07 -0800
>From: Hal Murray
>To: devel@ntpsec.org
>Subject: Anybody taking care of refclock_trimble?
>Message-ID:
> <20200211083307.a89ce406...@ip-64-139-1-69.sjc.megapath.net>
>Content-Type: text/plain; charset=us-ascii
>
>
>/* get timestamp
On Thu, 13 Feb 2020 03:24:21 -0800, you wrote:
I didn't get time this weekend to put anything on the issue tracker,
but I'll test over the next week with --disable-fuzz without changing
anything.
I have not made any changes to the Trimble driver since the generic
GPS rollover workaround suffixes
From: Hal Murray
To:devel@ntpsec.org
Subject: Testing
Does anybody test our code on Apple? Solaris?
In order to test 32 bit and 64 bit big and little endian hosts with the
Trimble driver, I have been using:
LE32: Raspberry Pi 3B with Raspbian
LE64: Xeon with Gentoo
BE32: Power Mac G4 with Fre
I created a loop like that for the Trimble driver. The algorithm is
pretty simple so I'm probably missing something; please check out the
merge request I made a few days ago. I still need to test the changes
with my simulator and with ntpd started with date offsets.
>Hal Murray hmurray at megapa
I have a device that will rollover after week 1998 (in 2018) that I
just tested with a GPS simulator set to 2 years in the future,
attached to ntpd classic with a +2 year offset in get_ostime (and
"disable ntp" in conf) and ntpcal_get_build_date() of 2016. The
512-week-around-receive-timestamp cod
I just finished testing the refclocks supported by the Trimble
driver on a sparc64 machine. The configure was able to set
WORDS_BIGENDIAN 1
without any problem. I didn't notice any runtime problems besides
what's likely due to serial port delays, but there were some warnings
during the bui
Please revert commit d74cf1e3 if possible. It seems that the MR page
is only available when not logged in, so I can't comment there.
On Sat, 27 May 2017 12:00:00 +, you wrote:
>Date: Fri, 26 May 2017 14:57:37 -0700
>From: "Gary E. Miller"
>To:
>Subject: ?MR 422
>Message-ID: <20170526145737.7
The CI builds worked, and I usually start with a ./waf distclean so I
didn't notice that moving the function into libntp breaks builds that
have not been cleaned.
While attempting to fix classic bug 2659 I noticed another problem
with my commit d74cf1e3: Since the UTC offset is now required to
obta
It's not necessary to use refclock_process() if the driver creates
its own l_fp timecode timestamp and uses refclock_process_offset(). I
was considering removing refclock_process() when I added the rollover
workaround to the trimble driver, but then I read this:
https://bugs.ntp.org/show_bu
>Hal Murray hmurray at megapathdsl.net
>Sun Jan 28 07:37:05 UTC 2018
>
>There is another approach that might be interesting. Use a loopback on some
>modem control signals or gpio pins. Then a test program can grab the time,
>flap the pin, and grab the time, then read the PPS time.
>
>Things may
>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
I modified the pps_parport Linux Kernel Module to produce pulses in
addition to receiving them. It's different from the existing
pps_gen_parport in a few ways:
*works with multiple parallel ports
*timestamps assert or clear edge instead of just asserting at the top
of the second without timestampi
>> Is there any point to it without the matching kernel driver?
>
>Has anybody tried asking for the "echo" from user space?
>
>That is:
> grab time
> raise modem signal
> grab time
> read timestamp over serial port
>
>If you precede that with
> grab time
> lower modem signal
>I think that wil
17 matches
Mail list logo
