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?
-- 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
It depends on what you want to do with your Ethernet. Are you talking about TCP/IP?
There is a trade of with speed and resource. It is possible to run TCP/IP in very little RAM, but it will be slow(er). Take a look at:
Regards, Richard.
You probably need at least enough for 1 Ethernet frame (1500 bytes).
Above and beyond the 1500 byte requirement, it depends entirely on what sort of protocol you want to impliment.
--
Grant Edwards grante Yow! Two with FLUFFO,
at hold th' BEETS...side of
visi.com SOYETTES!
Unless you plan to support Jumbo frames, 2000 bytes should be more than enough of RAM :-). Of course you may need some extra data space for the application data.
Paul
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. With this type of configuration, throughput would be very low. This might be OK, however, as memory constrained systems are likely to have only small amounts of data to send anyway (even though this may not always be the case). Also, this configuration is not guaranteed to work as it violates the RFCs (too small packet buffer, no IP fragment reassembly).
The minimum size for an RFC compliant TCP/IP application would be 14 (size of Ethernet header) + 576 (minimum RFC compliant packet size) + 576 (buffer for IP fragment reassembly) + 11 (the size of one ARP table entry)
A good estimate for the minimum RAM size for an RFC compliant low-end application with multiple TCP connections would be around 2k. The smallest RAM size for a uIP deployment that I know of was 183 bytes, but that particular application did not use Ethernet.
The simple uIP web server running on
/adam
-- Adam Dunkels, Swedish Institute of Computer Science http://www.sics.se/~adam/,
I think my approach is even better. :-) "~adam" (Dunkels) is visiting me Thursday! I talked to someone else using "lwIP", and he was using 100 kB.
-- 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
Your thinking is basically correct. Two comments however: first, if you wish to maximize throughput, you will probably need a lot of memory in order to buffer data for retransmissions. Second, if you are sending static web pages, there is no need to buffer those in RAM.
If the application does not require maximum throughput, you can get away with much less RAM. (Again, that size/throughput trade-off.)
Regards,
/adam
-- Adam Dunkels, Swedish Institute of Computer Science http://www.sics.se/~adam/,
2000 bytes fit one frame of TCP/IP , and not more.
I am thinking along the line: Small http server but decent performance over a wide area network with some delay when you download a web page.
In TCP/IP there is a window. I.E: you can send several packets before you get an acknowledge. You cannot discard a sent packet until you get an acknowledge. If you can only store one packet, then you need to wait for that acknowledge before you send the next. If the ping delay is 200 ms (just tried), then you can send 5 packets per second. At 1000 bytes per packet, this is 40 kbps. - Not a lot...
200 ms is quite good for pinging US from Sweden. Frequently see > 1 second. giving me 8 kbps.If the connection ends up over GSM, then you are limited to low speed transmission and I think you want to utilize the bandwidth as much as possible, which means transmitting all the time
Maybe the question should be more like:
Assuming you want to have maximum throughput with TCP/IP + PPP over a 56 kbps (7 kB/s) line and a ping delay of 100, 200 or 500 ms, sending web pages of x kB. Don't you really have to have enough RAM to store everything until you get the acknowledge. So if you have a ping delay of 500 ms, you have to store
7 kB * 0,5 = 3,5 kB.If you have a 500 kbps ADSL connection and 500 ms ping, then you need to store 500 kbit * 0,5 = 250 kbit = roughly 30 kByte.
If you sénd data in both directions, then you need 2 x memory and you are quickly close to 100 kB.
Did I misunderstand this?
-- 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
lwIP typically requires more RAM than uIP. The reasons for this are that it buffers data for retransmissions in RAM and that it is designed to be able to achieve much higher throughput. With lwIP, it should be possible to maximize throughput given your delay*bandwidth example.
We can discuss this in detail on Thursday :-)
Regards,
/adam
-- Adam Dunkels, Swedish Institute of Computer Science http://www.sics.se/~adam/,
Even though you have not spcified close enough what kind of "Ethernet applications" you have in mind, I asume this is going to be some application that needs TCP connectivity.
Basically it boils down to how many buffers you want/need to have. On the lower end there are those implementations which mostly exclusively use the NIC's io buffer space which are usually limitted to one single TCP session (if at all) or UDP based comunication only. In case of TCP such implementations also do not have a flight size > 1. That said only one segment is sent out and processing waits up until this segment gets ack'ed from the other end. Such implementations are fine if you want a little simply webpage showing some data you may collect with the device or where such a page is used to configure the device etc.
On the other end of the rope are those implementations where you need to process multiple TCP sessions in paralell and where you want a reasonable througput. If you want a reasonable speed, you need to have a minimum of two buffers per connection so as you can send out two segments which are not yet ack'ed by the other end (in other words a "flight size" of two buffers) and where it's likely that buffers are available for the reciver too.
So, as a rough estimate, I sugest to calculate 1500 bytes per buffer times number of buffers per connection times TCP sessions in paralell. Add probably 20% to this to have something left to maintain task/socket state and there you go. Of course this asumes that the buffers are held in a pool and are not strictly assigned to a given connection.
HTH
Markus
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, 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
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
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 @monlynx.de instead !
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:
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.
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/,
One can actually get quite far with a single packet buffer. The uIP web server at
Regards,
/adam
-- Adam Dunkels, Swedish Institute of Computer Science http://www.sics.se/~adam/,
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.
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. 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
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.
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.
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
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).
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, 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.
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/,
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.