Subject: Multicast of Ethernet

From: "Miro Capan" <[email-masked]>
Date: Thu, 23 Apr 1998 16:35:58 +0200

Hello there!

I couldn't find any exact information on a following issue, so if there is
anyone who can tell me for certain what happens please do so.

I am wondering, are Ethernet frames addressed at a Ethernet Multicast
address passed to upper layer protocols like IP, regardless of is there a
multicast application running on a praticular host or not? In other words,
does an average Ethernet NIC knows how to filter Ethernet Multicast frames
when they are not needed by the upper protocols?

Thnx

Miro Capan
e-mail: [email-masked]

---

From: Hugh LaMaster <[email-masked]>
Date: Thu, 23 Apr 1998 10:02:08 -0700 (PDT)

> when they are not needed by the upper protocols?

The packet should never make it to the upper layers unless that
particular multicast group has been joined, although  I seem 
to recall a horror story about early versions of Appletalk thinking
that all multicast traffic was intended for some kind of Appletalk
sharing information [printers or something? - I know nothing 
about Appletalk] and slowing down to a crawl whenever multicast 
was present on the LAN.  Anyway, that is in the ancient past now.

However, depending on the Ethernet card, it may always, or 
only sometimes, interrupt the CPU and pass into the Ethernet 
driver where the packet will be dropped.  On a BSD Unix system,
or most reasonable Unixes, it wouldn't be a big deal anyway, 
since, running BPF/tcpdump, e.g. my old SPARC2 can filter ~400 
packets/sec, so a recent Pentium running FreeBSD ought to be able 
to filter many thousands of packets/sec - on real-world loads, an 
entire ethernet.  I'm not sure exactly what an "average" Ethernet
NIC is - does that include cheap old ISA cards found in used parts
bins?  Or are we talking about DEC 2114x-based and and Intel 10/100 
PCI cards?  Some cards have a small set of multicast groups that can 
be set and handled in hardware, although, I would expect that 
number to be exceeded in typical cases, so, I'm not sure how 
much it really helps.  This is where measurements would really
help regarding the real-world efficiency of these different 
styles of cards.

Then, there is also the factor of how well the cards do when
running Windows 95 or Windows NT.  Again, measurements would
be nice.  Anybody know of some good web pages on this?

--
 Hugh LaMaster, M/S 233-21,    ASCII Email: [email-masked]
 NASA Ames Research Center     Or:          [email-masked]
 Moffett Field, CA 94035-1000  No Junkmail: USC 18 section 2701
 Phone: 650/604-1056           Disclaimer:  Unofficial, personal *opinion*.

---

From: Bill Fenner <[email-masked]>
Date: Thu, 23 Apr 1998 14:40:29 PDT

