Vinai, There were two motes used: One was Rx-only and the other was Tx-only. Nothing was competing for the radio.
The throughput was at the application layer, using GenericComm. CRC's were checked, and the motes were sitting about 3 feet apart. The Tx mote would start sending a message, and as soon as the sendDone event occurred it would send another - basically go as fast as it could. The number of messages sent is tallied up, and at the end of each second you know how many packets were sent over the past second. That information - the packets/second from the last full second - is sent as part of the payload in the transmitted messages. Then it's possible with a sniffer to find out how many packets the Tx mote is sending each second. The Rx mote is can be a little more difficult. In order to get an accurate measurement, you don't want the Rx mote transmitting anything and just accumulating the packets/sec. But you still need to get the information out of there somehow. I did it by letting the Rx mote send out a single message about every 10 seconds, which contained the average packets/second it was seeing from each of the full seconds it was able to accumulate. -david -----Original Message----- From: Vinai Sundaram [mailto:[EMAIL PROTECTED] Sent: Friday, April 21, 2006 9:47 PM To: David Moss Cc: tinyos-help@Millennium.Berkeley.EDU Subject: Re: [Tinyos-help] Rationale for 29 bytes payload 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
