15 messages in net.java.dev.spots.devRe[2]: Radio update, update| From | Sent On | Attachments |
|---|---|---|
| Ron Goldman | Mar 11, 2009 1:37 am | |
| John Daniels | Mar 11, 2009 2:01 am | |
| Ron Goldman | Mar 11, 2009 2:15 am | |
| John Daniels | Mar 11, 2009 2:46 am | |
| Markus Bestehorn | Mar 11, 2009 6:24 am | |
| Bart Braem | Mar 11, 2009 6:52 am | |
| Robert Taylor | Mar 11, 2009 7:24 am | |
| John Daniels | Mar 11, 2009 7:56 am | |
| Bart Braem | Mar 11, 2009 8:11 am | |
| Kurt Smolderen | Mar 11, 2009 11:04 am | |
| Ron Goldman | Mar 11, 2009 4:25 pm | |
| Ron Goldman | Mar 11, 2009 4:47 pm | |
| Ron Goldman | Mar 11, 2009 6:13 pm | |
| Ron Goldman | Mar 11, 2009 6:26 pm | |
| Stephan Kessler | Mar 16, 2009 12:04 am |
| Subject: | Re[2]: Radio update, update | |
|---|---|---|
| From: | John Daniels (jd...@syntropy.co.uk) | |
| Date: | Mar 11, 2009 2:46:46 am | |
| List: | net.java.dev.spots.dev | |
Hi Ron,
I just saw an out-of-memory error earlier today. Did you determine what was causing those errors and why slowing down transmission prevented them? Was it just the accumulated received packets awaiting processing?
I have a hazy memory of this. I think the problem is that packets build up on the radiostream output queue, waiting to be processed by the application (the OTA code in this case). The radiostream flush() doesn't help in this case because as far as the receiving radiostream is concerned all is well and the end-to-end ack (if multihop) is sent. The CRC stream doesn't have this kind of queuing which is why it solves the flow control problem. The CRC stream doesn't send the ACK until the application has read the incoming data.
--John