The surge program uses a Timer to start ADC conversions which subsequently
post message sends. You said you are sending at more than 100 packets/sec,
so I assume that you changed the "timer_rate" in
Timer.start(TIMER_REPEAT, timer_rate);
My comment of "a minimum of 4" means that Timer.start() returns a fail
if you try to set a rate below 4 (TOS-milli-seconds) and doesn't start
the timer. This change was made circa TOS1.1.10 for some vague reason,
since it works fine for me on mica2 at 1ms in T1.1.7...
And, if you did not change the SurgeMsg it doesn't matter what you
set the TOSH_DATA_LENGTH to, because only sizeof(SurgeMsg) payload
(which I counted as 5) bytes are transmitted.
So I guess what you are doing is run your modified ListenRaw for 20sec,
CTL-C it, and count up the number of 7E's you see?
If all of that is correct then you got 60 messages/sec. If each message
is 15 bytes (my handwaving estimate of msg overhead + payload), then
you got 900 bytes (7200 bits) per second.
My belief from previous testing is that I got about 120 msg/s on micaZ
using my test bed that sends a request and gets a reply from basestation
to re-Mote, and the messages were full TOSH_DATA_LENGTH payloads,
so (I think) 39 bytes each. Which is 4 times what you got, so I don't
know what's going on...
One thing to do is to make a simple TOS program that just sends empty
messages and posts a new send from the sendDone() of the previous.
Skip the ADC and everything else and this is pretty much as fast
as things can go. Then you can vary the number of bytes sent in
the send() call and see if you get different results.
On the Java side I would run the read() loop for a fixed amount of
time using System.currentTimeMillis(), and just keep a count of the
number of bytes you get (don't print them). This will run just about
as fast as it can, in Java anyway...But note that the resolution of
currentTime is usually 10 or 15ms, so take that into account.
MS
Jeong Kwanhee wrote:
Ok!!
I'm using tinyOS 1.1.10. What does means "there is a minimum of 4 (I think)
on the timer rate?"?
In my case I don't use the timer on mote.
I set up to show the time only Java application using the currentTimeMillis
function.
If I should use a read buffer, I don't know how I do.
I set packet size(100bytes).
I think, although the motes generate collision, it can send about 80~100bps
when it sends more than 80~100bps.
When I measure this, I gathered data during 20 second when I tested.
After that, I computed throughput. I can know 1200 packets / 20 second.
-----Original Message-----
From: Michael Schippling [mailto:[EMAIL PROTECTED]
Sent: Friday, April 27, 2007 4:09 AM
To: Jeong Kwanhee; TINYOS HELP
Subject: Re: [Tinyos-help] Data rate performance
Let me cc this back to the help list in case anyone else is interested...
What version of TOS are you using? After 1.1.10 there is a minimum of 4
(I think) on the timer rate. But you say 100 messages/sec so you must
have set the repeat rate at 10, right?
I don't understand "I send the packet about 100 packet size". Did you
try to increase the max payload size? In any case it turns out that
only the significant length of the message payload is transmitted, and
that would be sizeof(SurgeMsg) which looks like 5 bytes, plus the header
and control bytes. So what you have on the air may be less than you think.
Which would make your rate measurement worse, unfortunately...
You don't show the timing part of your Java program or how you count
and end the read() loop. How long do you sample and what are your actual
measurements?
Also having out() and Dump in the read() loop can significantly
slow things down. You could use a read buffer instead of byte
by byte which might eliminate some more Java overhead.
If you are hoping to extrapolate to multi-hop rates you will be
disappointed because they all share part of the bandwidth. Only
one guy can transmit at a time in any neighborhood, and if there are
hidden nodes in between there will be a lot of collisions and dropped
messages.
MS
Jeong Kwanhee wrote:
Hello Michael Schippling!!
I currently used modified surge application by myself.
I send the packet about 100 packet size and more than 100 packet per 1
second.
First of all, I did below:
command result_t StdControl.start() {
//jkh add
//call MacControl.disableAck(); //enableAck, disableAck
//base node not sampling(fixed)
if( TOS_LOCAL_ADDRESS != 0 ){
call Timer.start(TIMER_REPEAT, timer_rate);
}
return SUCCESS;
}
in order to not send from base node.
And I tested only 2 motes, however I'll increase 8 motes.
pc<----0---- 1 --- 2---- 3---- 4 ---- 5---- 6---- 7
0 is destination node, from 1 to 6 only relay node, 7 is source node.
I currently tested only like pc<----0---- 1.
Moreover, I modified UARTM.nc
async command result_t ByteComm.txByte(uint8_t data) {
bool oldState;
dbg(DBG_UART, "UART_write_Byte_inlet %x\n", data);
atomic {
oldState = state;
state = TRUE;
}
if (oldState)
return FAIL;
if(data == 0x7E) {
atomic{
if(++i % 2 != 0){
j++;
call HPLUART.put(j);
}
else{
state = FALSE;
}
}
}
else{
atomic{
state = FALSE;
}
}
if (!state)
return FAIL;
return SUCCESS;
}
I only checked packet count using framing start bit and end bit 0x7E.
After that, I used JAVA application in pc.
This part is ListenRaw.java(I modified this part)
public void read() throws IOException {
int i;
int count = 0;
byte[] packet = new byte[MAX_MSG_SIZE];
while ((i = in.read()) != -1) {
if (i == 0x7e) {
System.out.println();
}
Dump.printByte(System.out, i);
}
}
Output file is attached.
I always thanks for your request.
-----Original Message-----
From: Michael Schippling [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 1:50 PM
To: Jeong Kwanhee
Cc: tinyos
Subject: Re: [Tinyos-help] Data rate performance
I think I have lost the thread of this...
Can you please describe your methods again.
How many re-Motes?
What they transmit and how fast?
How is the code structured...sendDone() posts a new send()?
The UARTM change was in an otherwise vanilla TOSBase?
And it was the 0x7e thing you sent recently?
(This might give you two bytes per message--head and tail sync--
or did you do some other magic?)
What are the message counts you are getting now?
And how do you generate the counts and timings?
etc, etal...
MS
Jeong Kwanhee wrote:
Hello!
For increasing performance(throughput) of received mote, I changed UART
part.
Until now, I believed the reason why throughput is decreasing is serial
speed.
Serial speed is limited.
So, I changed UARTM.nc.
This only transfer specific information(packet count) to pc.
So I made that pc is received 1 byte per 1 packet.
After that, I did see over the ListenRaw. Surely I changed ListenRaw
application.
As a result of seeing, I'm surprised because throughput is not good.
I don't know why is this.
------------------------------------------------------------------------
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
------------------------------------------------------------------------
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
