frequency tolerance: 500

[Achim Gratz]

Udo van den Heuvel via devel writes:
>> How is the GPS connected and how do you get the PPS in?
>
> Same as it ever was:

How are we supposed to know that if you don't say it?

> Garmin GPS18X getting power from USB, PPS is coming in on DCD I believe.

So is this a USB serial or is it an LVC model and you use a "true"
RS232C port?  How do you create the necessary PPS device?  If you use a
serial device, have you set it to low_latency?  I haven't seen one of
these in person, but I believe the serial port for Ryzen systems is part
of the SuperIO, not the chipset itself.  There might be some BIOS
settings you need to tweak to get optimal performance.

> When I switch the GPSses (I have two) the GPS works fine in the other
> box. So something on this box is hosed and I ruled out wiring, I guess.
> I reset the GPS configuration, I changed PPS pulse length, etc.

What's that second system you talk about that seems to work?

> And I did not change anythign when this started, I simply rebooted into
> a different kernel.

Well, forget about the kernel for a moment unless you can actually name
the exact version transition that broke things for you (in which case
you would need to figure out which of the changes between those two
versions is responsible).  I suspect you've been relying on some
defaults which have changed, but that's just a guess.

> refclock nmea unit 0 mode 7 flag3 0 flag2 0 flag1 1 time1 0.00000006 time2 0.260 baud 4800

If you left the default message configuration on, then 4800 baud is way
too slow.  I don't think that particular model has any problems with the
highest configurable baud rate (should be 38400 I think).  Also, just
configure the one message you want ntpd to accept (most likely $GPRMC as
the Garmin doesn't have $GPZDA) and tell ntpd to only use that (mode 1
or, if you increased the baudrate to 38.4k, mode 49).  Reading multiple
messages into ntpd is useless, it only ever looks at the first one
anyway.  Your time1 configuration corresponds to 60ns, so it is almost
certainly useless at this point.  I would expect around 500µs to 1ms for
this parameter.  The time2 value is likely way too low for your current
setup, but could be correct for a higher baudrate.  Last but not least
if you get the PPS in via a serial line, you need to configure ntpd to
look for the "clear" edge (flag2 1).  If you are unsure, install the
pps-utils package or whatever your distribution calls it and use ppstest
to see which edge is closer to the second.  Play around with the PPS
width to see if it moves in the right direction to be sure.  Now,
sometimes the clear edge has a lot more jitter than assert if the
hardware has to poll for that edge instead of using interrupts.  If so, you
can try to reduce the PPS pulse width to the minimum that still
registers correctly, switch to the other edge and then adjust the time1
value by the PPS pulse width.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada