TCP/IP software overhead ?

Hi,

I am trying to get a feel for how much resources one needs for the TCP/IP in an embedded system for the following typical scenario: The embeded system is connected to a busy fileserver type LAN. (10Mb/s or 100Mb/s). The embedded system only communicates on an add hock bases. i.e. a few hundred bytes every couple of seconds. (Telnet type interface), unless code is being uploaded, or captured data is dumped to a file over ethernet. What type of non-related traffic -- to the embedded -- system will eat up resources by forcing the embedded system to handle things in the TCP/IP stack. What % CPU time can one expect on something like a 30MHz ARM7 core type MCU with typical opensource TCP/IP implimentations.

Any comments and insights would be welcome.

Regards Anton Erasmus

Reply to
Anton Erasmus
Loading thread data ...

"It depends" entirely on the environment. Trivial in most circumstances

A variety of things can cause you to see irrelevant traffic:

  • Ethernet hub is used instead of a switch (rarer these days)
  • Broadcast / group address traffic, including: * Windows NetBIOS * Multicast streams where a cheap switch handles them like broadcasts * Routing protocol updates
  • Switch MAC forwarding table behavior * Can cause you to see unicast traffic that's not yours

As a general rule, you should only see a few packets (

Reply to
Richard H.

The traffic of few hundred bytes every few seconds is insignificant traffic for a 30 MHz ARM7 core. The %CPU taken by TCP should be negligible.

I suspect less than 1%.

Deepa

--

formatting link
EventStudio 2.5 - Embedded System Modeling with Sequence Diagrams

Reply to
EventHelix.com

Is that avarage or worse case peak load - i.e. when the packet must actually be handled ? I am interested in how much spare capacity I need, when the main application is a control system that should never overrun in the control task.

Regards Anton Erasmus

Reply to
Anton Erasmus

That'd be a conservative average. But you will regularly need to handle a lot of packets that are not for you, at least enough to discard them.

For example, on a typical server subnet, the "normal" quiescent traffic you'd see is < 1 multicast packet per second for router and switch healthcheck activities. Simply applying the multicast mask filter in your Ethernet controller will keep you from seeing these packets at all.

Broadcasts are a different matter - you need to reply to some of them, so you must process, filter, and act on all of them (if only to discard). Examples are ARP, which must be matched against your IP address, and possibly replied to; also, Windows NetBIOS broadcasts (name registrations, etc.), which can likely be ignored.

Normally, broadcasts are also

Reply to
Richard H.

Thanks for all the info so far. I am slowly getting a feel for what is involved. What sort of traffic are generated by typical game servers. Does this type of traffic require a fair amount of handling by non-interested nodes ?

Regards Anton Erasmus

Reply to
Anton Erasmus

must

handle

them.

An observation: You don't need to check the checksum before checking if the message needs processing by checking its IP addresses etc.

Reply to
robert

A clever point; certainly less overhead by inverting the steps.

Reply to
Richard H.

In general, I'd speculate gaming systems will be good neighbors like most servers - i.e., no change to the prior comments here. They are more likely to be using multicasts to multi-player gaming, but since m-casts have so many practical limitations it's unlikely you'd see it used.

Rash assumption: They haven't been cracked or infected, so they're not spewing garbage and pinging / port-scanning the world. Gaming systems are popular targets for malice, so they're more likely to be compromised and doing ugly stuff.

If you have access to a sample environment, grab your laptop, load up Ethereal (free at

formatting link
and plug into a jack to see what comes across. Let me know if you need a hand decoding it.

Richard

Reply to
Richard H.

Hello I happened to see this thread only today and therefore a very belate query. I am currently developing firmware for networking application For small to medium LAN networks, only hubs are used and thefore th traffic not meant is also sent on the copper. How to filter thi unwanted packets without the processor spending its resources, whic will contribute to processor overhead? I some times keep wonderin the very purpose of MAC address, if all the data gets into th receive buffer

Any comments will be highly appreciated. Thank you

Nayani

Reply to
Nayanip

Please get a book on TCP/IP protocols. My favourite is:

W. Richard Stevens, TCP/IP Illustrated, Volume 1, The Protocols.

If the data link is Ethernet (or some similar LAN), the frames are sent with MAC addresses. The receiving interface chip will pick only those packets intended for it (own MAC or local broadcast), so no CPU overhead is associated with it.

There is a small overhead in translating the IP addresses to MAC addresses at the start of a packet interchange. This is taken care of by the ARP (Address Resolution Protocol).

HTH

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

I'm reasonably sure that's not any longer the case. Even 5-node home networks tend to have a switch in the center, these days.

Nobody in their right mind would try to build a 'medium' LAN using only hubs anymore. Nobody ever should have.

No need to wonder --- because it doesn't. Not into the buffer your CPU has to worry about, anyway.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

In the datasheet for your Ethernet controller:

  • Find the field for MAC address - fill it in.
  • Find a flag for promiscuous mode - turn it off.
  • Find the multicast mask - you can typically disable all of them.
  • Find the broadcast flag - enable it (or you won't get ARPs).

The Ethernet driver should then see only traffic to your MAC, or to the broadcast address (which may still require a lot of discards; broadcasts will arrive regardless of hub vs. switch)

Reply to
Richard H.

Hello

Thank you very much (Tauno Voipio, Richard. H, Hans etc.) for the ver

valuable information. Will try to get the suggested book.

Regard

Nayan

Reply to
Nayanip

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.