Re: Keeping a VERY accurate time (within a millisecond) - Networking

This is a discussion on Re: Keeping a VERY accurate time (within a millisecond) - Networking ; Ignoramus10032 wrote: > Well, hopefully something cheaper, like an add-on card. When I were a lad... before the dizy days of interwebconnetlandshire... We used to fit a product called a C.A.T. (rugby receiver) into the serial port of the PC. ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: Re: Keeping a VERY accurate time (within a millisecond)

  1. Re: Keeping a VERY accurate time (within a millisecond)



    Ignoramus10032 wrote:

    > Well, hopefully something cheaper, like an add-on card.


    When I were a lad... before the dizy days of interwebconnetlandshire...
    We used to fit a product called a C.A.T. (rugby receiver) into the
    serial port of the PC.

    I've checked the company and they still make the stuff though it's all
    windows specific drivers.
    Might be something of use though..
    http://www.galsys.co.uk/
    HTH
    Pete

    --
    http://www.GymRatZ.co.uk - Fitness+Gym Equipment.
    http://www.bodysolid-gym-equipment.co.uk
    http://www.trade-price-supplements.co.uk
    http://www.water-rower.co.uk

  2. Re: Keeping a VERY accurate time (within a millisecond)

    At Sat, 06 Sep 2008 19:32:49 +0100 "www.GymRatZ.co.uk" <0845.86.86.888@GymRatZ.Gym.Equipment> wrote:

    >
    >
    >
    > Ignoramus10032 wrote:
    >
    > > Well, hopefully something cheaper, like an add-on card.

    >
    > When I were a lad... before the dizy days of interwebconnetlandshire...
    > We used to fit a product called a C.A.T. (rugby receiver) into the
    > serial port of the PC.
    >
    > I've checked the company and they still make the stuff though it's all
    > windows specific drivers.
    > Might be something of use though..
    > http://www.galsys.co.uk/
    > HTH
    > Pete


    If it *still* uses a serial port (RS232) interface, you don't need a
    kernel-level driver, no matter what they tell you about 'windows
    drivers'. You just need a *user mode* program that opens
    /dev/ttyS, and uses termios to condition the port (eg BAUD
    rate, stop bits, parity, raw mode, handshaking protocols, etc.) and
    then you need to just read the data bytes. A simple program can be
    written to dump the bytes to stdout to determine what they might mean.

    >


    --
    Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
    Deepwoods Software -- Linux Installation and Administration
    http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
    heller@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk


  3. Re: Keeping a VERY accurate time (within a millisecond)

    "www.GymRatZ.co.uk" <0845.86.86.888@GymRatZ.Gym.Equipment> writes:



    >Ignoramus10032 wrote:


    >> Well, hopefully something cheaper, like an add-on card.


    >When I were a lad... before the dizy days of interwebconnetlandshire...
    >We used to fit a product called a C.A.T. (rugby receiver) into the
    >serial port of the PC.


    When you were a lad, gps receivers did not exist. They do now. They are
    accurate to submicroseconds. rugby receiver is accurate to many
    milliseconds, depending on how far away you are, what the ionisphere is
    like, etc.


    >I've checked the company and they still make the stuff though it's all
    >windows specific drivers.
    >Might be something of use though..
    >http://www.galsys.co.uk/
    >HTH
    >Pete


    >--
    >http://www.GymRatZ.co.uk - Fitness+Gym Equipment.
    >http://www.bodysolid-gym-equipment.co.uk
    >http://www.trade-price-supplements.co.uk
    >http://www.water-rower.co.uk


  4. Re: Keeping a VERY accurate time (within a millisecond)

    On 2008-09-06, Robert Heller wrote:
    > At Sat, 06 Sep 2008 19:32:49 +0100 "www.GymRatZ.co.uk" <0845.86.86.888@GymRatZ.Gym.Equipment> wrote:
    >
    >>
    >>
    >>
    >> Ignoramus10032 wrote:
    >>
    >> > Well, hopefully something cheaper, like an add-on card.

    >>
    >> When I were a lad... before the dizy days of interwebconnetlandshire...
    >> We used to fit a product called a C.A.T. (rugby receiver) into the
    >> serial port of the PC.
    >>
    >> I've checked the company and they still make the stuff though it's all
    >> windows specific drivers.
    >> Might be something of use though..
    >> http://www.galsys.co.uk/
    >> HTH
    >> Pete

    >
    > If it *still* uses a serial port (RS232) interface, you don't
    > need a kernel-level driver, no matter what they tell you about
    > 'windows drivers'. You just need a *user mode* program that
    > opens /dev/ttyS, and uses termios to condition the
    > port (eg BAUD rate, stop bits, parity, raw mode, handshaking
    > protocols, etc.) and then you need to just read the data
    > bytes.


    That's only going to be accurate to a few tens of milliseconds.
    You're not going to get sub-millisecond timings by reading a
    serial port from a user-space application.

    > A simple program can be written to dump the bytes to stdout to
    > determine what they might mean.


    Determining what they mean isn't an issue. The issue is
    getting sub-millisecond accuracy with a user-space program.

    --
    Grant


  5. Re: Keeping a VERY accurate time (within a millisecond)

    On 2008-09-07, Grant Edwards wrote:
    > On 2008-09-06, Robert Heller wrote:
    >> At Sat, 06 Sep 2008 19:32:49 +0100 "www.GymRatZ.co.uk" <0845.86.86.888@GymRatZ.Gym.Equipment> wrote:

    > That's only going to be accurate to a few tens of milliseconds.
    > You're not going to get sub-millisecond timings by reading a
    > serial port from a user-space application.
    >
    >> A simple program can be written to dump the bytes to stdout to
    >> determine what they might mean.

    >
    > Determining what they mean isn't an issue. The issue is
    > getting sub-millisecond accuracy with a user-space program.
    >


    Why would it be so, if everything is in RAM and no swapping is going
    on?

    For simplicity reasons, I can easily dedicate a computer to this
    application, so that it would run no seriously big loads.

    --
    Due to extreme spam originating from Google Groups, and their inattention
    to spammers, I and many others block all articles originating
    from Google Groups. If you want your postings to be seen by
    more readers you will need to find a different means of
    posting on Usenet.
    http://improve-usenet.org/

  6. Re: Keeping a VERY accurate time (within a millisecond)

    Ignoramus10032 writes:

    > On 2008-09-07, Grant Edwards wrote:
    >>
    >> Determining what they mean isn't an issue. The issue is
    >> getting sub-millisecond accuracy with a user-space program.
    >>

    >
    > Why would it be so, if everything is in RAM and no swapping is going
    > on?
    >
    > For simplicity reasons, I can easily dedicate a computer to this
    > application, so that it would run no seriously big loads.


    Unless you go to a real real-time OS, this just isn't going to
    happen. You can get sub-millisecond a lot of the time,
    several-millisecond most of the time, but if you really seriously
    want a guaranteed response time -- especially on short time scales
    like milliseconds -- general-purpose OSes just don't offer them. When
    the machine decides to do something that takes time... your response
    suffers.

  7. Re: Keeping a VERY accurate time (within a millisecond)

    On 2008-09-07, Joe Pfeiffer wrote:
    > Ignoramus10032 writes:
    >
    >> On 2008-09-07, Grant Edwards wrote:
    >>>
    >>> Determining what they mean isn't an issue. The issue is
    >>> getting sub-millisecond accuracy with a user-space program.
    >>>

    >>
    >> Why would it be so, if everything is in RAM and no swapping is going
    >> on?
    >>
    >> For simplicity reasons, I can easily dedicate a computer to this
    >> application, so that it would run no seriously big loads.

    >
    > Unless you go to a real real-time OS, this just isn't going to
    > happen. You can get sub-millisecond a lot of the time,
    > several-millisecond most of the time, but if you really seriously
    > want a guaranteed response time -- especially on short time scales
    > like milliseconds -- general-purpose OSes just don't offer them. When
    > the machine decides to do something that takes time... your response
    > suffers.


    Does that include responding to an interrupt from a serial port?

    --
    Due to extreme spam originating from Google Groups, and their inattention
    to spammers, I and many others block all articles originating
    from Google Groups. If you want your postings to be seen by
    more readers you will need to find a different means of
    posting on Usenet.
    http://improve-usenet.org/

  8. Re: Keeping a VERY accurate time (within a millisecond)

    Joe Pfeiffer wrote:
    > Ignoramus10032 writes:
    >
    >> On 2008-09-07, Grant Edwards wrote:
    >>> Determining what they mean isn't an issue. The issue is
    >>> getting sub-millisecond accuracy with a user-space program.
    >>>

    >> Why would it be so, if everything is in RAM and no swapping is going
    >> on?
    >>
    >> For simplicity reasons, I can easily dedicate a computer to this
    >> application, so that it would run no seriously big loads.

    >
    > Unless you go to a real real-time OS, this just isn't going to
    > happen. You can get sub-millisecond a lot of the time,
    > several-millisecond most of the time, but if you really seriously
    > want a guaranteed response time -- especially on short time scales
    > like milliseconds -- general-purpose OSes just don't offer them. When
    > the machine decides to do something that takes time... your response
    > suffers.


    I believe Unruh has the best approach to t least putting a dead accurate
    NTP server on the network..that is take some daemon like the NTP server,
    and drive it from a fast interrupt service routine..from, as he suggests
    the parallel port.

    That will give you a pretty uptodate time stamp somewhere.. then the
    issue is how fast the NTP server will respond..If it doesn't matter that
    the call to NTP takes time as lon as a dead accurate response is
    delivered, by the time the daemon has gotten into active state, as long
    as what it then reads and sends back is good, things shoud be OK at the
    server level.

    The client is a bit of a different matter though..as some process will
    presumably call into the network and suspend, waiting on a return packet
    with the time: if it doesn't get resumed fast enough when the packet
    comes back, the time it reads will be a little bit old.

    Then there are various other unpredictable scheduling delays..depending
    on the process lists etc.

    On my linux serer, when freshly booted, an attempt to telnet into it
    after a fresh reboot is instantaneous. After its been up a while though,
    it can take several seconds. I guess something important gets paged out
    eventually. Hardly 'sub millisecond'.


    Its this whole variability in scheduling that is the raison d'etre of
    real time OS'es, and why Linux doesn't normally get used in its shipped
    state in any time critical application. Linux, like Unix, starts to slow
    down under load. Real time stuff is designed to keep up, until it fails
    utterly.

    Without knowing the application, which appears to be sufficiently
    sensitive not to be disclosed, its hard to say what would work better
    though, or whether Linux would be 'good enough'

  9. Re: Keeping a VERY accurate time (within a millisecond)

    Ignoramus10032 wrote:
    > On 2008-09-07, Joe Pfeiffer wrote:
    >> Ignoramus10032 writes:
    >>
    >>> On 2008-09-07, Grant Edwards wrote:
    >>>> Determining what they mean isn't an issue. The issue is
    >>>> getting sub-millisecond accuracy with a user-space program.
    >>>>
    >>> Why would it be so, if everything is in RAM and no swapping is going
    >>> on?
    >>>
    >>> For simplicity reasons, I can easily dedicate a computer to this
    >>> application, so that it would run no seriously big loads.

    >> Unless you go to a real real-time OS, this just isn't going to
    >> happen. You can get sub-millisecond a lot of the time,
    >> several-millisecond most of the time, but if you really seriously
    >> want a guaranteed response time -- especially on short time scales
    >> like milliseconds -- general-purpose OSes just don't offer them. When
    >> the machine decides to do something that takes time... your response
    >> suffers.

    >
    > Does that include responding to an interrupt from a serial port?
    >

    certainly can do, yes.

    Which is why serial ports have FIFO buffers on em these days. If you
    dint make your ISR read ALL the buffer, even though it was set to
    interrupt on any input character, you occasionally lost data..

    Even hardware interrupts have some sort of prioritization.

    Its been a long time..but AFAICR the timer interrupt on the original PC
    had top priority, but when doing something time critical like pulling
    data via DMA off a disk, you might disable that..or postpone its effect
    anyway.

    And remember, even at 115k baud or whatever RS232 stops at, max data
    rate is only about 10K bytes/second..if your time string is 10 bytes
    long thats a millisecond to read it in..

  10. Re: Keeping a VERY accurate time (within a millisecond)

    The Natural Philosopher wrote:
    >
    > Which is why serial ports have FIFO buffers on em these days. If you
    > dint make your ISR read ALL the buffer, even though it was set to
    > interrupt on any input character, you occasionally lost data..
    >
    > Even hardware interrupts have some sort of prioritization.
    >
    > Its been a long time..but AFAICR the timer interrupt on the original PC
    > had top priority, but when doing something time critical like pulling
    > data via DMA off a disk, you might disable that..or postpone its effect
    > anyway.
    >
    > And remember, even at 115k baud or whatever RS232 stops at, max data
    > rate is only about 10K bytes/second..if your time string is 10 bytes
    > long thats a millisecond to read it in..


    If you use NTP, especially if you have an accurate local time source to
    drive it, you can do better than you would think from the hardware.

    NTP does not merely get the time from its reference source(s). It runs a
    phase lock loop that improves matters because it greatly reduces jitter
    (which practically speaking includes real jitter in the time source(s) and
    also the variable time it takes for the computer to respond to the time
    reference signals).

    So if the jitter is about 6 milliseconds, the phase lock loop can reduce the
    jitter to a very low value. NTP polls the time sources every 64 seconds
    until the phase lock loops (one per source) stabilize and gradually decrease
    the polling interval to 1024 seconds once things are working smoothly. For
    example, here is what my machine is doing (delay, offset, and jitter are in
    milliseconds). remote is the source of the time information. st = 1 means
    the time source is directly connected to an accurate time source. st = 2
    means the time source is one hop away from an st = 1 source, etc.

    remote refid st t when poll reach delay offset jitter
    ================================================== ==========================
    *clock1.redhat.c .CDMA. 1 u 963 1024 377 31.640 -4.328 1.634
    +time.nist.gov .ACTS. 1 u 446 1024 377 56.778 -7.453 2.347
    +lashiir.sapros. 128.194.254.9 3 u 878 1024 377 54.947 -8.416 0.259

    Now if one of your sources is GPS or CDMA located right next to your
    computer, the delay could be only a few nanoseconds (really, since the speed
    of light is about one nanosecond per foot) plus the minimum delay to get an
    interrupt through the system (perhaps a millisecond). The raw jitter is then
    the variable delay to get the interrupt acknowledged, that might be from 1
    to 10 milliseconds depending on the speed of the port used (I use a 100 MHz
    NIC connected to a 20 megabit/sec Verizon FiOS link, but the jitter to those
    clock sources may be considerable). So the jitter will not be much of an
    issue with NTP after it has been running a few hours.

    --
    .~. Jean-David Beyer Registered Linux User 85642.
    /V\ PGP-Key: 9A2FC99A Registered Machine 241939.
    /( )\ Shrewsbury, New Jersey http://counter.li.org
    ^^-^^ 06:40:01 up 31 days, 12:46, 4 users, load average: 4.25, 4.21, 4.13

  11. Re: Keeping a VERY accurate time (within a millisecond)



    "Ignoramus10032" wrote in message
    news:-9idnc4pMdv6_17VnZ2dnUVZ_j2dnZ2d@giganews.com...
    > On 2008-09-07, Joe Pfeiffer wrote:
    >> Ignoramus10032 writes:
    >>
    >>> On 2008-09-07, Grant Edwards wrote:
    >>>>
    >>>> Determining what they mean isn't an issue. The issue is
    >>>> getting sub-millisecond accuracy with a user-space program.
    >>>>
    >>>
    >>> Why would it be so, if everything is in RAM and no swapping is going
    >>> on?
    >>>
    >>> For simplicity reasons, I can easily dedicate a computer to this
    >>> application, so that it would run no seriously big loads.

    >>
    >> Unless you go to a real real-time OS, this just isn't going to
    >> happen. You can get sub-millisecond a lot of the time,
    >> several-millisecond most of the time, but if you really seriously
    >> want a guaranteed response time -- especially on short time scales
    >> like milliseconds -- general-purpose OSes just don't offer them. When
    >> the machine decides to do something that takes time... your response
    >> suffers.

    >
    > Does that include responding to an interrupt from a serial port?


    Linux, like all popular os, turns off interrupts when it is doing some
    stuff.
    Unless you know how long it does this for you cannot say it can respond to
    an interrupt within a certain time.
    The off time depends on the version of the kernel, the cpu type, the number
    of cpus, the clock speed, the etc.
    This is before you get into the priority, etc.

    Its why generic linux and windows don't make good real time systems.

    However you should be able to write some code to average the reported time
    from a serial port GPS and get pretty close to the correct time.
    Serial ports are somewhat easier to use than USB ones and they frequently
    just emulate a serial port anyway.


  12. Re: Keeping a VERY accurate time (within a millisecond)

    In comp.os.linux.misc The Natural Philosopher wrote:
    > And remember, even at 115k baud or whatever RS232 stops at, max data
    > rate is only about 10K bytes/second..if your time string is 10 bytes
    > long thats a millisecond to read it in..


    That's exactly why NTP has fudge factors in the configuration file to
    adjust the data values read.

    Chris

  13. Re: Keeping a VERY accurate time (within a millisecond)

    Ignoramus10032 writes:

    >On 2008-09-07, Joe Pfeiffer wrote:
    >> Ignoramus10032 writes:
    >>
    >>> On 2008-09-07, Grant Edwards wrote:
    >>>>
    >>>> Determining what they mean isn't an issue. The issue is
    >>>> getting sub-millisecond accuracy with a user-space program.
    >>>>
    >>>
    >>> Why would it be so, if everything is in RAM and no swapping is going
    >>> on?
    >>>
    >>> For simplicity reasons, I can easily dedicate a computer to this
    >>> application, so that it would run no seriously big loads.

    >>
    >> Unless you go to a real real-time OS, this just isn't going to
    >> happen. You can get sub-millisecond a lot of the time,
    >> several-millisecond most of the time, but if you really seriously
    >> want a guaranteed response time -- especially on short time scales
    >> like milliseconds -- general-purpose OSes just don't offer them. When
    >> the machine decides to do something that takes time... your response
    >> suffers.


    >Does that include responding to an interrupt from a serial port?


    Interrupts have top priority. And some interrupt drivers are badly written
    so they hog the interrupts and do not allow servicing of others.

    But if you want to look at a real world example--
    www.theory.physics.ubc.ca/chrony/chrony.html -- look at string-- will show
    you an ntp clock running off a GArmin 18LVC-- those times are the offsets in
    the GPS time readings over time.
    The others are other computers that take their time from string but they
    run chrony instead of ntp. chrony is about a factor of 2-3 better in
    disciplining clocks but it has no ability to use hardware refclocks.



  14. Re: Keeping a VERY accurate time (within a millisecond)

    The Natural Philosopher writes:

    >Joe Pfeiffer wrote:
    >> Ignoramus10032 writes:
    >>
    >>> On 2008-09-07, Grant Edwards wrote:
    >>>> Determining what they mean isn't an issue. The issue is
    >>>> getting sub-millisecond accuracy with a user-space program.
    >>>>
    >>> Why would it be so, if everything is in RAM and no swapping is going
    >>> on?
    >>>
    >>> For simplicity reasons, I can easily dedicate a computer to this
    >>> application, so that it would run no seriously big loads.

    >>
    >> Unless you go to a real real-time OS, this just isn't going to
    >> happen. You can get sub-millisecond a lot of the time,
    >> several-millisecond most of the time, but if you really seriously
    >> want a guaranteed response time -- especially on short time scales
    >> like milliseconds -- general-purpose OSes just don't offer them. When
    >> the machine decides to do something that takes time... your response
    >> suffers.


    >I believe Unruh has the best approach to t least putting a dead accurate
    >NTP server on the network..that is take some daemon like the NTP server,
    >and drive it from a fast interrupt service routine..from, as he suggests
    >the parallel port.


    >That will give you a pretty uptodate time stamp somewhere.. then the
    >issue is how fast the NTP server will respond..If it doesn't matter that
    >the call to NTP takes time as lon as a dead accurate response is
    >delivered, by the time the daemon has gotten into active state, as long
    >as what it then reads and sends back is good, things shoud be OK at the
    >server level.



    >The client is a bit of a different matter though..as some process will
    >presumably call into the network and suspend, waiting on a return packet
    >with the time: if it doesn't get resumed fast enough when the packet
    >comes back, the time it reads will be a little bit old.


    Experiments are always a good idea. And I have been running one for about a
    year now. See www.theory.physics.ubc.ca/chrony/chrony.html.
    From a local network tens of microseconds is a reasonable expectation. from
    the ntp server connected to the gps clock a few microseconds is reasonable.
    From a computer connected over an adsl link 100s of microseconds are a
    reasonable expectation, Even for a connection by internet to a server 1000
    miles away, 100s of microseconds is reasonable, even though thought the
    round trip time is 10s of milliseconds.



    >Then there are various other unpredictable scheduling delays..depending
    >on the process lists etc.


    >On my linux serer, when freshly booted, an attempt to telnet into it
    >after a fresh reboot is instantaneous. After its been up a while though,
    >it can take several seconds. I guess something important gets paged out
    >eventually. Hardly 'sub millisecond'.


    Telnet? I do nope ssh. But anyway, that requires waking up many processes
    and reading many files. Also ntp can be told to run at heightened priority,
    so it is much less likely to get swapped out.




    >Its this whole variability in scheduling that is the raison d'etre of
    >real time OS'es, and why Linux doesn't normally get used in its shipped
    >state in any time critical application. Linux, like Unix, starts to slow
    >down under load. Real time stuff is designed to keep up, until it fails
    >utterly.


    Those are real time user space programs.


    >Without knowing the application, which appears to be sufficiently
    >sensitive not to be disclosed, its hard to say what would work better
    >though, or whether Linux would be 'good enough'


    All I know is that the linux clock can be conditioned to give microsecond
    accuracy when called. I have no idea if this is useful to him.
    Ie, calling gettimeofday will give microsecond type accuracy at the time it
    is called. What happens before of after that call is another issue.
    It may be that he does require a reeal-time-OS.



  15. Re: Keeping a VERY accurate time (within a millisecond)

    Jean-David Beyer writes:

    >The Natural Philosopher wrote:
    >>
    >> Which is why serial ports have FIFO buffers on em these days. If you
    >> dint make your ISR read ALL the buffer, even though it was set to
    >> interrupt on any input character, you occasionally lost data..
    >>
    >> Even hardware interrupts have some sort of prioritization.
    >>
    >> Its been a long time..but AFAICR the timer interrupt on the original PC
    >> had top priority, but when doing something time critical like pulling
    >> data via DMA off a disk, you might disable that..or postpone its effect
    >> anyway.
    >>
    >> And remember, even at 115k baud or whatever RS232 stops at, max data
    >> rate is only about 10K bytes/second..if your time string is 10 bytes
    >> long thats a millisecond to read it in..


    >If you use NTP, especially if you have an accurate local time source to
    >drive it, you can do better than you would think from the hardware.


    >NTP does not merely get the time from its reference source(s). It runs a
    >phase lock loop that improves matters because it greatly reduces jitter
    >(which practically speaking includes real jitter in the time source(s) and
    >also the variable time it takes for the computer to respond to the time
    >reference signals).


    >So if the jitter is about 6 milliseconds, the phase lock loop can reduce the
    >jitter to a very low value. NTP polls the time sources every 64 seconds
    >until the phase lock loops (one per source) stabilize and gradually decrease
    >the polling interval to 1024 seconds once things are working smoothly. For
    >example, here is what my machine is doing (delay, offset, and jitter are in
    >milliseconds). remote is the source of the time information. st = 1 means
    >the time source is directly connected to an accurate time source. st = 2
    >means the time source is one hop away from an st = 1 source, etc.


    > remote refid st t when poll reach delay offset jitter
    >================================================== ==========================
    >*clock1.redhat.c .CDMA. 1 u 963 1024 377 31.640 -4.328 1.634
    >+time.nist.gov .ACTS. 1 u 446 1024 377 56.778 -7.453 2.347
    >+lashiir.sapros. 128.194.254.9 3 u 878 1024 377 54.947 -8.416 0.259


    >Now if one of your sources is GPS or CDMA located right next to your
    >computer, the delay could be only a few nanoseconds (really, since the speed


    No, it is not. The delay comes about because of the traversal of the
    operating system and the network card to finally getting the stuff out onto
    the internet. Even the packet length on the network is greater than a usec.
    You cannot get nanosecond precision, even with a GPS attached directly to
    your system. And ntp does not do the best possible job of getting rid of
    the jitter. It is a rather simply second order feedback network, which
    throws away past data.


    >of light is about one nanosecond per foot) plus the minimum delay to get an
    >interrupt through the system (perhaps a millisecond). The raw jitter is then


    Interrupt times are microsecond range. I tested this by having a program
    sendout data out the parallel port, with a gettimeofday just before it was
    sent out. That was connected to the interrupt line on the parallel portand
    the interrupt routine did a gettimeofday when it received that interrupt.
    The difference was about 4-5usec


    >the variable delay to get the interrupt acknowledged, that might be from 1
    >to 10 milliseconds depending on the speed of the port used (I use a 100 MHz
    >NIC connected to a 20 megabit/sec Verizon FiOS link, but the jitter to those
    >clock sources may be considerable). So the jitter will not be much of an
    >issue with NTP after it has been running a few hours.


    There are two sources of jitter-- the clock reading jitter you have
    discussed, and the drift rate of the clocks varying due to temp changes (
    eg using or not using the computer which causes its temp to fluctuate). NTP
    by design is rather slow in responding to the latter (hours) And a change
    of 1PPM meas a clock error of 1usec per second.

    Now, one can try to compensate by reading the temp of the system ( eg via
    one of the on board thermometers) and compensating for the clock drift
    rates using that temperature, and get about a factor of 5 improvement in
    ntp. One can use chrony and get a factor of 2-3 improvement over ntp (It
    respondes faster to termal fluctuations, and averages out over jitter
    better if jitter dominates.)




+ Reply to Thread