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
