I’ve been asked by a coworker how to synchronize the time between two QNX
machines, to at least 10 ms accuracy. Two possibilities I saw - rtc and ntp.
In his tests with “rtc net /net/nodename”, he believes that they are only
synchronized at 1 second accuracy.
In my tests with ntpd (4.1.72), I can’t get one node to synchronize with
another (don’t know if it should - I’m not very ntp-literate). It does
synchronize with a known ntp server.
So what’s the recommended way to get them synched?
I’ve been asked by a coworker how to synchronize the time between two QNX
machines, to at least 10 ms accuracy. Two possibilities I saw - rtc and
ntp.
In his tests with “rtc net /net/nodename”, he believes that they are only
synchronized at 1 second accuracy.
I find 1 second large but it would definitely not be within 10 ms,
In my tests with ntpd (4.1.72), I can’t get one node to synchronize with
another (don’t know if it should - I’m not very ntp-literate). It does
synchronize with a known ntp server.
One has to be setup as a ntp server and the other as a client.
So what’s the recommended way to get them synched?
If you only want to sync up QNX nodes to each other, I have a QNX4
utility that will sync up clocks on multiple CPUs to within a ms or two.
This can be ported to QNX6 fairly easily if you like.
The relative accuracy depends on latencies of the network. But it is
smart enough to recognize when the network gets slow (inconsistant) and
rejects doing updates until the network stabelizes again.
I will be out of the office for a while but I’ll post my code when I
can.
I’ve been asked by a coworker how to synchronize the time between two QNX
machines, to at least 10 ms accuracy. Two possibilities I saw - rtc and
MC > ntp.
In his tests with “rtc net /net/nodename”, he believes that they are only
synchronized at 1 second accuracy.
MC > I find 1 second large but it would definitely not be within 10 ms,
In my tests with ntpd (4.1.72), I can’t get one node to synchronize with
another (don’t know if it should - I’m not very ntp-literate). It does
synchronize with a known ntp server.
MC > One has to be setup as a ntp server and the other as a client.
So what’s the recommended way to get them synched?
In my tests with ntpd (4.1.72), I can’t get one node to synchronize with
another (don’t know if it should - I’m not very ntp-literate). It does
synchronize with a known ntp server.
One has to be setup as a ntp server and the other as a client.
“Marty Doane” <> martin.doane@siemens.com> > wrote in message
news:ba35h6$3e8$> 1@nntp.qnx.com> …
I’ve been asked by a coworker how to synchronize the time between two QNX
machines, to at least 10 ms accuracy. Two possibilities I saw - rtc and
ntp.
In his tests with “rtc net /net/nodename”, he believes that they are only
synchronized at 1 second accuracy.
I find 1 second large but it would definitely not be within 10 ms,
Why did you find it large? ‘rtc’ uses RTC hardware, and RTC keeps time in hh:mm:ss format, no more
accurately. ‘rtc net’ set time on one node by using RTC on other node. But RTC hardware on remote
node also gives your hh:mm:ss, not more. So, 1 sec is exactly correct )
“Marty Doane” <> martin.doane@siemens.com> > wrote in message
news:ba35h6$3e8$> 1@nntp.qnx.com> …
I’ve been asked by a coworker how to synchronize the time between two QNX
machines, to at least 10 ms accuracy. Two possibilities I saw - rtc and
ntp.
In his tests with “rtc net /net/nodename”, he believes that they are only
synchronized at 1 second accuracy.
I find 1 second large but it would definitely not be within 10 ms,
Why did you find it large? ‘rtc’ uses RTC hardware, and RTC keeps time in hh:mm:ss format, no more
accurately. ‘rtc net’ set time on one node by using RTC on other node. But RTC hardware on remote
node also gives your hh:mm:ss, not more. So, 1 sec is exactly correct > > )
Ahhh… but by carefully manipulating the hardware, even 1s resolution hardware
can be “tricked” into being more accurate. It’s all in the edge transitions
Cheers,
-RK
–
[If replying via email, you’ll need to click on the URL that’s emailed to you
afterwards to forward the email to me – spam filters and all that]
Robert Krten, PDP minicomputer collector http://www.parse.com/~pdp8/
In my tests with ntpd (4.1.72), I can’t get one node to synchronize with
another (don’t know if it should - I’m not very ntp-literate). It does
synchronize with a known ntp server.
One has to be setup as a ntp server and the other as a client.
Care to elaborate on the server setup?
Basically, ntp is designed to synchronize computers with time sources
(typically atomic clocks), and therefore requires a time source to be
specified if it is going to be a server (ntp - never really recognizes
a computer as a time source, and must be “fooled” into thinking it is
one). The trick in making a PC based ntp server is to declare it’s
local clock as a time source.
This is done by telling ntp to use the OS clock as a time source
(not really something ntp is designed to do). This is done by
specifying a special (invalid) IP address (127.127.0.0 - IIRC) as a
server. Note that this IP address is not a loopback address, but
an invalid IP address that tells ntpd to read the OS clock.
So:
In the ntp.conf file on the machine that is to be server add the
line:
server 127.127.0.0
In the ntp.conf on the machine that is to be client add the line:
server XXX.XXX.XXX.XXX
Where XXX.XXX.XXX.XXX is the IP of the server machine.
I’d like to get CLOCK_REALTIME synchronized between local
QNX machines to within 10ms, so that timestamps on logged data are
all in sync. All the machines are on the same LAN. Time
correctness matters; control decisions will be made based on it.
Is this something that can be done reliably? What’s the
recommended approach?
John Nagle
Animats
Marty Doane wrote:
I’ve been asked by a coworker how to synchronize the time between two QNX
machines, to at least 10 ms accuracy. Two possibilities I saw - rtc and ntp.
In his tests with “rtc net /net/nodename”, he believes that they are only
synchronized at 1 second accuracy.
In my tests with ntpd (4.1.72), I can’t get one node to synchronize with
another (don’t know if it should - I’m not very ntp-literate). It does
synchronize with a known ntp server.
So what’s the recommended way to get them synched?
ed1k <> ed1k@humber.bay> > wrote:
Why did you find it large? ‘rtc’ uses RTC hardware, and RTC keeps time in hh:mm:ss format, no more
accurately. ‘rtc net’ set time on one node by using RTC on other node. But RTC hardware on remote
node also gives your hh:mm:ss, not more. So, 1 sec is exactly correct > > )
Ahhh… but by carefully manipulating the hardware, even 1s resolution hardware
can be “tricked” into being more accurate. It’s all in the edge transitions >
Just curious which “trick” do you have in a pocket We are speaking here about ‘rtc’ command and I
doubt that this command uses any tricks. All what is done it is just reading of three registers
“current hour”, “current minute” and “current second” (or writing if we’re setting the RTC time), I
believe (QNX isn’t open source OS, so I lay on documentation only). RTC chip can be programmed in
order to generate periodicaly interrupts as accurately as once in 122.07uS and this can be used to
synchronize the processes on a local computer. In case of few computers, you have to care about
propagation of this event (periodicaly synchronized interrupt) to remote nodes. Is not ntp about
such propagation? BTW, is any warranty about delivery time of event (e.g. pulse) to remote node
across QNET? Hmm… years ago we used special separate wire to generate time synchronized interrupts
on all nodes in a small LAN, but source was an atomic clock
I’d like to get CLOCK_REALTIME synchronized between local
QNX machines to within 10ms, so that timestamps on logged data are
all in sync. All the machines are on the same LAN. Time
correctness matters; control decisions will be made based on it.
Is this something that can be done reliably? What’s the
recommended approach?
NTP will do this for you; in fact, it can do much better than
10ms.
What he said was:
“It’s all in the edge transitions”
So when you do a lot of read’s very quickly in a loop, you can detect the
transition to the next second.
Depending on the cycle time of your loop, you can sync the second node
pretty acurate.
In article <ba4157$ns1$> 1@inn.qnx.com> >, > rk@parse.com > says…
ed1k <> ed1k@humber.bay> > wrote:
Why did you find it large? ‘rtc’ uses RTC hardware, and RTC keeps time
in hh:mm:ss format, no more
accurately. ‘rtc net’ set time on one node by using RTC on other node.
But RTC hardware on remote
node also gives your hh:mm:ss, not more. So, 1 sec is exactly correct > )
Ahhh… but by carefully manipulating the hardware, even 1s resolution
hardware
can be “tricked” into being more accurate. It’s all in the edge
transitions >
Just curious which “trick” do you have in a pocket > > We are speaking here
about ‘rtc’ command and I
doubt that this command uses any tricks. All what is done it is just
reading of three registers
“current hour”, “current minute” and “current second” (or writing if we’re
setting the RTC time), I
believe (QNX isn’t open source OS, so I lay on documentation only). RTC
chip can be programmed in
order to generate periodicaly interrupts as accurately as once in 122.07uS
and this can be used to
synchronize the processes on a local computer. In case of few computers,
you have to care about
propagation of this event (periodicaly synchronized interrupt) to remote
nodes. Is not ntp about
such propagation? BTW, is any warranty about delivery time of event (e.g.
pulse) to remote node
across QNET? Hmm… years ago we used special separate wire to generate
time synchronized interrupts
on all nodes in a small LAN, but source was an atomic clock >
Marty Doane wrote:
In my tests with ntpd (4.1.72), I can’t get one node to synchronize
with
another (don’t know if it should - I’m not very ntp-literate). It does
synchronize with a known ntp server.
One has to be setup as a ntp server and the other as a client.
Care to elaborate on the server setup?
Basically, ntp is designed to synchronize computers with time sources
(typically atomic clocks), and therefore requires a time source to be
specified if it is going to be a server (ntp - never really recognizes
a computer as a time source, and must be “fooled” into thinking it is
one). The trick in making a PC based ntp server is to declare it’s
local clock as a time source.
This is done by telling ntp to use the OS clock as a time source
(not really something ntp is designed to do). This is done by
specifying a special (invalid) IP address (127.127.0.0 - IIRC) as a
server. Note that this IP address is not a loopback address, but
an invalid IP address that tells ntpd to read the OS clock.
So:
In the ntp.conf file on the machine that is to be server add the
line:
server 127.127.0.0
In the ntp.conf on the machine that is to be client add the line:
server XXX.XXX.XXX.XXX
Where XXX.XXX.XXX.XXX is the IP of the server machine.
What he said was:
“It’s all in the edge transitions”
So when you do a lot of read’s very quickly in a loop, you can detect the
transition to the next second.
Huh? You can program RTC hardware to generate interrupt on the transition to the next second. Then
you have to tell second node about this event. But if you prefer loop for reading RTC time from
second node, it’s also good. Actually it doesn’t matter. In one case you read across network, in
second case you sent event across network. Theoreticaly, it is good solution for infinite fast
network. “But hardware works in case, not in theory” (c) one of my teachers.
Depending on the cycle time of your loop,
Also depending on a network speed for particular transaction and time it takes you to
spawn/exec/system the rtc command (or whatever you want to read the time on another node).
you can sync the second node
pretty acurate.
Originator of the thread wants 10 ms. But thank you for explanation. Actually, I missed that
quoted key sentence… or missunderstood it )
)