Hi Vinai, My guess of the default max payload size is to reduce RAM overhead, since each TOS_Msg structure will use more RAM when the max payload size is increased.
I can't see that using a larger payload size would adversely affect performance. There would be more overhead fragmenting larger packets into 29 byte payloads, due to the header overhead, not to mention extra CPU cycles and complexity of fragmentation and reassembly. Cheers, Matt Vinai Sundaram wrote: > 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: [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 >>> >>> >> >> >> >> >> >> > _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
