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]
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
