Hi David,
Thank you for your response and the graphs attached. Can you explain the
experimental setup used to obtain the results? Specifically, is this the
throughput seen at the application layer ( packets that passed CRC
Check)? How many motes were used in the experiment and were they
competing for the radio?
Regards,
Vinai.
David Moss wrote:
Hi Vinai,
I'm interested in this topic as well, and I have no answer as to why 29
bytes was chosen, but I've found that the optimal payload size depends on
what type of environment your network exists within. With any radio, if you
increase the available data length you're effectively decreasing the packet
header:data ratio. By increasing the data length as much as possible,
you're going to increase your data throughput to its maximum - in ideal
cases. This is because it takes less header information per data
information to transmit, and because on some radios (CC1000) the radio kicks
back and forth between Tx->Rx->Tx between every packet which takes an extra
512 uS per back-to-back packet. So by decreasing the number of transmitted
packets while still getting the same amount of data through, you're
obviously going to increase throughput.
However, if your network is in a noisy environment, then there's more chance
for the packet to get corrupted during transmission. In this case, it will
take longer to recover that packet because of its length - instead of losing
only a little bit of data, you're losing a lot of data. And this is what I
think your question is about - what's the nominal packet length that
minimizes the effects of noise while maximizing throughput? It's a design
problem.
I'm sure this can be simulated with some kind of packet success rate
probability for various environments, but it may be difficult to port that
over to the real world because the packet success rate in your network
environment may change over time, even by the minute. The best answer I can
give you is, increase your TOS_Msg payload length as much as you're
comfortable with while leaving enough free RAM on the mote to execute the
app, and run it in the environment you plan to deploy in. If it's indoors
with tight spacing, max out the payload. If it's outdoors on the ground
with wider spacing, might as well keep the payload size pretty modest.
The ultimate solution would involve some kind of back-end architecture that
provides the ability to recommend how much data the payload of the current
packet should be loaded with to maximize throughput based on an RSSI or LQI
or something, and also provide the ability to increase/decrease the transmit
power automatically to save battery on motes that are sitting near each
other in a noiseless environment.
I've attached several spreadsheets showing the packet throughput for mica-
mote types with varying payload sizes. Noise was not a factor in any of
these tests.
-david
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Vinai
Sundaram
Sent: Friday, April 21, 2006 1:39 AM
To: [email protected]
Subject: [Tinyos-help] Rationale for 29 bytes payload
Hi ,
I need to send more than 29 bytes for the application I am working on.
However, I do not want to increase the payload size so much that it will
reduce the throughput of the network. Is "29 bytes" found to give close
to optimal throughput? Are there any empirical/analytical studies that
suggest a payload size range that would give near-optimal throughput? I
didn't come across the reason for 29 bytes in any of the documents.
Thank you for your help,
Vinai.
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
