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-help > > !DSPAM:45d3597b42995915437362! _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
