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