TCP/IP software overhead ?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

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


Re: TCP/IP software overhead ?
Quoted text here. Click to load it

"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

Re: TCP/IP software overhead ?
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


Re: TCP/IP software overhead ?

Quoted text here. Click to load it
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






Re: TCP/IP software overhead ?
Quoted text here. Click to load it

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

Re: TCP/IP software overhead ?

Quoted text here. Click to load it

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


Re: TCP/IP software overhead ?

Quoted text here. Click to load it
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.


Re: TCP/IP software overhead ?
Quoted text here. Click to load it

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

Re: TCP/IP software overhead ?
Quoted text here. Click to load it

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

re:TCP/IP software overhead ?
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



Re: TCP/IP software overhead ?
Quoted text here. Click to load it

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


Re: re:TCP/IP software overhead ?

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: TCP/IP software overhead ?
Quoted text here. Click to load it

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)

re:TCP/IP software overhead ?
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


Site Timeline