[time-nuts] Set time on Solaris computer from HP 58503A

Bob Camp kb8tq at n1k.org
Sun Dec 14 10:44:58 EST 2014


> On Dec 14, 2014, at 8:38 AM, Dr. David Kirkby (Kirkby Microwave Ltd) <drkirkby at kirkbymicrowave.co.uk> wrote:
> On 14 December 2014 at 12:39, Neil Schroeder <gigneil at gmail.com> wrote:
>> Based on my recent testing - including Solaris - you will be better off
>> with the Internet unless your USB adapter is far better behaved than the
>> several I have here
> The USB -> serial adapter I have is an Keyspan USA-19HS
> http://www.tripplite.com/high-speed-usb-to-serial-adapter-keyspan~USA19HS/
> I bought that one, as it was officially supported by Sun. I also have
> another one somewhere - forget which model. Again that was officially
> supported by Sun.

There are some long and detailed threads back in the archives about just how USB works and what this does to timing. 

Simple / quick summary:

To do a proper / accurate time transfer, an edge from a source needs to be accurately clocked into the target machine. Any delay in this process is a bad thing. There are a lot of places delay can come from. 

USB is a packett / block transfer protocol. It gets it’s speed from sending a lot of stuff all at one time. When a serial USB sees a long string coming in, it formats it into a single block and transfers the whole thing in one bus transaction. That’s perfect for most things (commercial or consumer). The device gets on the bus and off the bus quickly with minimum overhead involved.

Waiting on something like a pps string is a real bad idea. Your serial port is running at a rational baud rate. At 9600 baud, each character time you delay messes up the PPS timing by almost a millisecond.  The PPS ID strings are many characters long. The impact on pps timing could (and often is) quite major. Even in the “best case” of sending the data one or two characters later, the pps is not very accurate. In the “worst case” it’s 10X or maybe 100X less accurate still. 

Some numbers:

1) PPS out of your GPSDO is likely < 100 ns all the time. Most of the time (one sigma) it’s in the 10 to 30 ns range depending on which box you are running. 

2) One character at 8N1 is 10 bits. At 9600 baud that’s 1.04 ms. It’s unlikely the USB sends in less than 1 character time.

3) A normal string is in the 30 to 40 characters range. A normal USB will buffer for 30X the character time ...

NTP via ethernet, with well chosen servers, can get you down to < 10 ms timing on you machines. It’s reliable and fairly easy to set up. The other alternative is to get the PPS edge into the machine in a more direct manner than USB. Yes I have a pile of SUN boxes, they often don’t come with all the i/o chards you might like to have….

Another alternative (and thus it’s popularity on the list) is to set up something small and light weight as a dedicated NTP server on your local LAN. That gets the timing issues of your local connection to the internet out of the NTP equation. You can  get down under 10 us with a setup like that. The result may be better than your ability to time an edge on the SUN box, due to all the other overheads involved there. It’s also a nice stand alone project that is far less likely to mess up your main machine. The boards commonly used are < $100 and some are much cheaper than that. 


> Both have worked for industrial control applications, whereas I gather
> some cheap ones are only suitable for common consumer devices.
> In any case, it will be more fun & educational to use the GPS
> receiver. To be honest, I don't need great accuracy. I only bought the
> unit as a frequency standard - the clock functionality is not
> important to me, but if I can have a bit of fun playing around with
> it, then I will.
> Dave
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

More information about the time-nuts mailing list