ntp server help - NTP

This is a discussion on ntp server help - NTP ; Hello I have 4 ip cameras and I configured with ntp server 10.219.229.1, a Debian NTP Server. I am Having problems to synchronize cameras because I need at least 0.01 seconds of offset and I am having more than this ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: ntp server help

  1. ntp server help

    Hello

    I have 4 ip cameras and I configured with ntp server 10.219.229.1, a
    Debian NTP Server. I am Having problems to synchronize cameras because I
    need at least 0.01 seconds of offset and I am having more than this
    value, as you can see in the graphic. Is very important that cameras
    time be very accuracy . Please help, is for an important project
    I query cameras with this script

    #! /bin/bash
    umbral=0.010000

    dato=$(ntpdate -q $1 | grep ntpdate | grep offset | awk '{ print $10 }')

    verifi=$(echo $umbral $dato| awk '{if ($1 > $2) print "ok"; else print
    "fail"}')

    if [ $verifi = "ok" ]; then
    echo "OK ($dato)"
    exit 0
    else
    echo "Too much delay ($dato)"
    exit 1
    fi


    /ntp.monitor camera3
    OK (0.003026)


    --
    Mikel Jimenez
    Irontec, Internet y Sistemas sobre GNU/LinuX - http://www.irontec.com
    +34 94.404.81.82

  2. Re: ntp server help

    On 2008-08-07, Mikel Jimenez wrote:

    > I have 4 ip cameras and I configured with ntp server 10.219.229.1, a
    > Debian NTP Server.


    Is that a time server that you or your organization operate?

    >I am Having problems to synchronize cameras


    What is the make and model of these cameras ahd how do they query the
    time server?

    > because I need at least 0.01 seconds of offset


    s/at least/no more than/ ???

    > and I am having more than this value, as you can see in the graphic.


    You can not send binary files here. Please post the image somewhere and
    send us the link.

    > /ntp.monitor camera3
    > OK (0.003026)


    That camera looks OK.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  3. Re: ntp server help

    Steve Kostecke wrote:
    > On 2008-08-07, Mikel Jimenez wrote:
    >
    >> I have 4 ip cameras and I configured with ntp server 10.219.229.1, a
    >> Debian NTP Server.

    >
    > Is that a time server that you or your organization operate?
    >

    Since 10.219.229.1 is an RFC-1918 "private network" address, it pretty
    much HAS to be that.

  4. Re: ntp server help

    mikel@irontec.com (Mikel Jimenez) writes:

    >Hello


    >I have 4 ip cameras and I configured with ntp server 10.219.229.1, a
    >Debian NTP Server. I am Having problems to synchronize cameras because I
    >need at least 0.01 seconds of offset and I am having more than this
    >value, as you can see in the graphic. Is very important that cameras
    >time be very accuracy . Please help, is for an important project
    >I query cameras with this script


    And you are using ntpdate why? Why not set up ntp on the system and use it
    to discipline your system's clock. Note whether you will get 1/100 sec
    accuracy depends on the network etc.

    And why are you comparing the offset?



    >#! /bin/bash
    >umbral=0.010000


    >dato=$(ntpdate -q $1 | grep ntpdate | grep offset | awk '{ print $10 }')


    >verifi=$(echo $umbral $dato| awk '{if ($1 > $2) print "ok"; else print
    >"fail"}')


    >if [ $verifi = "ok" ]; then
    >echo "OK ($dato)"
    >exit 0
    >else
    >echo "Too much delay ($dato)"
    >exit 1
    >fi



    >/ntp.monitor camera3
    >OK (0.003026)




  5. Re: ntp server help

    On 2008-08-09, Unruh wrote:

    > mikel@irontec.com (Mikel Jimenez) writes:
    >
    >>I have 4 ip cameras and I configured with ntp server 10.219.229.1, a
    >>Debian NTP Server. I am Having problems to synchronize cameras because
    >>I need at least 0.01 seconds of offset and I am having more than this
    >>value, as you can see in the graphic. Is very important that cameras
    >>time be very accuracy . Please help, is for an important project I
    >>query cameras with this script

    >
    > And you are using ntpdate why?


    The OP is using ntpdate to query the cameras from some other system and
    display the camera clock offsets.

    The fact that the cameras can answer the ntpdate poll suggests that they
    are running ntpd.

    > Why not set up ntp on the system and use it to discipline your
    > system's clock.


    The OP has, apparently, configured the 4 IP cameras to poll an NTP
    server at 10.219.229.1

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  6. Re: ntp server help

    Unruh wrote:
    > mikel@irontec.com (Mikel Jimenez) writes:
    >
    >
    > And you are using ntpdate why? Why not set up ntp on the system and use it
    > to discipline your system's clock. Note whether you will get 1/100 sec
    > accuracy depends on the network etc.


    Although it isn't particularly clear, I believe he is running ntpdate on
    a machine that is properly synchronised, to measure the offsets of the
    cameras.

    Of course, the error in the cameras may well be an order of magnitude
    better than the offsets measured, either that way, or the more approved
    way of using configuring the cameras as ignored servers on the
    synchronizing machine.

    However, my gut feeling is that this application required that it be an
    explicit requirement to buy the cameras that they maintain an offset
    less than 10ms. If that was the case, then he should be pursuing this
    with the vendors of the cameras. If not, he should put it down to
    experience.

    It seems unlikely to me that the cameras are runing NTP, rather than a
    basic implementation of SNTP, and even if they are running NTP, it is
    unlikely that they have included any of the recent optimisations for
    fast convergence, so he should be waiting several hours, after powering
    up the cameras, before doing anything critical.

    It's also worth noting that one really needs a local radio reference
    clock (although I suspect he's actually using the local clock as
    reference) to guarantee 10ms accuracy on the server. It is possible to
    get this most of the time with an internet time reference, but some care
    is needed to achieve it all the time.
    >
    > And why are you comparing the offset?


    He wants the video feeds from the cameras to have their RTP timestamps
    within 20ms (probably he meant 10ms) of each other. I'm not sure why,
    as it would seem easier to retime outside of the camera. I'm guessing
    the RTP bit.
    >
    >


  7. Re: ntp server help

    David Woolley escribis:
    > Unruh wrote:
    >
    >> mikel@irontec.com (Mikel Jimenez) writes:
    >>
    >>
    >> And you are using ntpdate why? Why not set up ntp on the system and use it
    >> to discipline your system's clock. Note whether you will get 1/100 sec
    >> accuracy depends on the network etc.
    >>

    >
    > Although it isn't particularly clear, I believe he is running ntpdate on
    > a machine that is properly synchronised, to measure the offsets of the
    > cameras.
    >
    > Of course, the error in the cameras may well be an order of magnitude
    > better than the offsets measured, either that way, or the more approved
    > way of using configuring the cameras as ignored servers on the
    > synchronizing machine.
    >
    > However, my gut feeling is that this application required that it be an
    > explicit requirement to buy the cameras that they maintain an offset
    > less than 10ms. If that was the case, then he should be pursuing this
    > with the vendors of the cameras. If not, he should put it down to
    > experience.
    >
    > It seems unlikely to me that the cameras are runing NTP, rather than a
    > basic implementation of SNTP, and even if they are running NTP, it is
    > unlikely that they have included any of the recent optimisations for
    > fast convergence, so he should be waiting several hours, after powering
    > up the cameras, before doing anything critical.
    >
    > It's also worth noting that one really needs a local radio reference
    > clock (although I suspect he's actually using the local clock as
    > reference) to guarantee 10ms accuracy on the server. It is possible to
    > get this most of the time with an internet time reference, but some care
    > is needed to achieve it all the time.
    >
    >> And why are you comparing the offset?
    >>

    >
    > He wants the video feeds from the cameras to have their RTP timestamps
    > within 20ms (probably he meant 10ms) of each other. I'm not sure why,
    > as it would seem easier to retime outside of the camera. I'm guessing
    > the RTP bit.
    >
    >>

    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.org
    > https://lists.ntp.org/mailman/listinfo/questions
    >

    How can I configure the server to cameras get server time every very
    very short time? My objective is to get the server and 4 cameras
    syncronizhed, not more 0.01s desyncronizhed, taking reference the server.

  8. Re: ntp server help

    Mikel Jimenez wrote:

    > How can I configure the server to cameras get server time every very


    You need to configure the cameras, not the servers, unless they are
    using broadcast mode.

    > very short time? My objective is to get the server and 4 cameras
    > syncronizhed, not more 0.01s desyncronizhed, taking reference the server.


  9. Re: ntp server help

    mikel@irontec.com (Mikel Jimenez) writes:

    >David Woolley escribis:
    >> Unruh wrote:
    >>
    >>> mikel@irontec.com (Mikel Jimenez) writes:
    >>>
    >>>
    >>> And you are using ntpdate why? Why not set up ntp on the system and use it
    >>> to discipline your system's clock. Note whether you will get 1/100 sec
    >>> accuracy depends on the network etc.
    >>>

    >>
    >> Although it isn't particularly clear, I believe he is running ntpdate on
    >> a machine that is properly synchronised, to measure the offsets of the
    >> cameras.
    >>
    >> Of course, the error in the cameras may well be an order of magnitude
    >> better than the offsets measured, either that way, or the more approved
    >> way of using configuring the cameras as ignored servers on the
    >> synchronizing machine.
    >>
    >> However, my gut feeling is that this application required that it be an
    >> explicit requirement to buy the cameras that they maintain an offset
    >> less than 10ms. If that was the case, then he should be pursuing this
    >> with the vendors of the cameras. If not, he should put it down to
    >> experience.
    >>
    >> It seems unlikely to me that the cameras are runing NTP, rather than a
    >> basic implementation of SNTP, and even if they are running NTP, it is
    >> unlikely that they have included any of the recent optimisations for
    >> fast convergence, so he should be waiting several hours, after powering
    >> up the cameras, before doing anything critical.
    >>
    >> It's also worth noting that one really needs a local radio reference
    >> clock (although I suspect he's actually using the local clock as
    >> reference) to guarantee 10ms accuracy on the server. It is possible to
    >> get this most of the time with an internet time reference, but some care
    >> is needed to achieve it all the time.
    >>
    >>> And why are you comparing the offset?
    >>>

    >>
    >> He wants the video feeds from the cameras to have their RTP timestamps
    >> within 20ms (probably he meant 10ms) of each other. I'm not sure why,
    >> as it would seem easier to retime outside of the camera. I'm guessing
    >> the RTP bit.
    >>

    >How can I configure the server to cameras get server time every very
    >very short time? My objective is to get the server and 4 cameras
    >syncronizhed, not more 0.01s desyncronizhed, taking reference the server.


    We have no idea what is running on the cameras/ There is apparently a clock
    on them. Is there some sort of ntp/sntp running on them If there is your
    server running ntp will automatically also act as an ntp server. If there
    is no ntp running on the cameras, then I do not know. So, more information
    would be helpful


  10. Re: ntp server help

    "Mikel Jimenez" wrote in message
    news:489DAFD4.8050009@irontec.com...
    [...]
    > How can I configure the server to cameras get server time every very
    > very short time? My objective is to get the server and 4 cameras
    > syncronizhed, not more 0.01s desyncronizhed, taking reference the
    > server.


    One way would be to configure the server for broadcast mode, and the
    clients for listening to the broadcasts. Then the server would send
    out timestamps every 64 seconds (I think), which for NTP purposes
    qualifies as quite often.

    But that's not the normal way to have a small number of clients work.
    It is more common to run NTP on the clients and let it adjust the clock
    until it runs very nearly exactly right. That works much better than
    leaving the clock to run slow or fast and jolt it back or forward as
    required 'every very very short time'.

    Two things may be wrong with a clock: it may simply be off (reading
    for example ten past midnight at midnight), and it may be running
    fast or slow (say, advancing sixty-one minutes every hour). Most
    clocks suffer from both. Most people know no better than to set back
    that clock twenty-four minutes every day. Doing that more often will
    require smaller adjustments each time, and also have the clock being
    closer to real time on average.

    But NTP can slow down or speed up the clock as well. It can really
    make the clock run at sixty minutes per hour[0]. And then you only
    need to make the rough adjustment once, if at all. After that, the
    clock is adjusted by making it run faster or slower (only a _veeery_
    little bit) when it needs it. Very soon, you get to the point where
    the time difference between client and server must be allowed to
    accumulate for quite a long time before you can even reliably see
    it, so you are correcting real error and not just measurement noise.

    NTP will start by polling every 64 seconds. When it is running well,
    it will poll less and less, until it stops at polling every 1024
    seconds (just over 17 minutes). And the offset will be not just
    under 0.01 seconds, it can be under 0.01 _milli_seconds. If it's
    running well.

    Groetjes,
    Maarten Wiltink

    [0] These numbers are faked. A more realistic error is a tenth of
    a second per hour.



  11. Re: ntp server help

    On 2008-08-09, Mikel Jimenez wrote:

    > David Woolley escribis:
    >
    >> [---=| Quote block shrinked by t-prot: 42 lines snipped |=---]


    [snip: more blind quoting]

    > How can I configure the server to cameras get server time every very
    > very short time? My objective is to get the server and 4 cameras
    > syncronizhed, not more 0.01s desyncronizhed, taking reference the
    > server.


    What cameras are you using? (Make, model number)

    How have you configured the cameras?

    What is does the output of 'ntpq -p your_server' look like?

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  12. Re: ntp server help

    "Maarten Wiltink" writes:

    >"Mikel Jimenez" wrote in message
    >news:489DAFD4.8050009@irontec.com...
    >[...]
    >> How can I configure the server to cameras get server time every very
    >> very short time? My objective is to get the server and 4 cameras
    >> syncronizhed, not more 0.01s desyncronizhed, taking reference the
    >> server.


    >One way would be to configure the server for broadcast mode, and the
    >clients for listening to the broadcasts. Then the server would send
    >out timestamps every 64 seconds (I think), which for NTP purposes
    >qualifies as quite often.


    >But that's not the normal way to have a small number of clients work.
    >It is more common to run NTP on the clients and let it adjust the clock
    >until it runs very nearly exactly right. That works much better than
    >leaving the clock to run slow or fast and jolt it back or forward as
    >required 'every very very short time'.


    >Two things may be wrong with a clock: it may simply be off (reading
    >for example ten past midnight at midnight), and it may be running
    >fast or slow (say, advancing sixty-one minutes every hour). Most
    >clocks suffer from both. Most people know no better than to set back
    >that clock twenty-four minutes every day. Doing that more often will
    >require smaller adjustments each time, and also have the clock being
    >closer to real time on average.


    >But NTP can slow down or speed up the clock as well. It can really
    >make the clock run at sixty minutes per hour[0]. And then you only
    >need to make the rough adjustment once, if at all. After that, the
    >clock is adjusted by making it run faster or slower (only a _veeery_
    >little bit) when it needs it. Very soon, you get to the point where
    >the time difference between client and server must be allowed to
    >accumulate for quite a long time before you can even reliably see
    >it, so you are correcting real error and not just measurement noise.


    The problem is that we have no idea how the time keeping on the camera is
    actually done. It may just have a real time clock-- no system time, which
    it reads, and which has a 1 second quantization, a la the PC real time
    clock. It may have no software on board to run a system clock based on the
    processor, or video, or whatever other frequency. Asking the user to write
    the software to install a system clock on board the camera with all of the
    discipline that the Linux or Unix kernel has is asking a bit much. After
    all millions use ntp on a windows machine which has pretty poor machine
    time disciplining from all I have heard. And very very very few people have
    rewriten Vista's system clock software to make it behave itself better.

    Ie, we really need to know what in the world he has -- hardware and
    software-- on the camera before we can give much advice.



    >NTP will start by polling every 64 seconds. When it is running well,
    >it will poll less and less, until it stops at polling every 1024
    >seconds (just over 17 minutes). And the offset will be not just
    >under 0.01 seconds, it can be under 0.01 _milli_seconds. If it's
    >running well.


    It can be well under .1ms with a reasonable network connection.
    But that is only because the system software supports such behaviour. Even
    NTP's software clock discipline would be dead in the water if the per
    second select() time fluctuated by .5 sec from time to time. Ie, the
    software and hardware on the camera system has to be designed properly.
    We have no idea if it is.


    >Groetjes,
    >Maarten Wiltink


    >[0] These numbers are faked. A more realistic error is a tenth of
    > a second per hour.




+ Reply to Thread