frequency tolerance: 500

[Achim Gratz]

Udo van den Heuvel via devel writes:
> udev.

So, with ldattach?

> rc.local

Use an udev rule again, much easier and more reliable, too.

>>  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.
>
> We have an RS232 PCIe card.

Thanks again for not mentioning which actual model.

> ASRock QC5000M-ITX/PH with same gps connected very similarly.
> Just not on an RS232 card but one of the serial ports of the ITX.

…which ties directly into the chipset and hence has very low latency
into the interrupt system.

>> versions is responsible).  I suspect you've been relying on some
>> defaults which have changed, but that's just a guess.
>
> Sounds reasonable given that the situation is currently normalising
> after switchign the clocksource to hpet. (from tsc)

You should still figure out why TSC is not working correctly.  HPET is
seriously slow on any modern system and Spectre/Meltdown mitigations
have only added to that.

> 4800 works very well when you set it up like this:
> $PGRMO,,2*75
> $PGRMO,GPRMC,1*3D
> $PGRMO,GPGGA,1*20
> $PGRMC,A,42.9,100,,,,,,A,3,1,2,9,30*61

That doesn't tell me anything, I don't have that unit or something else
using the same command set.  But again, you really only want a single
message from the GPS since ntpd doesn't look at anything but the first.
And since it times with the end of the message, configuring messages
that have wildly different sizes is another no-no.  PPS will hide that
as long as it's available.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada