> -----Original Message----- > Date: Mon, 04 Sep 2006 10:24:22 +0200 > From: Jan Kiszka <[EMAIL PROTECTED]> > Subject: Re: [RTnet-users] Atheros wifi driver > To: [EMAIL PROTECTED] > Cc: rtnet-users@lists.sourceforge.net > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-15" > > Sounds really interesting. Do you consider to integrate your protocol on > top of RTmac? If something is missing in its interface to do this, let > us know. > > A bit background on our plans with RT-WLAN: it's clear that > deterministic transmission is practically infeasible over WLAN, you > simply cannot control the media with all those bubbling devices around > today. Therefore our aim is to provide best-effort short latency data > delivery with as much control on error handling as possible (real-time > data often prefer drop-on-error over repetition). At the same time, > attaching a RT-managed WLAN adapter must not disturb other > RT-applications an a node in an unpredictable way, even in noisy > environments. The latter aspect still needs more research.
As we need to use RTAI to get correct TDMA timing in our prototype, it would seem reasonable to try and integrate it with RTnet. We have versions of our dynamic TDMA election and routing protocols that we expect to make public and some fancier versions that would be licensed (we are a commercial company :) Our goal is not really a RT network, but a multi-hop ad hoc network that supports probabilistic QoS for voice and video applications over an extended multi-hop network. Also, the RTmac format with master/slave time keepking is not what we will use. So, it would be more of an "integrate with" rather than "build on" effort, I think. Our goal is to integrate something like Rentel & Kunz (WCNC 2005) distributed time sync in to the TDMA protocol at the MAC layer. As protocols like these become much more stable with increasing beacons, they should do well in a TDMA where there is little cost (unlike 802.11) to transmitting timing information per slot. For now, however, we are using a PPS signal because it was fast to implement. One reason we were looking at the Atheros cards is it appears that we can disable carrier sense, which would get around the unbounded backoff problem you note. This still needs to be verified, but it looks do-able. I will take a shot at working with the madwifi-ng drivers and see how it goes. I will keep you posted. Marc ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users