usb versus serial for NTP

L

linuxuser2010

Hi All,
Is anyone aware as to why serial connections using PPS generate less jitter than usb connections, when attempting to set up a stratum one server using a gps receiver and ntp?

Thank you.
 
Assuming it's a hardwired serial connection instead of a usb -> serial connection, I would guess that the interrupt path is faster. Serial connections are very basic and as such have less overhead than something really complicated like USB.
 
Thanks for the reply. I've read that usb has quite a bit more overhead than serial due to device drivers, synchronization methods, etc, but the few articles do not go into much detail. Your comment on interrupts will provide another place to begin focusing on. Thanks again!
 
I would be very surprised if you get a PPS signal via USB at all.
The USB receivers I've seen only supply timestamp information via NMEA protocol, which alone does not provide the precision, you're looking for. Considering the fact that most USB receivers contain serial->USB converter chips does not make their precision any better, too.

Your best bet is to get a serial GPS device, which provides a 1 PPS signal (usually wired to the CTS or DCD line).

The last time I looked into this, FreeBSD's PPS API also would work with standard serial ports only, not with USB serial ports like ucom, uplcom, etc.
 
mickey said:
The USB receivers I've seen only supply timestamp information via NMEA protocol, which alone does not provide the precision, you're looking for.
Click to expand...

<besserwisser> That does depend on what you are using it for. I have a GPS-time source running over USB which completely fulfills my requirements. BUT I don't require more accuracy than is provided </besserwisser>
 
Thanks for the info Mickey. I'll be setting up a stratum one for public use so accuracy is the utmost importance. The gps receiver purchased by the department connects via usb and does not have PPS capabilities.

Thanks for your reply also mix_room. In regards to your ntp.conf setup, do you list additional time sources along with you GPS Receiver for redundancy purposes or to improve accuracy? As I mentioned above, when I list additonal time sources, ntp is disregarding my gps time source as inaccurate and thus removes it from contention (as a false ticker). Any insight into your ntp.conf file and overall configuration would be highly appreciated. Thank you.
 
linuxuser2010 said:
As I mentioned above, when I list additonal time sources, ntp is disregarding my gps time source as inaccurate and thus removes it from contention (as a false ticker).
Click to expand...

That is exactly what I was talking about. The timestamp information alone is quite inaccurate. In other words, a DIY DCF77/MSF radio receiver gives more accurate time. The thing that adds high precision to a GPS time source is the 1 PPS signal, which should at least provide µS precision.
 
linuxuser2010 said:
Thanks for your reply also mix_room. In regards to your ntp.conf setup, do you list additional time sources along with you GPS Receiver for redundancy purposes or to improve accuracy? As I mentioned above, when I list additonal time sources, ntp is disregarding my gps time source as inaccurate and thus removes it from contention (as a false ticker). Any insight into your ntp.conf file and overall configuration would be highly appreciated. Thank you.
Click to expand...

The entire ntp-server which was being fed by the gps-source was a backup. So the usb-receiver was the only one listed. It was only used when I had no connection to the internet. Unfortunately this seems to be a completely different solution than what you had in mind. Perhaps this could be a solution for you to work on - running multiple ntp servers in jails, aggregating them to a pool. Just as a suggestion.
 
Great ideas and insight. It seems like PPS via serial is the way to go. Pooling several servers sounds like a cool project to pursue in the future should I come across some more hardware. Thanks for the replies, this thread has definitely given me some direction.
 
You must log in or register to reply here.
Back
Top