How much RAM needed for low end Ethernet application?

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/,

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/,

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

It 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

I see no reason apart from performance why PowerNet should not fit. Is an EVB available yet? I could be tempted.

Stephen

-- Stephen Pelc, snipped-for-privacy@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: - free VFX Forth downloads

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

Nice.

PowerNet was designed from the outset for 32 bit CPUs and plenty of RAM. Yes, it has a BSD style API. All servers, e.g. Telnet and HTTP share a common architecture based on one thread per connection. This makes it rather RAM hungry but it is extremely easy to program. Now that single-chip micros have 64k RAM, the RAM hunger is much less of an issue, but a RAM reduction exercise is under way.

Stephen

-- Stephen Pelc, snipped-for-privacy@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: - free VFX Forth downloads

Good question. I've been focused on an NE2000/Asix driver. While those chips use DMA for block writes, it does seem possible to go back and re-write a single byte. A lot of setup for a single I/O, so inefficient for truely random accesses, but seems viable to go back and re-write a checksum after the packet is buffered.

Interesting. I'll watch for this. The NE2000 works similarly, but you can specify the start address during setup.

Sorry... by 'SRAM' I'm referring to the MCU's SRAM (say, 200 bytes for

10 sessions). Keep the stateful variables in MCU SRAM for performance, and construct the packets directly in the Ethernet controller's TX buffer to avoid double-buffering and MCU RAM overhead.

Hmmm... I'm not sure how that could be viable - the sending host would need to have an ACK timeout facility. ISTR from the sequence number of the lowest ACK his scheme could identify the file and offset to re-fetch for re-TX. I'll have to put that one back on the reading pile for a refresher. :-)

Well, I'm questioning my memory now, but I thought the general scheme was something like the high-order bits of the sequence # identified the file number, and the low-order bits mapped to the file offset. Clearly in violation of rules about ISN randomization, but if a packet goes missing, take the Seq# in highest ACK received, go back to that file and start at that offset to re-TX.

It'd seem you could dump an entire window's worth of packets on the wire, and TX the next packet based on the highest ACK received - either the next in sequence, or the "missing" packet. (A little more complexity required, but not much for static content, I think.) Clearly, a very specialized scheme, but MCUs tend toward that kind of optimization, and it might let you keep a lot of packet outstanding with very few resources.

You're right. I'm used to systems that need promiscuous mode or multicast addresses.

--
Darin Johnson
    Laziness is the father of invention

Does it have an External Bus Interface?

How much RAM on board?

regards, Johnny.

I would be carefull when it comes to the tricks mentioned by some posters here. Don't forget that there are SYN flood attacks, tear drop attacks and other malicious activity out there in the internet waiting to hit your implementation. You must handle these kind of things reasonably well in a comercial product or otherwise you will have lot's of problems.

Another issue is how many systems out there simply do not play by the standards. We see systems anouncing MSS but then do not accept segments of this size etc. etc. So again, if this is for a heavily comercial kind of application you must consider these things too. Especially the SYN flood thing requieres implementing SYN cookies or other kind of counter measures or else the limitted resources of an embedded system are eaten up instantly. The customer surely will blame you if this happens - and not the attacker.

In the TCP stack I implemented, I'm using 50 buffers of 1500 bytes in size in a pool. There is a low water mark which if reached means that new connection requests are no longer granted up until enough buffers become available. In other words there is no fixed relation between connection and buffers but instead they are dynamically assigned whre needed. This allows to handle ~20 connections very efficiently, but also means at the same time that peaks of 70 or more paralell connections still work reasonably well. The per connection state overhead is about 50 bytes more per connection. You could easily tailor the RAM useage by defining a different buffer pool size.

The code size used to implement this is 34 KB.

The stack supports the following features / protocols:

- ARP

- ICMP

- IP (fragment reasembly supported)

- DHCP client

- UDP

- DNS resolver

- TCP/IP

- SYN cookies

- configurable window size

I hope above information gives you an idea of what's needed RAM/Flash size wise.

HTH

Markus

Markus,

What approach did you implement for SYN cookies?

I've seen a couple schemes - one crypto-based, the other a scheme for encoding the setup vars in the ISN. Both seem to have challenges, not the least of which is the limited field size of the Seq# to work with (never mind that it violates the requirement for ISN randomization).

For example, did you sacrifice the options header / certain MSS increments in the process? IIRC, this is the one big point of compromise to fit in the available field space, with the being 0 RAM used until the reply SYN-ACK arrives (i.e., fairly impervious to SYN flooding).

Richard

I'm not sure what you mean with "the tricks mentioned by some posters" (perhaps you could be a little more specific?) but I would also like to stress the importance of doing heavy testing of a TCP/IP stack. Send as much "bad" packets to your stack as possible - others surely will.

Failure to adhere to the size of the MSS seems to be the most common way to diverge from the RFC standards. This may work fine when talking to a PC, but may result in communication failure when trying to talk to a small embedded device. Lacking support for IP fragment reassembly also seems quite common. Some stacks also leave out TCP's congestion control, which may even lead to network overload. I fully agree with you: compliance with RFCs is important.

For a more thorough discussion of RFC compliance of small TCP/IP implementations, please refer to my MOBISYS'2003 paper "Full TCP/IP for

8-bit architectures", available at

Regards,

/adam

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

Ulf Samuelsson wrote about an unannounced AT91SAM7x part with ethernet:

