Open bkozak-scanimetrics opened 8 years ago
It's very likely that it's a bug. After all this is all growing software, reusing old parts. Try fixing it, run the test-suite and if it works fine, send a pull-request. You're more likely to get decent feedback then.
I don't think that's a bug, but I agree things can be improved in the particular case described here (packets en-queued from packet_sent callback) I added a comment under https://github.com/contiki-os/contiki/pull/1167
This is related to the test I am performing in #1165.
I have found that when using ContikiMAC with RIME (I think this may also apply to other network stack configurations), if I try to queue up packets one after another using the unicast "sent" callback, I actually get a severe throughput decrease.
After some debugging, I found that the majority of this slowdown occurs because of the behaviour of
free_packet()
in csma.c. What happens is that, if there are a number of packets queued together,free_packet()
will setup a ctimer to transmit afterdefault_timebase()
time ticks have elapsed. This will only happen if there are packets in CSMA's neighbour queue but ContikiMAC does not send them all at once (this is the case if the queued packets do not have the PENDING attribute set).So, we can actually have (much) faster sending by sending packets one at a time in the application such that we never have a queue in the csma driver. If the receiver is performing duty cycling (which is not the case in my test) I don't think that there will be any slowdown because
default_timebase()
will wait for only onechannel_check_interval()
.I don't see any good reason for this behaviour (although perhaps someone can tell me why it exists) and suspect that it may be a bug.
Thanks.