[Tinyos-devel] Crc interface buffer size restriction

[Chieh-Jan (Mike) Liang]

I tried a 8K byte-array on telosb, and it took about 80 ms. This is  
with the loop-free implementation in Crc.h. The table-lookup version  
cuts this time by about half (as Andreas pointed out).

I have a BigCrc component with split phase to deal with large byte- 
array. I can check in if it will be useful to anyone.

Mike

On Jan 15, 2009, at 9:05 AM, Andreas Köpke wrote:

>
> Philip Levis wrote:
>> On Jan 14, 2009, at 1:07 AM, Andreas Köpke wrote:
>>> Vlado Handziski wrote:
>>>> On Tue, Jan 13, 2009 at 11:07 PM, Philip Levis
>>>>
>>>> <pal at cs.stanford.edu> wrote:
>>>>> On Jan 13, 2009, at 1:41 PM, Philip Levis wrote:
>>>>>
>>>>> One other thought: if you want a 16-bit length CRC interface,
>>>>> chances
>>>>> are you want it to be split-phase, due to the possible time  
>>>>> duration
>>>>> of the operation.
>>>>
>>>> There are also alternative table look up versions in the eyesIFX
>>>> folder
>>>> that can be useful.
>>>
>>> However, the table lookup is only twice as fast as the current  
>>> default
>>> implementation, which itself is an 10 times improvement over the
>>> original bit
>>> shift for loop. You might want to do time measurements before
>>> deciding whether
>>> it should be split phase: the LPL channel check for telosb takes
>>> 11ms in an
>>> atomic block
>>
>> This is totally broken and should be fixed.
>
> Well -- tough task. It would require to enable the interrupt on the  
> CCA pin,
> but currently there is a single component that is coded around the  
> assumption
> that it is the only receiver of such an interrupt.
>
>>> and the 64bit multiplication of the default random number
>>> generator takes about 1ms in an atomic block.
>>
>> It's doing the multiplication in software because the codegen for
>> multiply is broken in the gcc version we use. IIRC, boomerang solved
>> this by doing a little bit of assembly for a hw multiply. We might
>> want to do the same thing.
>
> Question is rather: why does it have to do this in an atomic block?  
> Did anyone
> check lately whether the HW multiplier still does not work for the  
> latest
> msp430-gcc?
>
>>> So I guess we can spare the 1ms
>>> for 16bit CRC in an non-atomic block easily.
>>
>> My concern was doing a CRC over 65,535 bytes. That would take much
>> more than 1ms, right?
>
> On an eyesIFX it would take about 0.9s -- slightly more than 1ms ;-)
> For telosb it should be around 0.45s, due to the fact that it uses  
> the table
> lookup from Ross' CRC guide. Well, not many nodes do have 64k RAM.
>
>> Phil
>
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel