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

Anton Erasmus wrote:
> 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.

"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 (<5) per second 
that wouldn't be relevant to you.  But higher volumes can happen with 
wierd circumstances, so you wouldn't want to fall over when it happens.

One defensive measure is to pre-filter the MAC packets in your Ethernet 
NIC - you'll probably find a broadcast/multicast address config 
register, which you can set to ignore most traffic that's not pure 
broadcast (like ARP) or unicast to your MAC address.

Another measure would be to ensure that your MAC address and IP address 
matching logic is very efficient at discarding other junk that gets through.

HTH,
Richard

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
--
http://www.EventHelix.com/EventStudio
EventStudio 2.5 - Embedded System Modeling with Sequence Diagrams

On 1 Feb 2005 19:04:15 -0800, "EventHelix.com" <eventhelix@gmail.com>
wrote:

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

Anton Erasmus wrote:
>>I suspect less than 1%.
> 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.

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 <1 packet per second.  However, events can 
cause them to easily spike above 200-300/sec.  For example, when an 
infected PC tries to rapidly ping every IP in an address range, which 
causes the router to broadcast an ARP for every IP it doesn't already 
have cached.  This happens often (daily or more often, depending on how 
well they keep their systems anti-virused).

So... under normal conditions, the volume is so low as to be trivial. 
However, you need to be efficient enough to sustain the bursts without 
falling over.  The key there will be getting the packets out of the 
Ethernet controller buffer and filtered efficiently.  Done well, even 
200-300 broadcasts/sec could probably be handled in <5% of your CPU.

Richard

On Thu, 03 Feb 2005 08:41:47 -0700, "Richard H." <rh86@no.spam> wrote:

>Anton Erasmus wrote:
>>>I suspect less than 1%.
>> 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.
>
>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 <1 packet per second.  However, events can 
>cause them to easily spike above 200-300/sec.  For example, when an 
>infected PC tries to rapidly ping every IP in an address range, which 
>causes the router to broadcast an ARP for every IP it doesn't already 
>have cached.  This happens often (daily or more often, depending on how 
>well they keep their systems anti-virused).
>
>So... under normal conditions, the volume is so low as to be trivial. 
>However, you need to be efficient enough to sustain the bursts without 
>falling over.  The key there will be getting the packets out of the 
>Ethernet controller buffer and filtered efficiently.  Done well, even 
>200-300 broadcasts/sec could probably be handled in <5% of your CPU.
>

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

Anton Erasmus wrote:
> On Thu, 03 Feb 2005 08:41:47 -0700, "Richard H." <rh86@no.spam>
wrote:
>
> >Anton Erasmus wrote:
> >>>I suspect less than 1%.
> >> 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.
> >
> >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.
> >

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

robert@suesound.co.za wrote:
> An observation:
> You don't need to check the checksum before checking if the message
> needs processing by checking its IP addresses etc.

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

Anton Erasmus wrote:
> 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 ?

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 http://www.ethereal.com), and plug into a jack to see 
what comes across.  Let me know if you need a hand decoding it.

Richard

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