>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?This is a very hard question, I will try to illistrate why... In general you can hand build a TCP/IP system with very little RAM. (10K or less) But if you want to send lots of data or want to use a traditional socket programming interface you will need a lot more. I would put the minimum at around 64K. As a guess aproximatly 2 to 3 times the bytes/per second you want to transfer over the network for buffering and an additional 512 bytes per connection, and 1K for miusc system state. You need to explicitly answer 2 Questions to estimate the RAM size. 1)What type and number of connections? Raw frames? ICMP,ARP,UDP? DHCP? TCP Web? TCP Telnet? TCP Ftp? TCP E-Mail? DNS? SNMP? 2)Do you want a traditional socket like programming interface or can you deal with a special minimal ram interface? This is mosst true for TCP. I'll use the examples of a single threaded webserver.... Step 1 Negotiate a connection... Client sends SYN packet Sever sends a SYN ACK Client Sends an ACK. This step will be the same reguardless of the interface. All packets are small, does not take much memory. Step 2 Client makes a request... The Client asks for a web page if there is no complicated post this likely a single packet. Request packet comes in..... Traditional: Using the traditional "socket read interface" the TCP stack has to take the incomming packet and store it in a received buffer, the transfer it to another buffer on the read request, so ram used is 2 to 3 times the size of the received packet. LowRam interface: The TCP stack takes the incomming packet and then gives to the user as a pointer, no copy takes place, but the interface is not a traditional "read." Memory usage is 1.5 times the payload size. Step 3 The Server responds... The Server genrates the response to the web request, no matter what the interface I will assume that the wholw thing is builtup in a ram buffer, it may be built in peices, or all at once, this is just a speed tradeoff.... Traditional: Using the traditional write interface the programmer assembles his respons(es) and calls write for the socket. The TCP stack then copies this data into an outgoing packet and holds on to a copy of the data until the othet side acknowledges it. The TCP system can use a lot of ram here, LowRam Interface: The user asks the TCP system to give him a place to put the outgoing data, Then the programmer puts some limited amount of data into this outgoing packet. The packet is submitted to the TCP system that then goes to sleep waiting for the other side to acknowledge the packet, or until it is time to try and retransmit the packet. This methodology will be slow as it reduces the tCP flow control system to a stop and go protocol 2 to 10 times slower than a traditional TCP implemtation. Repeate step 3 until the whole thing is transfered. Step 4 Close the connection... Server sneds FIN Client send FIN ACK Server sends FIN. All small packets using very little memory. When you've explictly answered the first question what connections and how many simultanious connections of each type you c When you say Ethernet I will assume you mean TCP/IP Some background.... Full size ethernet rames are around 1500 bytes, + a few bytes dependign on weither your ethernet controller puts addistional information in the frame or as seperate registers. If you are sending receivng UDP,ICMP,ARP etc... then you probably need to buffer a couple incomming frames and one or two outgoing frames. At this level the buffering can all be in the ethernet chip/controller.
How much RAM needed for low end Ethernet application?
Started by ●March 1, 2005
Reply by ●March 2, 20052005-03-02
Reply by ●March 2, 20052005-03-02
Stephen Pelc wrote:> 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. > > StephenThe question is really related to the specification of the AT91SAM7X processor which has integrated Ethernet. There is no SRAM in the "Ethernet controller". The Ethernet MAC is integrated and shares the memory with the CPU, so there is no extra memory available. Also there is no external bus, so it is really important that enough SRAM memory is in the chip to start with, because this is all that is available. Thanks for comments! -- 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
Reply by ●March 2, 20052005-03-02
On Wed, 02 Mar 2005 09:53:24 -0700, Richard H. wrote:> 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.How many Ethernet controllers are able to address this memory directly? I wrote a device driver for the CS8900a and I seem to remember that it only provided a sequential interface to its packet buffer (i.e., read and write bytes from the start of the packet to the end, no "random" access).>> 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.)Hmmm, maybe I don't get it, but aren't you placing the entire TCP connection state in the Ethernet controller's SRAM then?>> 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.)Yes, that is a nice trick and saves four bytes of per-connection state. However, if I remember correctly, his stack did not do retransmissions but relied on the remote host to do retransmissions. This actually works in some situations, where both hosts are sending data simultaneously (like an HTTP GET / response situation) but does not work for unidirectional transfers.> 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)Hmmm, I don't think it can be extended *that* easily. One problem arises when doing retransmissions: there is no way of knowing what sequence number to retransmit. Unless you store it in RAM, but that sort of defeats the purpose of the trick :-) Regards, /adam -- Adam Dunkels, Swedish Institute of Computer Science http://www.sics.se/~adam/, <adam@sics.nospam.se>
Reply by ●March 2, 20052005-03-02
On Wed, 02 Mar 2005 15:45:35 +0000, Stephen Pelc wrote:> 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.I'm not sure I fully understand: are you saying that you have found embedded stacks that require that the TCP sender sends multiple segments? That do not work when the sender sends only one TCP segment? I guess we are talking about different things.> Unless it is clearly stated as a requirement, testing with desktop > machines is no longer enough.Agreed. Regards, /adam -- Adam Dunkels, Swedish Institute of Computer Science http://www.sics.se/~adam/, <adam@sics.nospam.se>
Reply by ●March 2, 20052005-03-02
On Wed, 02 Mar 2005 08:15:45 +0100, Ulf Samuelsson wrote:> 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.If assembling the packet in the first place is requires a lengthy computation (say a 10 seconds encryption), then reproducing the packet in order to do a retransmission might become a performance bottleneck. In such an application it would be better to buffer the data. For a set of simple sprintf()s or a computation that takes less than a second, it probably is not a bottleneck to recompute the data for a retransmission. In many applications, retransmissions are not that frequent. (But this of course depends on the network conditions.) Regards, /adam -- Adam Dunkels, Swedish Institute of Computer Science http://www.sics.se/~adam/, <adam@sics.nospam.se>
Reply by ●March 2, 20052005-03-02
On Wed, 02 Mar 2005 15:39:34 +0000, Stephen Pelc wrote:> 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.I have been running uIP together with the Contiki OS, a web server (with support for dynamic pages), a VNC server (remote networked display), and a small GUI with a 120x56 pixels virtual desktop on an MSP430 with 60k ROM and 2k RAM. The device was connected using RS232 and SLIP. If I remember correctly the entire system used around 40k ROM, of which some 20k constituted the Java VNC client and the web pages. uIP also is a general purpose stack and not a stripped-down application specific stack. I would suspect that part of the explanation for the differing resource requirements between uIP and PowerNet are that throughput is likely to be much higher with PowerNet, and that PowerNet has a full socket API that is easier to program than the uIP API and that makes porting Unix applications straightforward. Also, the PowerNet web server is much more advanced than the uIP web server. Regards, /adam -- Adam Dunkels, Swedish Institute of Computer Science http://www.sics.se/~adam/, <adam@sics.nospam.se>
Reply by ●March 2, 20052005-03-02
"Ulf Samuelsson" <ulf@a-t-m-e-l.com> writes:> The question is really related to the specification of the AT91SAM7X > processor which has integrated Ethernet.Which part is that? I don't see it on the web site, but maybe I'm not looking in the right place. Thanks, Eric
Reply by ●March 2, 20052005-03-02
Eric Smith wrote:> "Ulf Samuelsson" <ulf@a-t-m-e-l.com> writes: >> The question is really related to the specification of the AT91SAM7X >> processor which has integrated Ethernet. > > Which part is that? I don't see it on the web site, but maybe I'm > not looking in the right place. > > Thanks, > EricIt is not available yet. -- 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
Reply by ●March 2, 20052005-03-02
On Wed, 2 Mar 2005 19:55:22 +0100, "Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote:>The question is really related to the specification of the AT91SAM7X >processor which has integrated Ethernet. > >There is no SRAM in the "Ethernet controller". >The Ethernet MAC is integrated and shares the memory with >the CPU, so there is no extra memory available. >Also there is no external bus, so it is really important >that enough SRAM memory is in the chip to start with, >because this is all that is available.I see no reason apart from performance why PowerNet should not fit. Is an EVB available yet? I could be tempted. 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
Reply by ●March 2, 20052005-03-02
Ulf Samuelsson wrote:> The question is really related to the specification of the AT91SAM7X > processor which has integrated Ethernet.I wrote:> Which part is that? I don't see it on the web site, but maybe I'm > not looking in the right place.Ulf wrote:> It is not available yet.OK, but is it announced yet? Will it have an onboard PHY? I'd love to see an alternative to the Freescale MC9S12NE64 with a more powerful CPU and somewhat more RAM (32KB would be great). Eric
