How much RAM needed for low end Ethernet application?

Grant Edwards <grante@visi.com> writes:

> Above and beyond the 1500 byte requirement, it depends entirely
> on what sort of protocol you want to impliment.

And buffering requirements.  If there's only room for one frame
then it's very easy to miss incoming frames.

-- 
Darin Johnson
    Caution! Under no circumstances confuse the mesh with the
    interleave operator, except under confusing circumstances!

Adam Dunkels wrote:
> As Richard says in another reply, there is a size/throughput trade-off
> involved. If you intend to run TCP/IP on top of the Ethernet, the
> lower bound on RAM is 14 (size of Ethernet header) + 40 (size of TCP/IP
> headers) + 20 (estimated size of TCP options in TCP SYN segment) + 11 (the
> size of one ARP table entry) + the RAM requirements for one TCP
> connection. For uIP, this would be around 120 bytes.

Adam,
Why buffer the full header in RAM (or further, in each TCB entry) when 
you can build it on-the-fly as you write it to the NIC, then go back and 
re-write the checksum?  Ditto on incoming - if you handle the options 
are they're being read, why buffer them first?

It seems that use of the 16K buffer RAM on an NE2000 Ethernet controller 
would significantly reduce the SRAM requirements, reducing it to just 
storing the key session variables, no?

