On 30/03/13 13:43, John Hasler wrote:
BTW what kind of accuracy do you need and how quickly must your machines
converge to it? Ntpd may not be your best choice. It's designed to
synchronize always-on machines with relatively low drift rates over the
Internet.
That depends entirely on the performance of the communication framework
we are using.
Which is what I'm trying to measure.
You see I have these machines without an RTC so on startup they sync
with the local time server (which is always on and always connected so
it keeps itself synced with other servers).
We are using ROS (www.ros.org if anyone is familiar) which has its own
comm layer above the TCP/IP stack, plus all the other fake-kernel stuff
it uses to appear as a framework and provide functionalities as if any
program were running on the same machine.
So I want to measure the overhead of all of this, and how much this
overhead is affected by network type and network congestion (1 robot, 2
robots, 3 robots, ethernet or wifi, etc), frequency of requests, number
of open sockets... you get the picture.
Fact is the system was born for wired networks and loosely coupled
systems (not real time).
We are evaluating its performance on wireless networks and semi-real
time systems.
We have to get some numbers.
I'm open to suggestions as to how to meter these variables in this
situation.
My main course of action was to create some control message paths so
that they get affected the same as real message paths by varying
conditions, and use these messages to gather data (essentially like a
ping, but running inside the framework and possibly with daisy-chained
stations in between). But that, as said before, would use local clock
sources so I then thought that if I could know the accuracy of the clock
I could also either augment the accuracy of the measure, or at least
give a more accurate error figure about the measure.
BR
Claudio
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