Of RAM? Yes, that's plenty for small-to-medium size applications. I'd be pretty happy with 32KB. If you want to support largish applications, you should either include 128KB of RAM, or allow external RAM to be added.

If you're talking Flash, I'd recommend at least 128KB, though 64KB is enough for small systems, and 32KB is enough for tiny systems.

If you haven't yet decided the memory sizes, it's obviously quite a way out yet.

Or if you have already taped out a part with 64KB and are trying to decide whether to introduce it as a product, the answer is yes. :-)

Eric

I dont make decisions like this in Atmel, but sometimes I can make people reverse decisions by good arguments. If anyone has anything to complain about the Watchdog in the SAM7S series then I am the guy to talk to.

Just wanted to know if the SRAM size was worthy of another crusade. It looks like we can live with 64KB of SRAM for a substantial part of the market.

--
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

I started my implementation about two years ago and back then all small TCP stack's I looked at could not resist SYN flood attacks not to mention more complicated attacks that are reality also. I do not say that they necesairly crash the device, but there are no counter measures at all in place. SYN flood attacks are nasty in that the attacker can easily hide origin by randomly varying the sender IP address. In normal day to day's live it's not feasable to track the source of an attack since it would requiere cooperation of sysadmins all across the way back to the attacker. In other words, such attacks can go on for hours thereby rendering an embedded device using this kind of unsecure TCP implementation useless. This CAN be a very important issue if the device is used in a productive envireonement.

With "tricks" I mostly refered those implementations which try to keep state in the NIC's buffer, useing specially crafted sequence numbers et all. The randomness of initial sequence numbers is extremly important to avoid other kind of attacks (i.e. man in the middle) . If however bit's from the sequence number are used for other purposes as sugested, the randomness of the numbers can't be guaranteed to a high degree enough. I do see the obvious advantages that such tricks might have to save RAM et all, but not also considering security issues in todays times is probably only ok for hobby projects..

I actually was refering to some Linux TCP versions which in fact anounce an MSS of say 1460 byte, but silently drop every segment bigger than 1420 bytes. So, the embedded TCP stack must implement a technique to slowly increase the MSS and maybe lower it if it sees that segments are lost. Not that this would be a problem, but it must be implemented and it uses code space and can't be ignored. Ignoreing these kind of issues leads to hard to explain interoperabilty problems.

I currently don't have the time to read this document but surely will do so. I have no idea wether your implementation suffers in any of the points I put my finger to. What I can say here though is that out of my experience RFC compliance alone is often not enough. The stack also must be able to deal with non complying implementations - at least to some degree.

Markus

We encode the setup vars and then create an MD5 hash out of this which is used as the ISN. The hash key is varied randomly and only valid for a certain duration. The SYN/ACK therefore must arrive within this time window to be acepted.

The compromise is in reality not that big in that almost all TCP implementations use some popular MSS value. Then you can't trust the anounced MSS value anyways since there are implementations which anounce a bigger MSS than what they actually accept. Sometimes there are also gateways along the way which drop segments above a certain size but fail to send the propper ICMP anouncements. Often this is the case because a sysop firewalls everything but uses a router behind the firewall showing this behaviour. In such scenarios it's often impossible to tell wether the TCP implementation of the oponent is broken or if it's just a configuration issue. This is just one area where strict RFC compliance of your impelmenation alone does not guarnatee seamless operation in the field. I do agree that such situatins are rare, but they DO exist. So it's wise to have a TCP implementation which is able to adapt the anounced MSS value acordingly or else you will have interoperabilty issues. The problem with these kind of things are that they ocure at the point in time your product is in the market. It's even nastier that although your product may follows the RFC's, the customer will point at you since it's Windows PC's TCP implementation does adapt the anounced MSS and therefore work. It's quite difficult to discuss such issues with end users.... So you better prepare right from the start.

Obviousely solving these kind of issues also uses code space and eventually also RAM. That's why I thought it's a good idea to bring this point to Ulf's attention.

Markus

I haven't found a checklist, but out of my experience the timely order of network events is something that is hard to test. In my project, most of the bug's that ocured after lab testing were in this area.

To give you an example, one time our implementation ran into problems if the answer to a second ARP query arrived before the first one. Was a stupid typo, but it got undiscoverd in the lab.

What you SHOULD do under all circumstances is visit some "hacker" sites, collect the latest attack tools and bomb your implementation with it. If you don't do it, you can bet that someone else will.

Another thing you can do is to use a second device of yours and programm it to generate all these ugly situations you fear most in your implementation. I.e. make sure to generate out of order pakets, fragmented pakets and so on. It's a matter of fact that you can generate the most exotic pakets with your own hardware the easiest way since even the raw socket interface does not allow to generate all kind of ugly things. Such a test device of yours then can also be used to verify future releases of your software.

Markus

I would expect the performance to be almost identical. Both are single cycle flash access, both a risk like. The Motorola site has some MIPS benchmarks for the 5282 I think it's about 78 Mips for the 80 Mhz 5282.

There are a number of low cost BDM's (BDM is Freescales version f JTAG debugging) for the coldfire. Both Linux and Windows hosted.

Out (Netburner's) 5282 product uses the Network to upload/download code and a non maskible serial routine running as a GDB stub.

If you have to have the BDM interface companies that have low cost ColdFire BDMs are

Paul