Hi Matt,
Thanks for your response. Yes, the number of bytes transmitted over
radio is simply the length parameter passed to SendMsg.send( ) and not
fixed 29 bytes. However, if we always have packets with payload larger
than 29 bytes to send, it is necessary to increase the payload size.
Regards,
Vinai.
Matt Thompson wrote:
I know with the CC2420 radio, the payload size you select does not
affect how many bytes are actually transmitted over RF. I'm not sure
about the CC1000 though.
I use a payload size of 90, but if I send 4 bytes of payload, only
MSG_HEADER_SIZE + MSG_FOOTER_SIZE (FCF) + payload len bytes are transmitted.
Cheers,
Matt
Vinai Sundaram wrote:
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: tinyos-help@Millennium.Berkeley.EDU
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
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
