I was talking about the Radio Stack only. This is
based upon using MultihopLQI and SP underneath it.
The Serial port and SF stack, I have no detail knowledge
about since we only use it at a Gateway. My use
of TOSBase has been limited to a packet sniffer
function.
I think the movement of data is causing most of
your delays if you are not using SP's ACK. Loading
and emptying the FIFO is not free, Serial moves may
not be free also if SF does CRC's.
I had packet duplication and other problems, this
is why I looked into the SPI bus timing using
64 byte AM packet sizes.
I do have Logic analyzer logs of this from TmoteSky's.
With MultihopLQI and SP lowpower a lot of things
happen to packets from mote to Gateway.
francis
Chonggang Wang wrote:
Thanks a lot, Francis.
"Default 802.15.4 ACK is in software" - do you mean the ACK implemented in SerialForwarder (SF) or else? I noticed there is ACK and CRC in net.tinyos.tools.Packetizer, which is invoked by SF.
By the way, I was wondering why Packetizer implements CRC since CC2420 already
has 2420?
Sincerely,
Chonggang
----- Original Message -----
From: Francis Simoneau <[EMAIL PROTECTED]>
Date: Wednesday, July 11, 2007 4:23 pm
Subject: Re: [Tinyos-help] throughput of tmote sky
To: Joe Polastre <[EMAIL PROTECTED]>
Cc: Chonggang Wang <[EMAIL PROTECTED]>, Philip Levis <[EMAIL PROTECTED]>,
tinyos-help@Millennium.Berkeley.EDU
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
