Joe is right about other delays in the system
Assuming TmoteSky means Boomerang 2.0.4 and default compile.
Default CPU speed is 4 mhz
Default 802.15.4 ACK is in software
Default RX is RXFIFODelayedRead at a task level.
You have the following linear delays
Radio Stack of Boomerang 2.0.4
Move packet to TXFIFO 19usec per byte on the SPI bus
Transmit packet 32 usec per byte on the RF
RXFIFODelayedRead at 48 usec per byte on the SPI bus
Software ACK after Read
TX holds off until ACK received
start all over
Other issues will be RXFIFO overflow at 120 byte packets
with 5 byte ACKs, and the Radio stack does a RXFIFOFlush
after each ACK received, who knows what it is flushing
and may be causing retransmissions.
Some options are to compile for 8 mhz CPU. This reduces
RXFIFODelayedRead to 33 usec on the SPI bus.
Reduce the packet size to 64 total bytes or less to allow
two packets in the RXFIFO. Total bytes is Length, FCF and
RSSI/LQI bytes on top of packet size.
francis
Joe Polastre wrote:
Remember that the radio takes 450us to switch from RX>TX and another
450us to switch back from TX>RX. There are other associated delays.
-Joe
On 7/11/07, Chonggang Wang <[EMAIL PROTECTED]> wrote:
Thanks for the posting, Phil. Yes, There is a backoff in CSMA-CA.
However the backoff is not that much to make 250 Kbps down to 35 Kbps.
The reason is below.
According the IEEE 802.15.4 standard 2003 version, the average backoff
time will be (2^BE * aUnitBackOffPeriod * aUnitSymbolTime) /2 . Also
according to the standard, aUnitBackOffPeriod = 20 and aUnitSymbolTime
= 1/SymoblRate = 1/ 62.5K = 16 us (for 2.45 GHz PHY). In this
experiement, there is no collision, therefore BE = macMinME. macMinME
is between 0 and 3. If it is 0, there is no backoff. Let us choose the
maximum 3 and BE=3.
Therefore, for each packet, the average backoff time is about
(8*20*16)/2 = 1.28 ms. In my experiment, the UDP packet length is 110
Bytes and consider 10 bytes or so overhead, it is 120 bytes in total,
and the consumed time is 120*8/250K = 3.84 ms.
Therefore the achieved throughput should be around
(3.84/(3.84+1.28))*250K = 187.5 Kbps. Am my understanding right?
187.5 Kbps is still far larger than 35 Kbps. I still do not know the
reason.
Thanks,
Chonggang
----- Original Message -----
From: Philip Levis <[EMAIL PROTECTED]>
Date: Wednesday, July 11, 2007 1:57 pm
Subject: Re: [Tinyos-help] throughput of tmote sky
To: Chonggang Wang <[EMAIL PROTECTED]>
Cc: tinyos-help@Millennium.Berkeley.EDU
> On Jul 11, 2007, at 10:48 AM, Chonggang Wang wrote:
>
> > Hello,
> >
> > I am trying to test the pure throughput of 802.15.4 and conduct
> an
> > experiment as follows:
> >
> > \/ \/
> > | |
> > ----------- ------- --------
> > -----------
> > | PC1 | |Mote1| |Mote2| | PC2
> |
> > | |-----| | |
> > |---------| |
> > ---------- ------- --------
> > ----------
> >
> >
> > Both motes are placed close (guarantee good channel condition)
> and
> > configured as Base Station by being installed TOSBase
> application.
> > There is a sender program at PC1 and a receiver program at PC2.
> > Both PC1 and PC2 start SerailForwarder (SF) (I changed the
> original
> > SF in order to support UDP and avoid the effect of TCP Congestion
>
> > Control and ACK). The baud rate for both motes is 115200.
> >
> > Then the sender program at PC1 continuously send a file (large
> > enough) to SF at PC1 through UDP socket. The receiver program at
> > PC2 listens to the SF's UDP port at PC2 and calculate the
> received
> > data rate. I repeated this experiment for lots of times and found
>
> > the received data rate at PC2 is only about 35 Kbps. Since tmote
> > sky uses chipcon 2420 with 250 Kbps data rate, 35 Kbps is
> > surprisingly pretty slow since in this case there should not be
> any
> > collision. I am not sure if those two motes automatically go to
> > sleep state. Also i did not find any bad packet due to CRC
> failure
> > in SerialForwarder.
> >
> > Could any one give me a clue?
>
> MAC backoff.
>
> Phil
>
_______________________________________________
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
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
