[Contiki-developers] uIP polling interval

[Randall Nortman]

This is a question about uIP actually, not contiki, but uIP does not
seem to have its own mailing list. I hope this is not considered
off-topic.

In my application, I would like to be able to send data more than once
per second; ideally I would like to be able to send at least 20
packets per second, and more is better (up to a point, that point
being probably around 256 packets/s). So I have two questions: first,
is this even possible given uIP's policy of one packet in flight at a
time? The receiving end will be a "full" TCP/IP stack (Linux 2.6, in
particular), and my understanding is that it will probably delay the
ACK packet for a while. Until uIP receives the ACK, it cannot send
more data. (This application will be on a low-latency Ethernet LAN,
so there's no reason I couldn't get this sort of throughput, in
theory.)

Second, if this is possible, what are the side effects of calling
uip_periodic more often than the recommended once per second? Will
this cause connections to time out more quickly as well? If so, would
it be pretty straightforward to separate application polling from IP
periodic handling? I glanced through the code a bit, and this all
seems to be handled in the rather lengthy uip_process function, so it
might be difficult to tease out. Perhaps split the UIP_TIMER flag
into UIP_TIMER for IP periodic processing and UIP_POLL for application
polling?

Thanks,

Randall

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Contiki-developers mailing list
Contiki-d...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/contiki-developers

[Adam Dunkels]

Hi!

No, it isn't possible to reduce the polling interval to get more packets
sent. Instead, as you've already discovered, it will cause connections
to time out faster (and retransmit packets faster, possibly causing a
lot of unnecessary retransmissions).

Instead, try to collect the data that you wish to send in a buffer, and
send out that buffer when the applications gets called by uIP (either
because of a poll, or because uip_acked() is true).

If you run into problems with the Linux host not acking data quickly
enough, there is a trick that can speed things up: chop outgoing packets
into two before sending them. This is not RFC-compliant behavior,
however. Still, I'm attaching the uip-split.c code from Contiki that
does this. You need to change the #includes and the call to
tcpip_output() to a call to uip_arp_output() and
your_device_drivers_output_function() before using it.

Regards,

/adam

--
Adam Dunkels, Swedish Institute of Computer Science
http://www.sics.se/~adam/

[Randall Nortman]

On Thu, Mar 23, 2006 at 07:59:52PM +0100, Adam Dunkels wrote:
[...]

> If you run into problems with the Linux host not acking data quickly
> enough, there is a trick that can speed things up: chop outgoing packets
> into two before sending them. This is not RFC-compliant behavior,
> however. Still, I'm attaching the uip-split.c code from Contiki that
> does this. You need to change the #includes and the call to
> tcpip_output() to a call to uip_arp_output() and
> your_device_drivers_output_function() before using it.

Thanks, I think that may be helpful. Browsing through the uIP code in
Contiki vs. what's in the uIP 0.9 standalone tarball, I see that the
Contiki version is more advanced, and not only because of this
uip-split code. For example, there seems to be support for UDP
broadcast packets in the Contiki code. (I actually already hacked uIP
0.9 to support broadcast ICMP, because I wanted to respond to
broadcast pings. I can share that code if anybody likes. It's not
pretty.) Is Contiki's uIP version hard to separate from Contiki, or
should I be able to pull it out easily?

Then again, I have been considering switching to full-fledged Contiki
anyway, so maybe this is the time. It has a bit more than I need, in
particular I do not need a program loader/linker or GUI. Program
loading makes no sense in my application -- my only storage device is
some small on-chip Flash, and programs execute directly from Flash for
the most part, except for interrupt handlers and other time-critical
code, which is loaded into RAM by the bootstrap code. Can I just
strip out the program loader and link my code directly with the OS, as
is more typical for embedded environments?

[Adam Dunkels]

Randall Nortman wrote:
> On Thu, Mar 23, 2006 at 07:59:52PM +0100, Adam Dunkels wrote:
> [...]
>> If you run into problems with the Linux host not acking data quickly
>> enough, there is a trick that can speed things up: chop outgoing packets
>> into two before sending them. This is not RFC-compliant behavior,
>> however. Still, I'm attaching the uip-split.c code from Contiki that
>> does this. You need to change the #includes and the call to
>> tcpip_output() to a call to uip_arp_output() and
>> your_device_drivers_output_function() before using it.
>
> Thanks, I think that may be helpful. Browsing through the uIP code in
> Contiki vs. what's in the uIP 0.9 standalone tarball, I see that the
> Contiki version is more advanced, and not only because of this
> uip-split code. For example, there seems to be support for UDP
> broadcast packets in the Contiki code. (I actually already hacked uIP
> 0.9 to support broadcast ICMP, because I wanted to respond to
> broadcast pings. I can share that code if anybody likes. It's not
> pretty.) Is Contiki's uIP version hard to separate from Contiki, or
> should I be able to pull it out easily?

It is intended to be easy to pull out just uIP, so it typically is no
problem. Some #includes may need to be slightly changed, but other than
that it should be no changes to the core uIP code.

> Then again, I have been considering switching to full-fledged Contiki
> anyway, so maybe this is the time. It has a bit more than I need, in
> particular I do not need a program loader/linker or GUI. Program
> loading makes no sense in my application -- my only storage device is
> some small on-chip Flash, and programs execute directly from Flash for
> the most part, except for interrupt handlers and other time-critical
> code, which is loaded into RAM by the bootstrap code. Can I just
> strip out the program loader and link my code directly with the OS, as
> is more typical for embedded environments?

Yes, neither the loader nor the GUI is needed.

/adam

--
Adam Dunkels, Swedish Institute of Computer Science
http://www.sics.se/~adam/