Good news! Did you try to use serialsender instead? serialsend.c in ../tinyos-2.x/support/sdk/c/sf ? I think that taking SF out of the equation will do only good. Never tried it, but I'm thinking to use.
Arik On Thu, Dec 17, 2009 at 19:15, Giuseppe Cardone < [email protected]> wrote: > Hi, > > you hit perfectly the right spot: adding a small fixed delay of 50ms > solved the issue and now it looks like that my implementation can keep > up with the IPv6 and have slightly better performance (but I still > have to test it extensively). The major clue that this is indeed the > reason for the poor performance of my implementation comes from this > comment and code in the function void send_fragments(...) in > $TOSROOT/support/sdk/c/blip/ driver/serial_tun.c : > > // if this is sent too fast, the base station can't keep up. The > effect of this is > // we send incomplete fragment. 25ms seems to work pretty well. > // 6-9-08 : SDH : this is a bad fix that does not address the > // problem. > // at the very least, the serial ack's seem to be > // working, so we should be retrying if the ack is failing > // because the hardware cannot keep up. > // 9-17-09 : SDH : it seems we've tracked this down to packets > // arriving too fast to enqueue, especially at higher baud rates > // (115200). reenabled to prevent retries, which are very slow. > #ifdef __TARGET_mips__ > usleep(50000); > #else > usleep(25000); > #endif > > So it looks like that the blip developers had the same problem and > resolved it adding a delay of 25ms or 50ms (I hope I am not > misinterpreting the meaning of send_fragments, I didn't read all the > ip_driver code). Maybe I'll patch the SerialForwarder to implement > this "leaky bucket" behaviour. Thank you very much for your help, I > hope that this information will be useful to you too. > > Best regards. > > -- > Giuseppe Cardone > > > > On Thu, Dec 17, 2009 at 2:28 PM, Arik Sapojnik <[email protected]> wrote: > > Even if requests' inter-time interval is exponentially distributed, it > can > > be relatively small. > > I used ~35mSec delay between the packets. Otherwise SF queued all the > > packets and sent them very slow. > > Perhaps you should try to send message once in a second, just to see if > my > > speculation is right. > > > > Arik > > > > > > > > On Thu, Dec 17, 2009 at 14:14, Giuseppe Cardone > > <[email protected]> wrote: > >> > >> Hi, > >> > >> I'm generating random requests whose inter-time interval is randomly > >> generated using a exponential distribution, which typically simulates > >> relatively well real traffic. Anyway I'm generating requests with the > >> same parameter with both implementations, so I don't think that's the > >> issue. I may have hit a performance issue in the Serial Forwarder, but > >> I think it's unlikely. > >> > >> -- > >> Giuseppe Cardone > >> > >> > >> > >> On Thu, Dec 17, 2009 at 12:45 PM, Arik Sapojnik <[email protected]> > >> wrote: > >> > Hi, > >> > > >> > I suppose you are sending your ping requests from client (PC) to > server > >> > (mote). > >> > In this case, are you using an inter-packet-gap? This might be the > >> > issue. > >> > > >> > Arik > >> > > >> > > >> > > >> > On Thu, Dec 17, 2009 at 12:29, Giuseppe Cardone > >> > <[email protected]> wrote: > >> >> > >> >> Hi, > >> >> > >> >> for my benchmarks I'm generating random request of fixed size. The > >> >> time between two requests is exponentially distributed. As long as > The > >> >> rate parameter of the exponential distribution is low enough my > >> >> implementation achieves lower RTTs than blip, but when the rate > >> >> parameter gets higher, blip becomes far better than my > implementation. > >> >> Here's a chunk of results obtained using lambda=1.0 (mean = 1.0). The > >> >> first column is the the request size in bytes (not including the IEEE > >> >> 802.15.4 header and the Active Message field), the second one is the > >> >> RTT in ms of my implementation, the third one is the RTT in ms using > >> >> blip. > >> >> > >> >> 08 68 71 > >> >> 16 57 75 > >> >> 24 81 87 > >> >> 32 110 93 > >> >> 40 147 95 > >> >> 48 175 96 > >> >> 56 296 102 > >> >> 64 305 103 > >> >> 72 375 115 > >> >> 80 405 165 > >> >> 88 494 164 > >> >> 96 565 177 > >> >> > >> >> It's hard to say if my implementation has a linear performance with a > >> >> high slope or if it is quadratic. There are some anomalies (for > >> >> example the sharp rise between RTT for requests of 72 and 80 bytes > >> >> using blip, which seems to be a platform issue), but the trend is > >> >> clear: blip sharply outperforms my implementation as the traffic gets > >> >> heavier. I was able to use blip with high lambdas (=5.0) and still > >> >> having decent RTTs: > >> >> > >> >> 8 105 > >> >> 16 98 > >> >> 24 123 > >> >> 32 144 > >> >> 40 190 > >> >> 48 217 > >> >> 56 184 > >> >> 64 203 > >> >> 72 297 > >> >> 80 498 > >> >> 88 738 > >> >> 96 961 > >> >> > >> >> As I said my echo implementation simply uses a Pool component to > >> >> manage the echo requests (I also tried to use a ring buffer written > by > >> >> me but the results didn't change much), that's why I suppose that > blip > >> >> is particularly clever with buffer management, but still I can't > >> >> understand where the trick is. > >> >> > >> >> -- > >> >> Giuseppe Cardone > >> >> > >> >> > >> >> > >> >> On Thu, Dec 17, 2009 at 7:48 AM, Arik Sapojnik <[email protected]> > >> >> wrote: > >> >> > Hi, > >> >> > > >> >> > I'm currently investigating the same issue - RTT, delay, > >> >> > throughput... > >> >> > Can you please post your results and the results of blip? > >> >> > > >> >> > Thanks, > >> >> > Arik > >> >> > > >> >> > > >> >> > On Wed, Dec 16, 2009 at 22:06, Giuseppe Cardone > >> >> > <[email protected]> wrote: > >> >> >> > >> >> >> Hi all, > >> >> >> > >> >> >> to get acquainted with TinyOS I'm writing a simple echo > application: > >> >> >> it sends back any message it receives. I'm using two TelosB motes > >> >> >> and > >> >> >> Tiny OS 2.1 compiled from CVS. The hardware setup is: > >> >> >> > >> >> >> echo client PC --- Proxy running Serial Forwarer connected to a > >> >> >> BaseStation --- Echo server on TelosB > >> >> >> > >> >> >> I'm using a Pool<message_t> to buffer messages on the echo server. > >> >> >> Everything works and I'm happy with it. As comparison I wrote a > >> >> >> simple > >> >> >> UDP Echo server using blip, and even if blip has to deal with > >> >> >> 6lowpan > >> >> >> it still does a great job and actually under relatively high > traffic > >> >> >> I > >> >> >> have a much better round trip time using blip than using my > >> >> >> application. I compiled my echo server using the switches: > >> >> >> > >> >> >> -DENABLE_SPI0_DMA -DCC2420_HW_ACKNOWLEDGEMENTS > >> >> >> -DTOSH_DATA_LENGTH=102 > >> >> >> > >> >> >> I'm not posting my source code since is pretty trivial: it's just > a > >> >> >> echo server that uses a ring buffer to deal with incoming > messages. > >> >> >> It's the simplest technique I could think of, and I don't know how > >> >> >> blip can have better performance (and I didn't find any obvious > >> >> >> trick > >> >> >> in the source code). How does blip achieve such high performance? > >> >> >> Does > >> >> >> it use any trick with buffers to have a performance boost? > >> >> >> > >> >> >> Any help, tip or hint will be greatly appreciated. Thanks. > >> >> >> > >> >> >> -- > >> >> >> Giuseppe Cardone > >> >> >> _______________________________________________ > >> >> >> Tinyos-help mailing list > >> >> >> [email protected] > >> >> >> > >> >> >> > >> >> >> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > Best Regards, > >> >> > Arik Sapojnik > >> >> > [email protected] > >> >> > > >> > > >> > > >> > > >> > -- > >> > Best Regards, > >> > Arik Sapojnik > >> > [email protected] > >> > > > > > > > > > -- > > Best Regards, > > Arik Sapojnik > > [email protected] > > > -- Best Regards, Arik Sapojnik [email protected]
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
