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 _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel