Nayanip wrote:
> For small to medium LAN networks, only hubs are used and thefore the
> traffic not meant is also sent on the copper. How to filter this
> unwanted packets without the processor spending its resources, which
> will contribute to processor overhead?

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)

Nayanip <nps@spectrasmart-dot-com.no-spam.invalid> wrote:

> For small to medium LAN networks, only hubs are used 

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.

> I some times keep wondering the very purpose of MAC address, if all
> the data gets into the receive buffer?

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.

Nayanip wrote:
> Hello,
> I happened to see this thread only today and therefore a very belated
> query. I am currently developing firmware for networking application.
> For small to medium LAN networks, only hubs are used and thefore the
> traffic not meant is also sent on the copper. How to filter this
> unwanted packets without the processor spending its resources, which
> will contribute to processor overhead? I some times keep wondering
> the very purpose of MAC address, if all the data gets into the
> receive buffer?
> 
> Any comments will be highly appreciated. Thank you.
> 
> Nayani P
> 

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

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

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

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

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