Andreas B. wrote: > On Thu, 2006-10-05 at 18:31 +0200, Jan Kiszka wrote: >>> I'm working on Realtime-Ethernet in conjunction with Distributed Clocks. >>> I wonder if anybody ever tried the following combination: >>> >>> RTAI + RTNet + Distributed Clocks >>> >> Yes (of course ;) ), our more complex robots uses RTnet for >> synchronising (and distributing) sensor data in real-time. An older >> example is [1]. Our accuracy requirements /wrt data time stamps are >> fairly low (~1 ms), though. > > Hello Jan, hello list, > > I think I have a different oppinion regarding 'distributed clocks'. I > want to try to get completely independent from the network.
Even IEEE1588 is not "completely" independent form the network, it only requires less frequent synchronisation than the simple mechanism of RTnet. Still, due to changing clock drifts over the time (think of varying temperatures), you have to resync in certain intervals. > > Very simple example: > ==================== > Imaging we have higly syncronized clocks in our network on every device. > Then you could send a packet including a timestamp (pointing to the > future) and a action that should be executed on each node. The package > could be sent 5 minutes > before the action has to happen. > If the time on each node is the time in the timestamp the action would > be executed. > EACH node would execute this action simultaniously independent from > delays introduced through the network. > > > > If the clocks are syncronized very well (this is the point I need > IEEE1588 for) I > would have a system doing actions 'absolutly' at the same time. Again, there is no difference in the basic idea, we could just enhance the clock synchronisation in a way that it can provide more stable clocks without having to resync every few miliseconds. You can already schedule time-triggered jobs on distributed RTnet/TDMA nodes far into the future. But when hunting for submicros in clock synchronisation, don't forget: time-triggered jobs even on boxes with ideally sync'ed clocks will still suffer from software related jitters you can see when running usual latency tests. And they may compete with other high-prio RT-jobs like RTnet. That's unavoidable unless to throw dedicated controllers on this - i.e. forget about using Linux and a complex RT system in parallel on the same silicon. > > > Any suggestions on this? > > > Andreas > > > PS: IEEE1588 can be found in many RT-Ethernet solutions out there on the > market. > Profinet, Ethernet Powerlink (V3), Ethercat .... Yes, I know very well. > > PTP was designed to be more precisely then NTP. PTP for example > tries to > eliminate the jitter introduced through the network stack and the OS > (Not completely possible with an SW only solution like the PTPd I > mentioned) Cannot really judge on this due to lacking detail knowledge, but I would be interested in learning what *protocol* differences helps PTP to achieve more accurate clock synchronisation than NTP. Wouldn't this be possible with NTP as well once you remove the network stack latency (RTnet takes timestamps in early IRQ context) and put it into the switches to compensate traffic-related jitters (RTnet controls the network traffic, so there is no need for this)? Jan ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
