Subject: NICs chipsets and multicasts

From: John Stumbles <[email-masked]>
Date: Tue, 14 Jul 1998 11:57:45 +0100 (BST)

I recently read some messages about the various types of NICs (based on
the chipsets used in them) and their performance in a multicast
environment. The gist was that, depending on the chipset, the NIC would
handle up to so-many multicasts on the wire in its hardware, but a greater
number of multicast addresses on the wire would cause the NIC to go into
promiscuous mode and pas all mcasts up to the processor for handling. Thus
there would be a performance penalty for certain NICs in a busy multicast
environment.

I was sure I'd archived these messages but - guess what, can I find them?
can I hell! :-(
I can't even remember what list or ng I saw them on, hence the cross-post.
[email Cc:s of replies to ng appreciated]

If anyone saw this thread and has a copy of the correspondence, or knows
the score on chipsets, NICs and mcasts and could update me, I'd be most
grateful!

tia,

--
John Stumbles                                      [email-masked]
Computer Services, University of Reading       http://www.rdg.ac.uk/~suqstmbl 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       If a job's worth doing, it'll still be worth doing tomorrow.

---

From: [email-masked]
Date: Tue, 14 Jul 1998 12:38:22 +0100 (BST)

>there would be a performance penalty for certain NICs in a busy multicast

There was a discussion of this on [email-masked] in early May.

It is not the number of multicasts on the wire that matter, but the
number that the host is interested in. For some NICs, any number
greater than zero causes them to go multicast-promiscuous. Better ones
split the address range into `buckets' or even have lists of
individual addresses to accept.

I append Bill Fenner's message on the subject from May 6th.

Andrew

----------------------------------------------------------------------------
|      From Andrew Findlay at Brunel University, Uxbridge, UB8 3PH, UK     |
| [email-masked]     +44 1895 203066 or +44 1895 274000 x2512 |
----------------------------------------------------------------------------

> Date: Wed, 6 May 1998 19:54:59 PDT
> From: Bill Fenner <[email-masked]>
>  
> 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: Don McGregor <[email-masked]>
Date: Tue, 14 Jul 1998 09:24:27 -0700 (PDT)

> there would be a performance penalty for certain NICs in a busy multicast

I did some research on what chipsets did what. It's on a web page
at

http://www.stl.nps.navy.mil/~mcgredo/projectNotebook/mcast/EthernetMain.html

or, for a higher level application-oriented discussion,

http://www.stl.nps.navy.mil/~mcgredo/projectNotebook/mcast/ethernet.html

The major variables are number of mcast groups subscribed to, the
interface hardware capability, and traffic volume. When you subscribe
to too many mcast groups the card throws up its hands and goes into
mcast-promiscuous mode. At that point all mcast packets get passed
up the protocol stack for filtering. The good news is that CPUs are
a lot faster these days, so the relative performance hit isn't as bad,
even for fairly large traffic volumes.

The 3Com cards are essentially always in mcast-promisc mode. The
DEC Tulip cards are the most sophisticated. They have a 512 bit
hash table to imperfectly filter subscribed mcast groups. The Linux
driver for those cards actually goes up to 1000 groups before going
into mcast-promisc mode; the hash table is overloaded by about a
2X factor. 

We're doing some research with software that will stress the number
of mcast groups subscribed to, potentially in the hundreds per
host. I'll probably be doing some research on how routers and
switches behave under that sort of load. Suggestions welcome.