Resending this mail for peoples attention.
regards,
Avinash
---------- Forwarded message ----------
From: Avinash Sridharan < [EMAIL PROTECTED]>
Date: Aug 7, 2006 10:55 AM
Subject: problems with using block storage at high data rate in tinyos-2.x beta2
To: tos <[email protected] >
Hi All,
I was having problems using the block storage device when I am using it to log data at high data rates. The settings for the CSMA are , the initial backoff is between 0-10ms and the congestion backoff is 0-3ms. I am using the tmote sky platform for my experiments.
The logic I am using to use the block storage device is as follows:
a> I have a buffer of size 10, with each element of 22 bytes. When ever I have to log data (an element of size 22 bytes) I log it to this buffer. Once I have sotred 10 elements in the buffer I call the BlockWrite.write command.
b> After 10 such writes I call commit, so I am commiting 22*10*10 bytes of data.
Now the experiment I am running generates a constant packet rate data, I am generating a packet by firing a fixed size timer. The packet is logged whenever it is sent out into the air. I am generating data with timer sizes of 10ms, 11ms, 12ms,13ms, 15ms and 20ms.
The Problem:
Due to contention at high data rates (when the timer size is close to 10ms) there is queueing taking place at the sender and the logging is also happening at a very fast rate. It turns out that at such a high rate when the commit call is made it blocks and does not return. It seems at these high data rates tinyos deadlocks and is not able to execute any other code.
More specifically I can observe this behavior at rates of 10ms and 11ms, as I go to lower rates the applications works fine. Also this behavior is erratic in the sense there are times when the logging at 10ms and 11ms works fine without blocking.
To test that the application has deadlocked and has not crashed, once I see that the application has been deadlocked (I know this since the application has to send a total of 5000 packets out if it has sent less than this many packets I assume there is a problem), I do a read on the flash (around 10 lines of data) and immediately the application starts sending out the remaining number of packets to the forwarding node.
Further I tried changing the initial backoff window to 3ms and the congestion backoffwindow also to 3ms, now my application is able to work easily at rates of 10ms and above but it starts failing close to 8ms.
Questions:
a> Could somebody clarify the deadlock behavior I am observing ( Or if it is even deadlock) and if someone else has observed this behavior ?
b> Are there some performance measures as to how fast and how much data can we write and commit on the block storage device ? This will help define the capacity of the system better.
PS: The problem is with the logging, since when I turn off my logger component, the application is able to run comfortable to datarates with fixed timer sizes close to 8ms without problems.
regards,
Avinash
I was having problems using the block storage device when I am using it to log data at high data rates. The settings for the CSMA are , the initial backoff is between 0-10ms and the congestion backoff is 0-3ms. I am using the tmote sky platform for my experiments.
The logic I am using to use the block storage device is as follows:
a> I have a buffer of size 10, with each element of 22 bytes. When ever I have to log data (an element of size 22 bytes) I log it to this buffer. Once I have sotred 10 elements in the buffer I call the BlockWrite.write command.
b> After 10 such writes I call commit, so I am commiting 22*10*10 bytes of data.
Now the experiment I am running generates a constant packet rate data, I am generating a packet by firing a fixed size timer. The packet is logged whenever it is sent out into the air. I am generating data with timer sizes of 10ms, 11ms, 12ms,13ms, 15ms and 20ms.
The Problem:
Due to contention at high data rates (when the timer size is close to 10ms) there is queueing taking place at the sender and the logging is also happening at a very fast rate. It turns out that at such a high rate when the commit call is made it blocks and does not return. It seems at these high data rates tinyos deadlocks and is not able to execute any other code.
More specifically I can observe this behavior at rates of 10ms and 11ms, as I go to lower rates the applications works fine. Also this behavior is erratic in the sense there are times when the logging at 10ms and 11ms works fine without blocking.
To test that the application has deadlocked and has not crashed, once I see that the application has been deadlocked (I know this since the application has to send a total of 5000 packets out if it has sent less than this many packets I assume there is a problem), I do a read on the flash (around 10 lines of data) and immediately the application starts sending out the remaining number of packets to the forwarding node.
Further I tried changing the initial backoff window to 3ms and the congestion backoffwindow also to 3ms, now my application is able to work easily at rates of 10ms and above but it starts failing close to 8ms.
Questions:
a> Could somebody clarify the deadlock behavior I am observing ( Or if it is even deadlock) and if someone else has observed this behavior ?
b> Are there some performance measures as to how fast and how much data can we write and commit on the block storage device ? This will help define the capacity of the system better.
PS: The problem is with the logging, since when I turn off my logger component, the application is able to run comfortable to datarates with fixed timer sizes close to 8ms without problems.
regards,
Avinash
--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
