RE: ublox refclock
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 without KPPS it is inferior at timekeeping. >> >> If the guy that wrote it wanted to work on it under the NTPsec umbrella >> that would be good. A little guidance and the guy that wrote that could >> be very useful to NTPsec. >> >> Without that guy, or someone interested in being that guy. I'd pass on >> that driver. I'm not personally interested in upgrading that software to >> have the smarts that gpsd already does about the u-blox and KPPS. > >I left an issue on his tracker about merging to upstream. If he responds >I will try to bring him into the fold. If he does not, from what you say there >os not much loss hrere. >-- > http://www.catb.org/~esr/";>Eric S. Raymond Thanks for the interest in the driver. It's the same one I posted in issue 499: https://gitlab.com/NTPsec/ntpsec/issues/499#note_133458690 I have been busy with my day job this year, but I will have some free time starting next month. I'll update my fork to the latest upstream this weekend. I have also tested the driver with a ZED-F9T for a few months now (with the new version posted on issue 499), and the performance is even better than what I reported on the issue 499 thread with the M8T -- And the F9T did not show any of the strange issues that I reported having with the M8T. I will attach some ntpvis plots of the F9T to the issue 499 thread. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
RE: ublox refclock
>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 incorporation in the ntpsec tree? >> (AFAIK this is a 'straight' refclock; no extra lines needed besides >> rx/tx and pps) > >I just took a quick look at refclock_ubx.c > >An interesting start, but followup messsages today on the list are >assuming this driver does things that it does not do. > >1) It does not, ever, config the u-blox. It does not, ever, write to >the u-blox to query it. > >Configuration is up to the user. There are so many configuration options, I think it's best to leave it up to the user. It wouldn't be difficult to send a generic configuration to the module on driver startup, however. >2) It decodes UBX-TIM-TM2 (Current time) and UBX-TIM-TIMELS (for the >leap second). Then does some limited sanity checking. > >It will fail to catch known u-blox time failure modes. Could you point me towards some documentation for this? I took a look at the gpsd-3.16 driver but I failed to spot anything obvious. I did notice some very intermittent oddities with the M8T (as mentioned in the issue499 thread), but the v0.02 driver was able to ignore the invalid data. I did not see any problems with the F9T. When testing, I configured the modules to use only GPS without SBAS. I did see a few mentions of SBAS timing problems, but the ublox docs do mention it is not recommended so I've always disabled it. >3) It does some interesting things with TIO that the comments claim >improves the time stability. But it does not use KPPS which would >just work better and simpler. > >Anything that uses KPPS will work much better. The whole reason for this driver is for an experiment to use only the module's EXTINT input for timing. I didn't try, but gpsd with shmem should take care of the case when PPS is desired. >4) It does not look at qErr, which combined with KPPS, might eventually, >theoretically, lead to better time. When CPU time quantization gets better. >From testing on a fast machine with the oncore driver, I have seen average jitter values of under 200ns so it may already be possible to notice an improvement with sawtooth correction, at least for modules with slow clock speeds. I may want to do a quick modification of the oncore driver to test the VP's @@En message. I've seen mention of the VPs correction values being +-52ns so it should be noticeable. For the M8T, I don't remember seeing correction values much beyond 10ns just watching in ucenter, so I think we will need to wait a while longer before correction could make a significant difference with modern modules. >In summary, not an improvement on current u-blox best practice. Maybe, >eventually, an improvement, with some work (configuration, KPPS, etc.). Even if the driver was fully-featured I'm not sure if anyone would use it when gpsd has already been in use for so long -- unless its timemark functionality is needed instead of PPS. I will set up a test using gpsd and the shm driver as soon as possible. I just noticed that I've been looking at an old version of gpsd, so I'll check the newest release over. I also see that there is a refclock_gpsd driver. I think I may have used gpsd as a refclock before, but I don't remember using that driver. The gpsd guides I've seen are using shared memory, so I will start with shm first. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
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 attached indicate a problem with my setup. Every 2 to 3 >hours a one-second offset appears on SHM(1). There could be several >problems, so I made a few changes at once to return to collecting data >as soon as possible: I didn't notice the post on the User's list which mentioned this problem: >>> > On Wed, 4 Sep 2019 17:09:04 +0100 >>> > shouldbe q931 via users wrote: >>> > >>> > > I saw something odd in ntpviz, which is that the server offset and >>> > > server jitter on SHM(1) goes to 1 second. I thought it would be >>> > > prudent to check another ntpviz, and https://pi3.rellim.com/day/ >>> > > shows similar. I'm still showing the same issue after the changes I made, so I'll try from the gitlab master version. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
RE: --disable-fuzz
>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 past the parser. I think "tinker tick 0" may disable >fuzzing for with-fuzz code, but I didn't notice that until I was well into >adding ifdef-s. > >It will be interesting to see if anybody can notice any difference. > I noticed a significant improvement with the Ublox driver. Please see the data posted in the Issue 499 thread: https://gitlab.com/NTPsec/ntpsec/issues/499 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Anybody taking care of refclock_trimble?
>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 after triggering since RAND_bytes is slow */ >get_systime(&pp->lastrec); > > >Back in December, I fixed get_systime to use random() rather than ntp_random() >which calls RAND_bytes(). When I added that comment I found that RAND_bytes() was taking hundreds of nanoseconds on the same system that was taking the classic version's local random less than 100ns. Since this is no longer the case, I'll check the performance of the new method -- but it should be safe to remove the comment. I revisited that area when the --disable-fuzz option was added in order to experiment with also removing fuzzing from the refclocks. I got a very significant reduction in jitter when switching from get_systime() to clock_gettime(). I'll create an issue on the tracker this weekend to discuss the possibility of switching the Trimble driver to clock_gettime(). I would also like to propose changes to the driver that will improve performance with unstable system oscillators. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Anybody taking care of refclock_trimble?
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 were added to fudgetime1. The "g" suffix was effective for the Oncore driver, so I think I'd rather pull out the rollover workaround I added to the driver and re-test with the generic one before making any other changes. > >> I revisited that area when the --disable-fuzz option was added in order to >> experiment with also removing fuzzing from the refclocks. I got a very >> significant reduction in jitter when switching from get_systime() to >> clock_gettime(). > >Did you try get_systime() and --disable-fuzz? > >That should do the same thing. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Testing
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 FreeBSD BE64: Sun Ultra 5 with v9os I also did some testing on a Power Mac G5 with 10.5 using MacPorts and its patches, but I lost interest when I found that MacOS doesn't have ntp_adjtime. I tried 14.2 on a Mac Pro 5,1 and there is still no ntp_adjtime support so the performance is poor. Both versions seem to lack a PPS line discipline. Very few serial port expansion cards are usable. Previously I was testing the driver with Solaris 11.3 on a T5220, but I wanted to stay current when 11.3 "premier support" was discontinued so I set up 11.4 CBE on a T4-1. It was working, but the machine is so loud and power-hungry that I switched to a Sun Ultra 5. I couldn't get a build environment set up with Solaris Express (which was the last version that was compatible with the Ultra 5) so I had to move on to the OpenSolaris forks. The only one that I could get a SPARC build environment working with was v9os. Neither v9os or 11.4 support MOD_NANO, so the performance isn't that great. For 11.4 with Solaris Studio, I had to make a change to V4_SIZEOF_RESTRICT_U and V6_SIZEOF_RESTRICT_U to use the ALIGNED_SIZE macro because I was getting unaligned access errors when accessing the restrict list (a member of restrict_u in ntp.h was changed sometime after the 1.2.2 release). I have added support for the Acutime 360 on my fork, but I need to finish up testing and clean up the documentation before I make a merge request. With the recent mention of a possible leap second deletion I may want to do a new set of tests with a simulator, but it will take a while before I can get to it. Some of the Trimble receivers have no direct indication of the leap second direction, so it could be exciting -- it might be best to remove leap notification support for those. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: I think we can drop the Jupiter driver.
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 megapathdsl.net >Wed Apr 26 00:16:58 UTC 2017 > >>> You could use it as an example of how to do it right. >> Er, *what*? > >Fix the code. Do it right and cleanly. Add a comment pointing to the page >with a full description of the whole mess. Have that page point back there >as an example of how to fix the GPS week roll over problem. > >It's not as simple as > if (week < xx) week += 1024 >That only works for 20 years. You need something like: > while (week < xx) week += 1024 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Does anybody have a sample of a NMEA device with the 1024 week bug?
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 code in the driver fixed the timecode timestamp from 1999-09-10 to the proper date. >Gary E. Miller gem at rellim.com wrote: > >Yo Mark! > >On Wed, 26 Apr 2017 01:09:14 + >Mark Atwood via devel wrote: > >> How hard is it to write a fake NMEA device simulator in Python, and >> use Linux IPC control magic to have it appear at a fake serial device? > >Not how hard, but who wants that at the top of their list. I think you >have some free time now? > >All for an obsolete device that we do not think anyone has? > > > >RGDS >GARY ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec on MIPSbe
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 build that I didn't see with an amd64 machine ("cast
increases required alignment of target type").
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: devel Digest, Vol 19, Issue 20
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.73875...@spidey.rellim.com> >Content-Type: text/plain; charset="utf-8" > >Yo Trevor! > >I have a problem with your MR 422 which just got pushed live. Concerning, >but fixable. > >For some reason gitlab will no longer let me in to that MR page... > >The reason gpstolfp.c was in libparse instead of libntp is because >libparse it optional and libntp is not optional. Many people build >ntpd with no refclocks, and now they will have to carry all this >extra code that is unused. > >I see two solutions: > >1. move it back to libparse, so it is again optional. > >2. add a lot of #ifdefs to the new code in libntp so compilation > is optional. > >RGDS >GARY ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Fw: ntpsec | build failed today on server - but without issues in the past (#320)
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 obtain the timecode, the factory default configuration of the Palisade, Acutime 2000 and Acutime Gold will no longer work with fudge flag2 active. That flag is normally used for troubleshooting with those receivers, so I did not test it. It's possible to configure them so they will work, but the configuration can't be done without user intervention. >Yo All! > >Looks like MR 422 broke some builds. Trevor, can you look at this? > >RGDS >GARY >--- >Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > gem at rellim.com Tel:+1 541 382 8588 > > Veritas liberabit vos. -- Quid est veritas? >"If you cant measure it, you cant improve it." - Lord Kelvin > > >Begin forwarded message: > >Date: Sat, 27 May 2017 07:44:39 + >From: "di. hans mayer" >To: gem at rellim.com >Subject: Re: ntpsec | build failed today on server - but without issues >in the past (#320) > > >Hint: It compiles fine with the standard configuration > >./waf configure > >there must be something wrong with the refclock config > >./waf configure --refclock=gpsd,generic,shm,pps,nmea,local > > > >// Hans > ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Verified - ntpd ignores the year part of refclock timestamps
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_bug.cgi?id=417 Where the reasoning behind clock_panic and not using the year in refclocks is touched on. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Additional pps-gpio
>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 get complicated by locks in the kernel. If they get too ugly, we >could use two machines and ping-pong back and forth. It would take a bit of >work to merge the data and correct for the time offset between the two >systems. That would work better with identical systems. > > > >> Well, that assumes you do have a serial port available that even has these >> signals connected. > >I'm interested in both GPIO and modem signals on PCs with real serial ports. >I have PCs with multiple serial ports. It may be easier for me to work with >them rather than learn how to drive the GPIO pins on a Raspberry Pi. If you're also going to test on a PC, you might be interested in a Linux parallel port PPS driver I modified a while back to add low-latency loopback echo and a mode that uses polling instead of interrupts for pulse capture. Also, on load the driver measures IO speed. Total capture latency can then be estimated with an external time interval counter. I just placed the driver on github at https://github.com/retroman/pps_parport_polled I will eventually upload some measurements I took with various machines. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
RE: [ntp:hackers] u-blox reference clock driver
>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 took one day to get in >> > git head. >> >> The only thing that linuxpps would be the correct target for is >> getting the PPS echo facility to do something useful with GPIO (and >> maybe serial, but that's a whole 'nother driver to consider). > >Yes. But until we have a kernel driver, the rest is pointless. > >> > Lukas told me, privately, he had already submitted it the the >> > LKM folks and been overwhelmed by the changes they requested. So >> > the patch will clearly need work. >> >> That does not surprise me, given it's all a pretty ugly hack that >> really only works for the one single thing he's needed it for. I'm >> not blaming him, just a reminder that getting things upstream takes a >> lot more apple polishing. > >Agreed. Lukas made a good start, but more to do. > >RGDS >GARY I added PPS output to the linuxpps parallel port module a while back. I intend to use it to trigger the timemark input on the Trimble Palisade/Acutime with more accuracy than can be done in user space with the current driver. I ran out of free time, though, so I have been unable to proceed. I also added a polled mode to work around interrupt latency, along with a low-latency echo output. It can be found at https://github.com/retroman/pps_parport_polled ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
LKM Timemark Driver for PC parallel ports with refclock_trimble now available for testing
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 timestamping *pulse timing is adjustable *assert and clear data values are configurable It is able to produce a pulse as narrow as 800ns with my hardware, a PCIe parallel card in a fast amd64 machine. The timestamps are accessed through the PPSAPI as normal. I still need to make some documentation, but all the load-time parameters are described in the driver source. I also added a few optional features to the standard input mode: * interrupt line polling to eliminate interrupt latency * local echo for measuring capture latency with an external counter * interrupt masking to allow operation with ports that have level-triggered interrupts I finally found some time to get the refclock_trimble driver in a usable state for testing the modified pps_parport driver. It's available at: https://gitlab.com/trv-n/ntpsec Usage instructions are located near the bottom of the docs/driver_trimble.txt file. Only the ntpd/refclock_trimble.c and docs/driver_trimble.txt files have been modified. I'm currently testing with an Acutime 2000. If anyone would like to try the driver out, there are several 2000s available on everyone's favorite auction site. Unfortunately the RS232-to-RS422 converter (37071-00) is expensive, and the cable connecting the two isn't readily available. I ended up having to make a converter and cable. I'll make some information available on the converter eventually, but it's pretty easy to build from the information in the receiver manual. The Trimble Thunderbolt does not have an event input, so it can't be used for testing the kernel driver. An EndRun Technologies Praecis Cf/Ct/II can be used to test, but a custom cable and possibly a level shifter will need to be built. I have a Cf that I'll be testing soon, along with a Palisade and Acutime Gold. Since it was easy to add support for the kernel driver into the trimble refclock driver, it may be worthwhile to add it to other drivers, but I'm pretty sure the only other non-trimble driver that has support for receivers with timemark-type inputs is the one that is being worked on by MLewis. I'll take a look at it and see if it is using the PPSAPI in a similar way -- it may be possible to use the modified parallel port kernel module on PC hardware with that refclock driver as well as the GPIO-type kernel driver he's working on. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
ublox refclock
>> 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 will warm up most of the cache. Another interesting experiment >would be to see how much of a difference that makes. The trimble driver already uses user-space for its time mark output (the HW_poll function). It works quite well: on my test machine (50ns precision, ovenized oscilator) a Praecis Cf has a jitter of less than 30ns, even with a 40k packets-per-second load. I don't remember pre-fetching a timestamp making much of a difference when I was testing changes to the driver. HW_poll does not echo a PPS input, so its alignment to the top of the second is arbitrary. Attached is an ntpvis summary csv of a run I just finished on my test machine while unloaded. Unit0 is a Praecis Cf with usermode timemark, and unit1 is a Palisade using the timemark kernel module I am developing. I am making another run now with the Palisade using the usermode timemark for comparison. Currently my kernel module has the same arbitrary-alignment problem as ntpsec's HW_poll, so it's not quite ready for general use. trimble-lkm-summary.csv Description: Binary data ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