Clearly you're deeper into this area than most folks, so likely you've 
considered this... why not store only the essential fields in SRAM and 
handle the rest on-the-fly?  Especially with static data (no re-TX 
buffers), it'd seem like an awful lot of stateful session entries could 
be squeezed into SRAM. (About 17-20 bytes per session, it'd seem.)

There's got to be a practical / performance catch here - what am I missing?

Assuming easily recreated data (e.g., static), it'd seem that even a 
barebones approach should be able to send large windows and perform 
well.  Clearly though, if the TX content needs to be buffered then a lot 
more RAM / lower performance kicks in.

Your thoughts?

Regards,
Richard

Richard H. wrote:
> Adam Dunkels wrote:
>> As Richard says in another reply, there is a size/throughput
>> trade-off involved. If you intend to run TCP/IP on top of the
>> Ethernet, the
>> lower bound on RAM is 14 (size of Ethernet header) + 40 (size of
>> TCP/IP headers) + 20 (estimated size of TCP options in TCP SYN
>> segment) + 11 (the size of one ARP table entry) + the RAM
>> requirements for one TCP connection. For uIP, this would be around
>> 120 bytes.
>
> Adam,
> Why buffer the full header in RAM (or further, in each TCB entry) when
> you can build it on-the-fly as you write it to the NIC, then go back
> and re-write the checksum?  Ditto on incoming - if you handle the
> options
> are they're being read, why buffer them first?
>
> It seems that use of the 16K buffer RAM on an NE2000 Ethernet
> controller would significantly reduce the SRAM requirements, reducing
> it to just storing the key session variables, no?

Doesnt help you in a single chip micro.
Then you have x amount of SRAM regardless
of where it is.

> Clearly you're deeper into this area than most folks, so likely you've
> considered this... why not store only the essential fields in SRAM and
> handle the rest on-the-fly?  Especially with static data (no re-TX
> buffers), it'd seem like an awful lot of stateful session entries
> could
> be squeezed into SRAM. (About 17-20 bytes per session, it'd seem.)
>
> There's got to be a practical / performance catch here - what am I
> missing?

If you have to do a resend, then you have to assemble the packet again
(on the single chip micro)
This is very likely a performance bottle neck as well.

The applications I am thinking of is mostly remote supervision/control
so pages would not be static.

>
> Assuming easily recreated data (e.g., static), it'd seem that even a
> barebones approach should be able to send large windows and perform
> well.  Clearly though, if the TX content needs to be buffered then a
> lot more RAM / lower performance kicks in.
>
> Your thoughts?
>
> Regards,
> Richard

-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

On Wed, 02 Mar 2005 00:57:49 GMT, Darin Johnson <darin_@_usa_._net>
wrote:

>Grant Edwards <grante@visi.com> writes:
>
>> Above and beyond the 1500 byte requirement, it depends entirely
>> on what sort of protocol you want to impliment.
>
>And buffering requirements.  If there's only room for one frame
>then it's very easy to miss incoming frames.

This is only a problem if the ethernet controller is in the
promiscuous mode or there are a lot of ethernet broadcasts or you are
running some unappropriate protocol for such small environments.

With simple master-slave protocols and with some kind of ethernet
controller filtering, a single frame buffer should be enough. 

Of course, this does not support a full TCP/IP implementation with a
http server with many concurrent clients :-), but was this a
requirement in the first place ?

Paul
 

On 01 Mar 2005 21:18:31 GMT, Grant Edwards <grante@visi.com> wrote:

>On 2005-03-01, Ulf Samuelsson <ulf@a-t-m-e-l.com> wrote:
>
>> I would be interested to understand the RAM needs when
>> you have simple Ethernet applications.
>
>You probably need at least enough for 1 Ethernet frame (1500
>bytes).

You can do with smaller frames, esp. if you use TCP (you can set the
segmnet size in the options).

On a 9S12NE64 with 8K RAM you can have a TCP/IP application with
buffering (framesize 512 bytes).

-- 
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !

On Tue, 01 Mar 2005 22:20:05 -0700, Richard H. wrote:

> Why buffer the full header in RAM (or further, in each TCB entry) when you
> can build it on-the-fly as you write it to the NIC, then go back and
> re-write the checksum?  Ditto on incoming - if you handle the options are
> they're being read, why buffer them first?

You are right - my bad. I was thinking a little too general and didn't
consider the fact that the Ethernet controller had buffer memory. Yes,
both reading and writing header directly from and to the Ethernet
controller is possible and doable without too much hackery. (I once did a
proof-of-concept hack that does something like this:
http://www.sics.se/~adam/miniweb/ )
 
> It seems that use of the 16K buffer RAM on an NE2000 Ethernet controller
> would significantly reduce the SRAM requirements, reducing it to just
> storing the key session variables, no?
> 
> Clearly you're deeper into this area than most folks, so likely you've
> considered this... why not store only the essential fields in SRAM and
> handle the rest on-the-fly?  Especially with static data (no re-TX
> buffers), it'd seem like an awful lot of stateful session entries could
> be squeezed into SRAM. (About 17-20 bytes per session, it'd seem.)

Do you mean storing connection state inside the Ethernet controller's
memory? I guess it would be quite possible to do so, although there would
be a performance hit with every incoming packet since the list of
connections would have to be scanned to check which connection that should
receive the packet.

> Assuming easily recreated data (e.g., static), it'd seem that even a
> barebones approach should be able to send large windows and perform
> well. Clearly though, if the TX content needs to be buffered then a lot
> more RAM / lower performance kicks in.

Yes, definitely. Adding the ability to have multiple outstanding TCP
segments does however complicate both the sending code and the ACK
processing code, and would lead to both increased code size and slightly
increased RAM requirements (since more state needs to be kept).

Regards,

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

On Wed, 02 Mar 2005 10:02:23 +0200, Paul Keinanen wrote:

> On Wed, 02 Mar 2005 00:57:49 GMT, Darin Johnson <darin_@_usa_._net> wrote:
> 
>>Grant Edwards <grante@visi.com> writes:
>>
>>> Above and beyond the 1500 byte requirement, it depends entirely on what
>>> sort of protocol you want to impliment.
>>
>>And buffering requirements.  If there's only room for one frame then it's
>>very easy to miss incoming frames.
> 
> This is only a problem if the ethernet controller is in the promiscuous
> mode or there are a lot of ethernet broadcasts or you are running some
> unappropriate protocol for such small environments.
> 
> With simple master-slave protocols and with some kind of ethernet
> controller filtering, a single frame buffer should be enough.
> 
> Of course, this does not support a full TCP/IP implementation with a http
> server with many concurrent clients :-), but was this a requirement in the
> first place ?

One can actually get quite far with a single packet buffer. The uIP web
server at http://uip-demo.sics.se/ has only one single buffer that holds
both incoming and outgoing packets, and the web server is able to serve up
pages even when I bombard it with packets from an nmap scan. It even is
able to serve pages while I ping flood it from a PC connected to the same
switch. (Feel free to try the nmap scan yourself, but please don't do the
ping flooding :-)

Regards,

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

On Tue, 1 Mar 2005 20:47:22 +0100, "Ulf Samuelsson"
<ulf@a-t-m-e-l.com> wrote:

>I would be interested to understand the RAM needs when
>you have simple Ethernet applications.
>
>Is 32kB/64 kB SRAM enough for a decent application or do you need more?
>I think there are simple applications where you dont need too much info
>but will they fit?

We have (finally) got round to testing our PowerNet TCP/IP
stack on an ARM with 120k Flash and 64k RAM. With Telnet,
multi-threaded HTTP server with CGI and ASP, it all fits
and runs. Connection is over Ethernet (port-mapped RTL8019AS).
The limitation is in the number of free buffers and number
of simultaneous open connections.

We'll know in a day or two what we can fit into 32k of RAM.

Note that PowerNet is a general purpose stack for embedded
systems, not a stripped-down application-specific stack. It
does make some compromises in areas such as option handling.

Stephen

--
Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

On Wed, 02 Mar 2005 08:56:04 +0000, Adam Dunkels <adam@sics.nospam.se>
wrote:

>Adding the ability to have multiple outstanding TCP
>segments does however complicate both the sending code and the ACK
>processing code, and would lead to both increased code size and slightly
>increased RAM requirements (since more state needs to be kept).

As we recently found, there are embedded stacks out in the
wild that *require* this. As more and more embedded systems
communicate, the different compromises in constrained-resource
stacks will conflict.

Unless it is clearly stated as a requirement, testing
with desktop machines is no longer enough.

Stephen

--
Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

Adam Dunkels wrote:
> the fact that the Ethernet controller had buffer memory.

Yes, often more than the MCU.  While I wouldn't leap to use it as 
general-purpose storage, it seems a convenient resource for packet 
construction, and avoids the need to transfer it in a subsequent step.


> Do you mean storing connection state inside the Ethernet controller's
> memory? I guess it would be quite possible to do so, although there would
> be a performance hit with every incoming packet since the list of
> connections would have to be scanned to check which connection that should
> receive the packet.

Ick.  That's a bit more aggressive than I was thinking, but it's an 
interesting thought for extremely limited systems.

No, I'm actually thinking along the lines of keeping only the essential 
variables in SRAM per-session and building the rest on-the-fly as the 
header is being written to the NIC.  Off-the-cuff... remote IP & port, 
session sequence & ack numbers, header flags, session MSS & window size, 
add up to ~17 bytes per TCP session. (And of course, the ARP table, 
which ideally has just the default gateway instead of many same-subnet 
peers.)

This scheme is more aggressive than a simple SRAM buffer for the whole 
packet, but on paper it doesn't seem to impose much internal processing 
overhead to write these variables & fill in other global content 
on-the-fly as data is written to the NIC, vs. crafting it in a buffer 
and then copying the buffer to NIC when transmitting.


> Yes, definitely. Adding the ability to have multiple outstanding TCP
> segments does however complicate both the sending code and the ACK
> processing code, and would lead to both increased code size and slightly
> increased RAM requirements (since more state needs to be kept).

Yes. ISTR that Bentham had an interesting approach for handling static 
data in TCP/IP Lean, where certain info was either stored in the session 
table or through trickery in the Sequence numbering that pointed to the 
"file" object and offset, allowing retransmissions to be re-built 
as-needed from the static source data instead of buffering.  (Workable 
only where data can be trivially reconstructed from the source.)

This would seem to support large windowing with no re-TX buffering 
(i.e., max throughput on high-latency links with little resource 
overhead on the device)

Thanks for the comments.

Regards,
Richard