The short answer is that yes, ethernet NICs know something about
multicast.  The ideal NIC would perform "perfect filtering", where you
tell the NIC exactly which ethernet multicast groups you want to join
and it only passes you those packets.  In the real world, though, NICs
vary from having a 1-bit filter (i.e. "yes, all multicast" or "no, no
multicast"), to having a small hash table which allows selection of a
set of multicast groups to receive, to having a small perfect filter
and a larger hash table (the larger the hash table, the fewer the
collisions).

Hopefully, the trend towards larger perfect filters and larger hash
tables will continue.

  Bill

---

From: Don McGregor <[email-masked]>
Date: Thu, 23 Apr 1998 18:06:50 -0700 (PDT)

> This is where measurements would really

I second that. I'm curious about what happens when you subscribe
to large numbers of mcast groups. I've heard, via folklore, that
cards eventually go into promiscous mode, but have heard varying
stories on the number of groups you can subscribe to before this
happens.

What would be a good test?

---

From: [email-masked] (John A. Stewart)
Date: Thu, 23 Apr 1998 22:44:32 -856436 (EDT)

Hugh;

BZZZT! Wrong! Our site just got hit by this problem, I think. I have
been asked to "tone down" my multicasting experiments....

Also, I won't mention Mark Hanley wondering how ICMP messages from internal
Banyan Vines machines (running our financial software - *just* replaced!)
made it to him from up here in Canada...

Problems still abound, even in "modern" networks.

John Stewart
[email-masked]

> I seem

---

From: [email-masked] (John A. Stewart)
Date: Thu, 23 Apr 1998 22:44:32 +447407740 (EDT)

Hugh;

John Stewart
[email-masked]

---

From: Beau Williamson <[email-masked]>
Date: Fri, 24 Apr 1998 12:05:15 -0500

>Hopefully, the trend towards larger perfect filters and larger hash

Bill,

Do you have any info (or know of a web site that has this info) on which
cards do what?

Beau Williamson

---

From: Hugh LaMaster <[email-masked]>
Date: Fri, 24 Apr 1998 11:05:35 -0700 (PDT)

> and a larger hash table (the larger the hash table, the fewer the

Which chipsets (and NICs), have both the small perfect filter 
along with a hash table?  Of those, which are supported
with open source drivers (in linux, FreeBSD, NetBSD, etc.)?
Do those chipsets have any other annoyances wrt performance?
[Forced misalignment of data, for example.]

---

From: Allan MacKinnon <[email-masked]>
Date: Sat, 25 Apr 1998 12:07:17 -0400

> [Forced misalignment of data, for example.]

	The DEC 21041 has this feature.  A fairly popular chip....

Here's a snipped from an old post of mine:
>
>         The Digital 21041 PCI Ethernet controller takes 
>         the CRC-32 of the multicast address and uses
>         the 9 most significant bits as an index into
>         a 512 bit table of 1's and 0's (nice!) to determine
>         if a multicast address is in use.
> 
>         The 21041 also supports 'perfect filtering'
>         of up to 16 addresses as well.

-- 
Allan MacKinnon
[email-masked]
Boston, MA - 617/424-0615

---

From: Hugh LaMaster <[email-masked]>
Date: Mon, 27 Apr 1998 10:58:26 -0700 (PDT)

> 	The DEC 21041 has this feature.  A fairly popular chip....

Which feature?  The hash table or the force misalignment ;-)
Both, actually.

According to a recent post, the Intel chipset uses less CPU
because the alignment can be set so that the user data
portion of a packet is aligned on a (N) byte boundary
for a faster subsequent bcopy() once the header has
been processed.  The DEC chipset forces misalignment,
which causes copies to eat a few more CPU cycles.  
OTOH, the DEC 21x4x is said to have superior multicast 
performance.  There are some old web pages around 
supporting these ideas, but, they are fairly old 
and don't discuss the most recent chipset revs, 
which, may be the same, or, may be different. 
They also don't discuss most of the other chipsets
out there.  So, web page pointers to up-to-date
information would be appreciated if known.

---

From: Don McGregor <[email-masked]>
Date: Wed, 6 May 1998 17:39:20 -0700 (PDT)

Re: Ethernet cards & the size of their multicast filters:

I got to poking around in the source for Linux ethernet drivers
(http://cedis.gsfc.nasa.gov/linux/drivers/index.html) and picked up
a few pointers. There is no guarantee that the source for the
drivers actually matches the full capabilities of the cards, but
the odds seem pretty good. 

A few fast ethernet cards:

DEC "tulip" cards--Dec 21040/21041/21140/21142/21143: 1000 group limit
before it goes into multicast-promiscous mode

Intel Etherexpress Pro 100B: 64 group limit

3Com 3C5*9, 3C900, 3C905, 3C592, 3C595, 3C597  : zero. Any mcast group 
subscribed causes the card to go into multicast-promiscuous mode. Worse,
it appears that the Windows NT 4.0 driver for the 3Com Etherlink III
3C5098-C 10 mb/s card I've got is _always_ in multicast-promiscuous mode; 
after a clean reboot I bring up the performance monitor, put some 
mcast on the wire from another machine, and watched the CPU usage go up.

On the positive side, on my 166 pentium with a 10 mb/s card and NT,
you can see about 2000-2500 multicast packets/sec come across the interface
before CPU usage gets above 10%. So, to an extent, you can get decent
performance without filtering by just throwing faster CPUs at the problem.

I'll try to put up a web page on this over the next few days.

Don McGregor
[email-masked]

---

From: Bill Fenner <[email-masked]>
Date: Wed, 6 May 1998 19:54:59 PDT

As you mentioned, it's not necessarily a good idea to assume that any
particular device driver describes the limitations of a certain chip.
It's possible that a driver writer doesn't understand or doesn't want
to take advantage of the capabilities of any given device, which is
why I said that chip/card manufacturers are much better sources of
this information.

Let me describe the types of filtering that I am familiar with:

1. 1-bit filtering: promiscuous to multicast or not.  This is what all
3Com cards that I am familiar with do (e.g. sun ec, PC 3c5xx series)
(although I am not familiar with their newest offerings).  Hosts that
support multicast at all simply have to set this bit, since all hosts
are always members of the ALL-SYSTEMS multicast address.

2. Hash-based filtering: a hash table consisting of single-bit
entries; the card hashes the multicast address and if that hash
bucket's bit is set then it accepts the packet.  Many cards (e.g.
sun le, sun qe, sun BigMAC, WD8003, ...) use a 64-bit hash table
using the ethernet CRC as a hash.

3. Perfect filtering: a table containing exactly the addresses
for which packets should be accepted.  The DEC TULIP card has
a small perfect filter, so that systems which only join a small
number of multicast groups (e.g. ALL-SYSTEMS and a couple of
others) need never receive packets they don't want.  The TULIP
also has a 512-bit hash filter, which can be used when the number
of multicast addresses exceeds the capacity of the perfect filter.

It's more interesting to describe cards or chips in these terms, e.g.

TULIP: 16-entry perfect filter (which you have to use for your own
MAC address and for the broadcast address, so you get 14 individual
multicast addresses) or 512-bit hash table.

3Com 3C5*9: 1-bit filter; promiscuous or not.

WD8003/SMC Ultra: 64-bit hash table

  Bill

---

From: Beau Williamson <[email-masked]>
Date: Thu, 07 May 1998 11:01:17 -0500

Don,

A web page with this information would be great!!!!  Once you get it going,
you might send it's URL to as many NIC card manufacturers as possible to
get them to keep this issue in mind for future products.

Also, as Bill Fenner points out, what the driver does and what the card is
capable of are not necessarily the same, but it's a good start.  The
ultimate web page would list the card's capability and then list how
various (Win95, Linux, FreeBSD) driver's handle multicast.  (I know I'm
dreaming but....)

Beau Williamson