high precision tracking: trying to understandsudden jumps - NTP

This is a discussion on high precision tracking: trying to understandsudden jumps - NTP ; >>> The basic idea is to do the time stamping in hardware deep in >>> the network adaper. That avoids lots and lots of jitter. > >>Yes, PTP can yield an accuracy better than 100 ns if both the NICs ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 29 of 29

Thread: high precision tracking: trying to understandsudden jumps

  1. Re: high precision tracking: trying to understand sudden jumps


    >>> The basic idea is to do the time stamping in hardware deep in
    >>> the network adaper. That avoids lots and lots of jitter.

    >
    >>Yes, PTP can yield an accuracy better than 100 ns if both the NICs at the
    >>clients and the server support hardware timestamping of sent/received PTP
    >>packets.

    >
    >I am still confused. To timestamp you have to read the computer's clock.
    >That is a software operation-- reading the counter in the cpu, translating
    >to time, returning the result through the kernel, etc. That has all kinds
    >of variable latencies,etc. I am having trouble seeing 100ns. Also seeing
    >the PPS from the hardware clock and its interrupts. Or are you replacing
    >all of the hardware and software of the system? (new kernel, new interrupt
    >system, new nics, etc)


    You can build a clock into the network adapter and sync it up to the
    system clock.


    --
    These are my opinions, not necessarily my employer's. I hate spam.


  2. Re: high precision tracking: trying to understand sudden jumps


    >>The basic idea is to do the time stamping in hardware deep in
    >>the network adaper. That avoids lots and lots of jitter.

    >
    >It avoids some jitter. Does that mean that you have to have special
    >hardware (special network cards ...


    Yes, and so far they are all expensive.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  3. Re: high precision tracking: trying to understand sudden jumps


    >Yes, PTP can yield an accuracy better than 100 ns if both the NICs at the
    >clients and the server support hardware timestamping of sent/received PTP
    >packets.
    >
    >On the other hand, also *every* network node between the PTP endpoints has
    >to be PTP-aware and compensate the packet delay it introduces, so you will
    >probably only get full PTP accuracy in your local network where you have
    >control over all the equipment.


    Suppose I have PTP network adapters but vanilla switches and my
    network is lightly loaded.

    Can I filter out the delays in the switches by sending 10 packets
    and throwing out the ones with long delays? I'd expect the
    timings to be a cluster around the case where there was no delay
    in the switch and a tail for the ones that encountered some
    delay. I think it would be easy to filter out that tail.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  4. Re: high precision tracking: trying to understand sudden jumps

    hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:


    >>>> The basic idea is to do the time stamping in hardware deep in
    >>>> the network adaper. That avoids lots and lots of jitter.

    >>
    >>>Yes, PTP can yield an accuracy better than 100 ns if both the NICs at the
    >>>clients and the server support hardware timestamping of sent/received PTP
    >>>packets.

    >>
    >>I am still confused. To timestamp you have to read the computer's clock.
    >>That is a software operation-- reading the counter in the cpu, translating
    >>to time, returning the result through the kernel, etc. That has all kinds
    >>of variable latencies,etc. I am having trouble seeing 100ns. Also seeing
    >>the PPS from the hardware clock and its interrupts. Or are you replacing
    >>all of the hardware and software of the system? (new kernel, new interrupt
    >>system, new nics, etc)


    >You can build a clock into the network adapter and sync it up to the
    >system clock.


    And how do you sync it up to the system clock without going through the
    kernel, etc? Ie, I have a clock on my gps receiver that is good to 100ns.
    It links to the system clock via interrupts and ntp. You have to do
    something like that if you are going to sync the clock on your nic to the
    system clock as well. Ie, I see no advantage to this procedure over putting
    in a cheap gps clock on each of the computers and just using that ( or
    running a buffered PPS line from one gps receiver to each of the machines
    (using some of the spare lines in a Cat5e cable if need be).Sure sounds
    cheaper than special nic cards with high accuracy on board clocks!




    >--
    >These are my opinions, not necessarily my employer's. I hate spam.



  5. Re: high precision tracking: trying to understand sudden jumps

    hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:


    >>Yes, PTP can yield an accuracy better than 100 ns if both the NICs at the
    >>clients and the server support hardware timestamping of sent/received PTP
    >>packets.
    >>
    >>On the other hand, also *every* network node between the PTP endpoints has
    >>to be PTP-aware and compensate the packet delay it introduces, so you will
    >>probably only get full PTP accuracy in your local network where you have
    >>control over all the equipment.


    >Suppose I have PTP network adapters but vanilla switches and my
    >network is lightly loaded.


    >Can I filter out the delays in the switches by sending 10 packets
    >and throwing out the ones with long delays? I'd expect the
    >timings to be a cluster around the case where there was no delay
    >in the switch and a tail for the ones that encountered some
    >delay. I think it would be easy to filter out that tail.



    ntp already does. It throws away 85% of the packets it gets, keeping only
    the roughly 1/8 of them with the shortest round trip times (a real waste
    of data I think but it certainly solves your problem).



  6. Re: high precision tracking: trying to understand sudden jumps

    Bill,

    Unruh wrote:
    > Martin Burnicki writes:
    >>Yes, PTP can yield an accuracy better than 100 ns if both the NICs at the
    >>clients and the server support hardware timestamping of sent/received PTP
    >>packets.

    >
    > I am still confused. To timestamp you have to read the computer's clock.
    > That is a software operation-- reading the counter in the cpu, translating
    > to time, returning the result through the kernel, etc. That has all kinds
    > of variable latencies,etc. I am having trouble seeing 100ns. Also seeing
    > the PPS from the hardware clock and its interrupts. Or are you replacing
    > all of the hardware and software of the system? (new kernel, new interrupt
    > system, new nics, etc)


    Yes, maybe I've been a little bit too unspecific here.

    Those timestamps are taken from a local oscillator, e.g. on the NIC board,
    and that oscillator can be disciplined with the mentioned accuracy.

    Most of those devices also contain a hardware PPS output, so you can use an
    oscilloscope to compare the PPS output of the PTP slave to the PTP output
    of the PTP grandmaster, and this is where you can see which accuracy you
    can get using the PTP protocol, and you can also see that you may not get
    that accuracy if you use switches which are not PTP-aware.

    BTW, we've made some tests and could see that you can yield the same
    accuracy with NTP and hardware timestamping.

    A different story is of course how you get the accurate time from the NIC's
    oscillator/counter to the kernel's system time.

    This introduces the latencies you mentioned, and those latencies occur
    regardless of whether you are using a NIC with timestamp counter, or GPS
    PCI card, or even when evaluating an incoming PPS signal.

    The latter also depends strongly on the operating system, i.e. the
    resolution of the system clock (1 microsecond or better under most
    Unix-like systems, about 16 milliseconds under Windows, except Vista).

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  7. Re: high precision tracking: trying to understand sudden jumps

    Unruh wrote:
    > hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:
    >>You can build a clock into the network adapter and sync it up to the
    >>system clock.

    >
    > And how do you sync it up to the system clock without going through the
    > kernel, etc?


    Maybe it's better to do it the other way round, i.e. sync the system clock
    to the NIC's timestamp counter.

    > Ie, I have a clock on my gps receiver that is good to 100ns.
    > It links to the system clock via interrupts and ntp. You have to do
    > something like that if you are going to sync the clock on your nic to the
    > system clock as well. Ie, I see no advantage to this procedure over
    > putting in a cheap gps clock on each of the computers and just using that
    > ( or running a buffered PPS line from one gps receiver to each of the
    > machines (using some of the spare lines in a Cat5e cable if need be).Sure
    > sounds cheaper than special nic cards with high accuracy on board clocks!


    Just like an NTP server a PTP/IEEE1588 grandmaster can synchronize a huge
    number of clients. Depending on the application this can either be the
    "official" UTC time, or just the "same" time for all devices.

    The target for PTP is more in industrial applications, where you have a
    dedicated network environment and more and more embedded devices which can
    be synchronized with high accuracy.

    For example, the new LXI standard (Lan EXtensions for Instrumentation, see
    http://en.wikipedia.org/wiki/LXI) which is a LAN-based successor to the old
    GPIB bus, explicitely uses PTP/IEEE1588 to time-trigger measurements
    accurately in spite of network latencies.

    There are now NIC chips available which support PTP timestamping, and in
    many measurement instruments there is a good oscillator which can be used
    both for time stamping and implementation of the system clock. Those
    devices normally have special printed circuit boards and dedicated software
    which supports that on-board hardware.

    So this is different from using PTP to synchronize a standard PC where you
    don't know which OS or version of an OS is running, and which types of
    hardware (e.g. NICs) are installed, and how to synchronize the system time
    to the counter chain on a PCI card or whatever.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  8. Re: high precision tracking: trying to understand sudden jumps

    Hal Murray schrieb:
    >> Yes, PTP can yield an accuracy better than 100 ns if both the NICs at the
    >> clients and the server support hardware timestamping of sent/received PTP
    >> packets.
    >>
    >> On the other hand, also *every* network node between the PTP endpoints has
    >> to be PTP-aware and compensate the packet delay it introduces, so you will
    >> probably only get full PTP accuracy in your local network where you have
    >> control over all the equipment.

    >
    > Suppose I have PTP network adapters but vanilla switches and my
    > network is lightly loaded.
    >
    > Can I filter out the delays in the switches by sending 10 packets
    > and throwing out the ones with long delays? I'd expect the
    > timings to be a cluster around the case where there was no delay
    > in the switch and a tail for the ones that encountered some
    > delay. I think it would be easy to filter out that tail.



    Yes, that is possible. The main problem with vanilla switches is the asymmetric
    delays you get when the (store-n-forward) switch starts to queue packets due to
    higher network load. This is a rare occurence in lightly loaded networks.

    The PTP standard (IEEE1588) describes how a client (called slave in PTP
    terminology) finds out the offset between his own clock and the servers
    ("master") clock. It does not specify what you do with this offset, i.e. you can
    step your clock or apply small corrections in order to keep things running
    smoothly. There is nothing that prevents you from applying filters and
    statistics on the offset values before adjusting your clock.

    If you want to play around with PTP, you can get a free (software-only) version
    at Sourceforge: ptpd.sf.net

    The developers of this implementation state that "PTPd should be able to
    coordinate the clocks of your computers within tens of microseconds", which is
    around the performance of ntpd. As Martin already said, you can get NTP to be as
    accurate as PTP if you add hardware timestamping and you can get PTP to be as
    accurate as NTP by taking the hardware timestamping away from it.


    Best Regards,
    Heiko

  9. Re: high precision tracking: trying to understandsudden jumps

    David Woolley wrote:
    > starlight@binnacle.cx wrote:
    >> The generic version of 'ntpd' has some sophisticated code that


    >>
    >> handles interpolation. See the source. Power management is


    >


    > I know that. But the problem is that normal applications just get a


    > more accurate time for the most recent tick, but still don't see any


    > times between ticks.
    >


    >> Pings are consistently 400 microseconds and 'ntpq -p' reports 800


    >


    > Which is excessive for 1GHz network doing essentially nothing but NTP.
    >


    >> probably have make use of PTP (precision timing protocol).
    >> Still très expensive.

    >


    > I assume by PTP you mean ethernet cards that extract a timestamp with a


    > very low latency. I doubt that this will help with lost interrutps. If


    > you really want extreme accuracy for applications you need to:
    >


    > 1) use hardware that maintains a high resolution time completely


    > independent of the software and is directly readable by application code


    > (I'm not sure if Windows supports such direct reading).
    >



    I suspect that what is being discussed here is IEEE1588 which can

    timestamp packets via the hardware. It requires device driver support

    and a number of other changes to NTP to work with it.

    Danny

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2