newstack branch

[Martin Guy]

Hi Bogdan
  Can you describe briefly what the changes are in the newstack branch
at the TCP/IP level?
  I see some changes deep in the uip code, others in the rfs layer.
  I'm interested because we have an issue in extreme slowness of uip:
when I try to hammer it, it slows down to one byte per second. A bit
like some people and deadlines: the more you push them the slower they
go :) so I'm wondering whether that is likely to improve this
behaviour or not.
  At that level, are you implementing a new TCP/IP stack,
extending/fixing/extending the use of uip, importing the changes
between uip and lwip or something else?

Thanks

   M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

Hi Martin,

On Sat, Mar 31, 2012 at 12:13 PM, Martin Guy <[hidden email]> wrote:
> Hi Bogdan
>  Can you describe briefly what the changes are in the newstack branch
> at the TCP/IP level?

1. Many patches in the uIP to eLua adaption layer which fix some
serious data RX/TX issues
2. UDP support
3. Per-socket buffers and callbacks
4. Physical Ethernet connection handling (inserting/removing the cable
with the board running works properly now)
5. Better (I hope) and richer API

>  I see some changes deep in the uip code, others in the rfs layer.
>  I'm interested because we have an issue in extreme slowness of uip:
> when I try to hammer it, it slows down to one byte per second. A bit
> like some people and deadlines: the more you push them the slower they
> go :) so I'm wondering whether that is likely to improve this
> behaviour or not.

I think it's quite likely to see an improvement in this behaviour.

>  At that level, are you implementing a new TCP/IP stack,
> extending/fixing/extending the use of uip, importing the changes
> between uip and lwip or something else?

Extending/fixing the use of uIP mostly, I haven't touched lwIP yet.
Item 5 above (better/richer API) is the main thing that made me stop
development on that branch for now. I'm sure you remember the talks we
had about the timer module API and the way it changed only to have it
reverted back. I'm not going to do the same mistake again. More
precisely, I'm not going to touch any API again until I'm able to
figure out a proper (and generic) API deprecation mechanism. I'm
working on that and I think I have something that is simple enough to
work and implement. Only after I have this in place I'll resume
working on the newstack branch.

Best,
Bogdan

>
> Thanks
>
>   M
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

On Mon, Apr 2, 2012 at 2:30 AM, Bogdan Marinescu
<[hidden email]> wrote:

> Hi Martin,
>
> On Sat, Mar 31, 2012 at 12:13 PM, Martin Guy <[hidden email]> wrote:
>> Hi Bogdan
>>  Can you describe briefly what the changes are in the newstack branch
>> at the TCP/IP level?
>
> 1. Many patches in the uIP to eLua adaption layer which fix some
> serious data RX/TX issues
> 2. UDP support
> 3. Per-socket buffers and callbacks

One comment here:  One thing that is entirely acceptable, and probably
helpful in keeping buffers down is not acking packets unless something
is done with them.  Certainly there are performance issues with this
sort of thing, but I think one thing that would have worked to make
the old setup more reliable was delaying acks until the single-packet
buffer had been consumed.  Either that or, not buffering & acking new
packets until the old one has been used.

I'm not sure what the state is currently in the newer implementation,
but TCP is designed to basically blast everything as fast as possible
until something starts dropping packets.  Its just as valid to drop
packets because the end device has no buffer space as it is for some
bottleneck in the intervening link to do so, and it helps the sender
to understand how quickly to send packets.

The "must not drop packets" mantra is actually one of the things that
leads to horrible upstream latency on home connections when one is
using TCP to upload large files:
http://en.wikipedia.org/wiki/Bufferbloat

I'm not mentioning this to suggest that anything should be ripped out
or redone, just that it's part of the design of the protocol, and
if/when we run into related issues we should drop packets when we
can't handle them.

> 4. Physical Ethernet connection handling (inserting/removing the cable
> with the board running works properly now)
> 5. Better (I hope) and richer API
>
>>  I see some changes deep in the uip code, others in the rfs layer.
>>  I'm interested because we have an issue in extreme slowness of uip:
>> when I try to hammer it, it slows down to one byte per second. A bit
>> like some people and deadlines: the more you push them the slower they
>> go :) so I'm wondering whether that is likely to improve this
>> behaviour or not.
>
> I think it's quite likely to see an improvement in this behaviour.
>
>>  At that level, are you implementing a new TCP/IP stack,
>> extending/fixing/extending the use of uip, importing the changes
>> between uip and lwip or something else?
>
> Extending/fixing the use of uIP mostly, I haven't touched lwIP yet.
> Item 5 above (better/richer API) is the main thing that made me stop
> development on that branch for now. I'm sure you remember the talks we
> had about the timer module API and the way it changed only to have it
> reverted back. I'm not going to do the same mistake again. More
> precisely, I'm not going to touch any API again until I'm able to
> figure out a proper (and generic) API deprecation mechanism. I'm
> working on that and I think I have something that is simple enough to
> work and implement. Only after I have this in place I'll resume
> working on the newstack branch.
>
> Best,
> Bogdan
>
>>
>> Thanks
>>
>>   M
>> _______________________________________________
>> eLua-dev mailing list
>> [hidden email]
>> https://lists.berlios.de/mailman/listinfo/elua-dev
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev

--
James Snyder
Biomedical Engineering
Northwestern University
http://fanplastic.org/key.txt
ph: [phone]
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev