I did some test lately as well. I checked rather influence of layers on
transmission speed and I used 32kHz timer too, but now I am interested in
more precise time testing, ie. CPU cycles. However it's hard for me to go
deep into TinyOs to get the lowest layer - very close to physical.
I gave up and I think other OS like LiteOS (without all that abstraction) is
better for testing device.

2011/3/29 <prasannakart...@cse.iitb.ac.in>

> hi,
>   I did some measurements recently. I quantified the time taken by the
> different components. Here are my results:
>
> before Amsend.send() statement 64420
> Send.send() 64426
> send() 64427
> AcquireSpiresource() 64431
> before loadtxfifo() statement 64432
> Loadtxfifo() 64433
> before TXFIFO.write() statement 64440
> after TXFIFO.write() statement 64446
> TXFIFO.writedone() 64519
> AttemptSend() 64521
> CaptureSFD.capture() 64655
> ReleaseSpiresources() 64538
> after loadtxfifo() statement 64447
> after Amsend.send statement 64448
> Amsend.Senddone() 64662
>
> All time values are based on 32Khz timer. CCA has been disabled. Also, DMA
> has been enabled. This is for 100 Byte packets on telosb platform.
> Tx time : 135 ticks => 4.2 msec
> Spi copy time without s/w overheads: 73 ticks => ~2.5 msec
> Hope this helps.
>
> I would like to know how you are measuring the time values. If you are
> using printf's(like i did a few days back), then the values are likely
> blown up.
>
> > Hi
> >
> > Does it happen in every packet transmission?
> > If no, maybe some packets are retransmitted by PacketLink Layer?
> >
> > 2011/3/28 蔡沅峰 <starry1...@yahoo.com.tw>
> >
> >> Dear all,
> >>
> >>
> >> We have a high-data-rate application and we need to decrease the
> >> transmission delay (between send.send and send.sendDone).
> >>
> >> The payload of our packet is 80 bytes. ( Total packet size is about 100
> >> bytes in Tinyos )
> >>
> >> We've adjusted the initial backoff time defined in CC2420csmaP.nc to the
> >> range of 10~60 ticks (under 32khz clock)
> >>
> >> The above two added is about 100*8/250(kbits/sec) + 35/32768 = 4.27ms
> >>
> >> But when we measure the time between send.send and send.sendDone, the
> >> result is 7.82ms, much bigger than 4.27ms
> >>
> >> Even though we take the congestion backoff time into account( 10~80
> >> ticks
> >> ----> 45/32768 = 1.37ms ), the result is still less 7.82ms
> >>
> >> But the inteval between our testing data packest is 3 seconds, the
> >> congestion backoff time shouldn't exist.
> >>
> >> Our application is broadcast, so we don't consider ACK wait time.
> >>
> >> Does anyone know why the larger transmission delay in our experiment?
> >>
> >>
> >> We also record the time when the packet is send out ( by the SFD
> >> interrupt
> >> ), the time between this SFD time and send.sendDone is about 1.99ms
> >>
> >> What confuse us is this time is much less than the data transmission
> >> needed
> >> (4.27ms), does anyone know why?
> >>
> >>
> >> Many thanks!!
> >>
> >>
> >> Best regards,
> >>
> >>
> >> Sean
> >>
> >> _______________________________________________
> >> Tinyos-help mailing list
> >> Tinyos-help@millennium.berkeley.edu
> >>
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
> >>
> >
> >
> >
> > --
> > Pozdrawiam,
> > Damian Rusinek.
> > _______________________________________________
> > Tinyos-help mailing list
> > Tinyos-help@millennium.berkeley.edu
> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
>
>


-- 
Pozdrawiam,
Damian Rusinek.
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to