On Wednesday 14 February 2007 14:57, Michael Schippling wrote: > For my robots, and subsequent radio reliability testing, I invented a > call and response message system with ACKs and a retry layer based on > missing sequence numbers, where the base station PC asked for a resend > when it missed a seqnum. But the one half of it is on the Java side so > it may not be of much use to you. See my code bolus at: > http://www.etantdonnes.com/Motes/robocode.tar.gz > and the various other files in that directory.
Sound's a bit like how tcp uses sequence numbers. I'll take a look at your work. Thanks for the good feedback! BTW, I just read your Mica2 radio analysis paper and found it very interesting. Steve > Ideally you'd like the store queue to empty faster than the input fills, > over whatever period that you have enough memory for the queues. And given > that you want to handle store-and-forward over unreliable links, you'll > have to spread that around all of your nodes. The one saving grace is that > the total number of messages is reduced because you are repeating messages > in each node's local environment. > > So the basic issue is that there is a finite radio message bandwidth > (which I initially measured at about 100 msg/s in the above, but it may > have been serial-comm limited with the micaz and I haven't retried...) that > you need to be able to store with what sounds like a smaller finite-BW > process. Then you will always need a throttle-retry mechanism of some kind. > Doing that with just ACKs could lead to the flooding issue, and I've > observed that ACKs are missed on occasion too. So some kind of destination > initiated retry request would probably be best, even if it uses up some of > your radio BW. > > hope my random thoughts help something... > MS > > Steve McKown wrote: > > On Wednesday 14 February 2007 11:11, Michael Schippling wrote: > >> An embeded RDB that runs too slow? I would do a little profiling on the > >> app to see if there's anything to fix before starting to throttle > >> messages. If the messages are bursty perhaps adding a insert queue to > >> the DB i'face would even things out. Depending on the DB you might be > >> able to do multiple inserts in one statement, that could speed things up > >> too. > > > > Its the flash filesystem; all IO to flash is quite slow. I'batching db > > inserts from multiple messages into relatively large DB transactions to > > get decent (but not great) performance. I'm certainly going to keep > > working this issue separately. But I digress... > > > > There's a lot of conditions where a message receiver might not be able to > > handle a sender's message. Ideally, the network design would be > > resilient so that such conditions don't unnecessarily cause data loss. > > Our motes will often be 'disconnected' from the network (aka out of range > > of the gateway), so perhaps message reliability is a bigger issue in our > > case. > > > >> Otherwise running the ACK mechanism through the basestation to the host > >> and doing some kind of request-retry thing should work. > > > > OK, I'm not way off track. But "should work" isn't a glowing review of > > the strategy! Any other ideas? Surely I'm trying to recreate the > > wheel... > > > >> You want to avoid > >> the "flooding with retries" scenario that kills e'nets though. > > > > No question. Our retry delay algorithm has to be very non-linear because > > I'm also planning to use no-ack conditions to allow a mote to conclude > > that it has gone out of range of the gateway. So, with a small frequency > > of no-ack conditions, the algo must act like ethernet's collision > > avoidance and send throttling logic. At a higher frequency of no-ack > > conditions, it needs to drive the retry delay way up to act as a polling > > interval to determine when it's back in range of the gateway again. > > > > Thanks for the feedback, > > Steve > > > >> An occasional bad crc is to be expected, I'm not sure that it's a > >> symptom of message overflow. But missing sequence numbers certainly > >> is... > >> > >> MS > >> > >> Steve McKown wrote: > >>> Hi, > >>> > >>> I have a current wireless star network: ARM gateway connected to a Xbow > >>> mote running BaseStation and several wireless motes that send unicast > >>> packets to the gateway/BaseStation. The wireless motes request acks > >>> and will initiate a resend of any message whose ack is not seen in > >>> sendDone(). The gateway uses the c-sdk to retrieve messages from the > >>> BaseStation, processes them and stores the results in a local embedded > >>> database. The gateway allows query of the RDBMS and presentation of > >>> its contents via a simple HTTP-base app it also runs. > >>> > >>> This setup works great until the receive rate of wireless messages > >>> exceeds the rate at which the gateway can insert them into the > >>> database. I tested this scenario by using only 1 wireless node and > >>> having it send messages to the gateway as fast as it can (still with > >>> ack/resend logic). In this test, the gateway will frequently show a > >>> bad_crc message from the c-sdk. At the same time, the gateway loses > >>> visibility to dozens of messages, based on message sequence #s. > >>> > >>> Here's what I think I need to do to extend BaseStation to get better > >>> message delivery reliability. Any comments or pointers to related > >>> information would be helpful. > >>> > >>> 1. BaseStation should elect to send acks for received messages based > >>> upon the filled state of the appropriate message queue (readioQueue, > >>> uartQueue) in addition to the crc check. > >>> > >>> 2. BaseStation should use a back-off/resend strategy for any message > >>> sent over uart or radio for which an ack is not received in a timely > >>> fashion. > >>> > >>> Am I on the right track? Is BaseStation a good place to start? > >>> > >>> Sorry for the long post, and thanks for your consideration. > >>> Steve > >>> _______________________________________________ > >>> Tinyos-help mailing list > >>> [email protected] > >>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-he > >>>lp > > !DSPAM:45d38abe104221542430122! _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
