Ok, I will take a look at that. What is strange though that people do
not seem to have trouble without Deluge. Miklos

On Mon, Oct 5, 2009 at 1:20 AM, Yee Wei Law <[email protected]> wrote:
> Sorry guys for this flurry of updates, but I'm eager to get this solved, so
> I'm posting yet another update.
>
> I found that the event SendDataMsg.sendDone() in DelugePageTransferP.nc
> takes forever to be triggered, so the networking stack for IRIS might indeed
> be problematic.
>
> 2009/10/4 Yee Wei Law <[email protected]>
>>
>> Hi guys,
>>
>> I think the problem with Deluge on IRIS goes deeper than the networking
>> stack (or might even have nothing to do with the networking stack) . For
>> example, I cannot delete an image properly:
>>
>> $ tos-deluge serial@/dev/ttyUSB3:57600 -e 1
>> Flushing the serial port..
>> Checking if node is a Deluge T2 base station ...
>> Image number 1 erased
>>
>> $ tos-deluge serial@/dev/ttyUSB3:57600 -p 1
>> Flushing the serial port..
>> Checking if node is a Deluge T2 base station ...
>> Pinging node ...
>> --------------------------------------------------
>> Currently Executing:
>>   Prog Name:   GoldenImageAppC
>>   UID:         0xFD5310DC
>>   Compiled On: Sun Oct 04 14:28:46 2009
>>   Node ID:     1
>>
>> Stored image 1
>>   Prog Name:   BlinkAppC
>>   UID:         0x878CE74E
>>   Compiled On: Thu Oct 01 17:53:37 2009
>>   Platform:    iris
>>   User ID:     ywlaw
>>   Host Name:   black
>>   User Hash:   0xE5206F15
>>   Size:        2672
>>   Num Pages:   13
>> --------------------------------------------------
>>
>> In the above, the image was not deleted although tos-deluge reported
>> success.
>>
>> Additional note: My version of TinyOS is from the CVS. I tested Deluge on
>> TelosB, and that works fine.
>>
>> Regards,
>> Yee Wei
>>
>> 2009/10/3 Razvan Musaloiu-E. <[email protected]>
>>>
>>> Hi!
>>>
>>> On Fri, 2 Oct 2009, Miklos Maroti wrote:
>>>
>>>> Hi Guys,
>>>>
>>>> I have never used deluge on IRIS before. Is this a recent problem or
>>>> has been always the proble? The default low power listening settings
>>>> has been reworked recently, mazbe it has something to do with that? Do
>>>> you see any other performance problem on the IRIS?
>>>>
>>>
>>> I just tried the burn-net script from apps/test/deluge/Blink and indeed
>>> it doesn't seem to work right on IRIS. I tried to use the CC2420DK sniffer
>>> to see what packets are send over the air and the packets were invalid. :|
>>>
>>> I also tried to go back to the version before default-lpl [1] and what I
>>> noticed then is that the tos-deluge fails to properly talk to the mote. I'm
>>> not sure why. As I said above, this works fine in the latest CVS.
>>>
>>> [1]
>>> http://hinrg.cs.jhu.edu/git/?p=tinyos-2.x.git;a=commit;h=fffd345e6fa1693873307844887c4370a0d75bb4
>>>
>>> --
>>> Razvan ME
>>>
>>>> On Thu, Oct 1, 2009 at 11:58 PM, Razvan Musaloiu-E. <[email protected]>
>>>> wrote:
>>>>>
>>>>> Hi!
>>>>>
>>>>> On Fri, 2 Oct 2009, Yee Wei Law wrote:
>>>>>
>>>>>> Hi Qiu, Razvan,
>>>>>>
>>>>>> I have some measurements on how slow Deluge actually is on the IRIS,
>>>>>> by
>>>>>> instrumenting the file
>>>>>> /opt/tinyos-2.x/support/sdk/java/PrintfClient.java
>>>>>> and capturing debug statements from DelugePageTransferP.nc
>>>>>>
>>>>>> To transfer 3696 bytes of data, a whopping 34.42 minutes were spent.
>>>>>
>>>>> Wow, that's very slow. I was not aware of this abysmal performance on
>>>>> IRIS. Perhaps somebody familiar with the RF230 can take a look. :D
>>>>>
>>>>> --
>>>>> Razvan ME
>>>>>
>>>>>> Do you have any advice on how I can speed up the process? According to
>>>>>> my
>>>>>> *preliminary* investigation, LPL is not enabled by default.
>>>>>>
>>>>>> Thank you in advance.
>>>>>>
>>>>>> Best regards,
>>>>>> Yee Wei
>>>>>>
>>>>>>
>>>>>> 2009/9/30 Razvan Musaloiu-E. <[email protected]>
>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>> On Wed, 30 Sep 2009, qiu ying wrote:
>>>>>>>
>>>>>>>  Thanks for your reply. By the way, I found another problem. I see
>>>>>>> the
>>>>>>>>
>>>>>>>> CVS code after 09/16 the LPL is default on,  but it seems Deluge
>>>>>>>> doesn't comptiable with LPL, I've found the GoldenImage with LPL
>>>>>>>> receive data very very slowly, for example, when send a 30K image, I
>>>>>>>> waited for 2 hours more, but it was still not finished.
>>>>>>>>
>>>>>>>>
>>>>>>> Without any configuration the default lpl committed on 09/16 is
>>>>>>> equivalent
>>>>>>> with the always on configuration. If it doesn't then it's a bug that
>>>>>>> we have
>>>>>>> to fix.
>>>>>>>
>>>>>>> Deluge T2 with LPL always took a long time. A deeper investigation
>>>>>>> might
>>>>>>> reveal a way to make it faster though. :-)
>>>>>>>
>>>>>>> --
>>>>>>> Razvan ME
>>>>>>>
>>>>>>>
>>>>>>>  My platform is iris and uses the latest CVS, can you help me with
>>>>>>> this?
>>>>>>>>
>>>>>>>> 2009/9/21 Razvan Musaloiu-E. <[email protected]>:
>>>>>>>>
>>>>>>>>> Hi!
>>>>>>>>>
>>>>>>>>> On Fri, 11 Sep 2009, qiu ying wrote:
>>>>>>>>>
>>>>>>>>>  Hi,
>>>>>>>>>>
>>>>>>>>>> I know Deluge can reprogram all the motes in a network. But I just
>>>>>>>>>> want
>>>>>>>>>> to reprogram a mote with specific ID. Is there  an existing
>>>>>>>>>> component can do
>>>>>>>>>> this? Or is it possible to modify Deluge to achieve this?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> In Deluge T2 there is no per-node filtering. The DelugeP.nc from
>>>>>>>>> tos/lib/net/Deluge is responsible for what happens when a node
>>>>>>>>> finds about a
>>>>>>>>> new image. The two functions in which reprogramming using tosboot
>>>>>>>>> is trigger
>>>>>>>>> are ObjectTransfer.receiveDone and DelugeMetadata.readDone. You
>>>>>>>>> could add
>>>>>>>>> some condition to those action if you want.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Razvan ME
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>
>
>
> _______________________________________________
> Tinyos-help mailing list
> [email protected]
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>

_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to