Yo Ruslan!

On Mon, 13 Feb 2017 11:07:49 -0500
Ruslan Nabioullin rnabioullin@gmail.com wrote:

#2 will have a lot higher jitter than #1.  On a #2 you can expect
500 micro second best timing.  On a #1 you can get to 1 micro second.

On a RasPi using GPIO you can get to 500 nano second.  Data
available on request, but better on the devel@ntpsec.org list.

RGDS
GARY

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com  Tel:+1 541 382 8588

    Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin

Pretty dramatic difference between a "real" serial port and USB.  Like two
orders of magnitude or more.

If you computer lacks a serial port, just buy a new computer.  The
Raspberry Pi or the like costs about $40.  But the money you save on
electric power will pay off that $40 in less than a year.

Why is this?  the serial port has a pin that is tied to an interrupt.  If
you read the code associated with that interrupt it is like maybe 4 or 6
lines of C and VERY simple.  USB on the other hand is packetized.
Nothing happens on till a block of data comes in and then it is quite
complex so the time from the pin going active to the internal counter being
sampled is quite variable  I said "two orders of magnitude"  it might even
be three orders.

On Mon, Feb 13, 2017 at 8:07 AM, Ruslan Nabioullin rnabioullin@gmail.com
wrote:

--

Chris Albertson
Redondo Beach, California

On 14/02/2017 12:24 AM, Chris Albertson wrote:

Great for picking up the PPS.
Know of any with an Ethernet port, preferably two, that aren't run from
a USB controller?

Michael

Hi

A direct port might be a +/- 100 ns sort of thing most of the time and a +/-10 us
thing every so often under some OS’s. Most desktop operating systems are not
designed to prioritize random pin interrupts. A dirt cheap MCU coded with a few
(hundred) lines of assembly code may be a better option than a typical desktop.
Complicating this further is the degree to which some OS’s can be directly or
indirectly optimized. Install this package and it all goes nuts. Install that package
and not much happens ….

Bob

On 14/02/2017 7:26 AM, Bob Camp wrote:

Hence, wouldn't Best Practice be boxes loaded with only the bare OS and
software for the time-related tasks?
As in:

• a dedicated machine/box for unencumbered acceptance of PPS, and
• for systems with a business need, a dedicated NTP server/box
  disciplined by the PPS source (with dedicated communication), while
  maintaining internet NTP sources as backup for when the PPS source fails?
  Is there a better way?
  Other considerations?

Michael

Here is a something that could work.  It has a real serial port and you
could add more ethernet controllers, uses very little power and cost only
$60.
www.newegg.com/....
https://www.newegg.com/Product/Product.aspx?Item=N82E16813157497&cm_re=j1900-_-13-157-497-_-Product

There are other boards like this that use the same J1900 CPU.  I'm
thinking about using this as th machine tool (milling machine) controller.

On Tue, Feb 14, 2017 at 4:26 AM, Bob Camp kb8tq@n1k.org wrote:

--

Chris Albertson
Redondo Beach, California

Hi

That would be one approach.

It depends on what you are trying to do. If the objective is to replace a piece of test gear
logging 100% of your events at the 100ns level, the computer likely will not measure up. If the objective is to run
NTP at the 100 us level, there are a lot more things you can get away with. NTP is designed from the
ground up to be quite tolerant of various issues.

Bob

If you find yourself in a situation like this -- where your timing seems to improve the less load you have -- that's a sure sign that you're doing the timing wrong in the first place.

Best practices are to do 1PPS timing in hardware using capture registers (which almost every microcontroller has). That way there's a separation between the critical act of making a timing measurement from the non-critical act of delivering the measurement result the operating system. You still use interrupts -- but now the purpose of the interrupt is simply to indicate that a fresh measurement result is ready, rather than the interrupt itself being the measurement. The result is that the time stamp / capture register method is immune to interrupt latency and system load issues.

Best practices number two are to replace the crystal on the motherboard with a TCXO or OCXO. Then, with the help of NTP, your computer is finally acting like a GPSDO.

/tvb

Something like this would make a great NTP server.
https://www.digikey.com/products/en?keywords=P0286-ND

Too bad they didn't include a PTP 1588 capable PHY...

On Tue, Feb 14, 2017 at 12:33 PM, Chris Albertson <albertson.chris@gmail.com