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.
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.
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 ....
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)
> >
> > For synchronisation of the clocks I would use the Precision Time Protocol
> > (PTP) (see IEEE1588). An Daemon for PTP can be found here
> > http://ptpd.sf.net
> >
> > With this solution you could synchronise actions up to a sub-microseconds
> > level independent from the amount of stations taking part in the
> > RT-Communication.
>
> Be warned about the patent situation with IEEE1588. I once considered to
> aim for integrating related support in RTnet but dropped the idea
> because it looked to me (IANAL) like that protocol (or better: an
> implementation in some device) is contaminated.
>
> >
> > Are there similar projects - or has anybody ever worked on
> > timestamping/distributed clocks?
>
> Depending on your requirements (accuracy, number of nodes, network
> structure, etc.) RTnet's TDMA service may already provide what you need.
> If not: any (non-1588) enhancement of RTnet's still fairly dumb
> synchronisation protocol would be warmly welcome! Maybe something like
> NTP over RTnet?
>
> I'm not so deep into what advantages PTP provides over NTP, except that
> the former typically runs on dedicated hardware or makes use of
> hardware-based packet time stamping to reduce software related jitters.
> There is currently quite a lot of work on efficient NTP for the Linux
> kernel going on ("scaled math"), maybe this is also worth a look. RTnet
> would prefer to see an efficient solution :) since it may run on fairly
> low-end boxes.
>
> Jan
>
> [1]http://www.rts.uni-hannover.de/images/b/b6/RTS_STILL_EURON_Technology_Transfer_Award.pdf
>
-------------------------------------------------------------------------
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
