Oh, I thought "embeded db" meant a host side program, not the EEPROM...
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.
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
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
!DSPAM:45d3597b42995915437362!
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
