is multicast *really* to all stations at once with a switch?

[Rick Jones]

I was thinking about what it would take to synchronize two instances
of netperf to get them to send their bursts at "the same time" to
explore some switch buffering questions. I don't know that I'm going
to make the requisite code changes to netperf to do it, but it got me
wondering:

When a switch receives a multicast frame on one port, and goes to send
it out "all" the other ports, does it in essence walk down the "list"
of "other ports" queueing (a copy of) the frame to each in turn?

For something like a 48 port switch, how much time might pass before
the frame starts exiting say port 2 and when it starts exiting port 48.

Ballpark - I suppose it probably depends on the switch.

rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

[glen herrmannsfeldt]

Rick Jones <rick....@hp.com> wrote:
(snip)

> When a switch receives a multicast frame on one port, and goes to send
> it out "all" the other ports, does it in essence walk down the "list"
> of "other ports" queueing (a copy of) the frame to each in turn?

> For something like a 48 port switch, how much time might pass before
> the frame starts exiting say port 2 and when it starts exiting port 48.

Instead use a repeater and only connect the transmit outputs
to the inputs of the switch under test. A repeater should reliably
transmit on all ports at the same time. You can even vary the cable
length to add small delays.

Then again, if you work at HP just ask the people in the
ethernet switch section.

-- glen

[bod43]

On 18 Dec, 21:58, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> Rick Jones <rick.jon...@hp.com> wrote:
>
> (snip)
>
> > When a switch receives a multicast frame on one port, and goes to send
> it out "all" the other ports, does it in essence walk down the "list"
> > of "other ports" queueing (a copy of) the frame to each in turn?
> > For something like a 48 port switch, how much time might pass before
> > the frame starts exiting say port 2 and when it starts exiting port 48.

This will be imeplementation dependent.

Some switches (e.g. Cisco Catalyst 5000/5500, and non-fabric 6500)
have an internal bus that sends all incoming traffic to *every*
port. It is buffered there until a signal is sent on the control bus
telling the ports what to do with the traffic. Send or discard.

In that case the traffic will be send simultaneously from every port,
as long as there is no contending traffic.

This architecture though is not used with newer cisco switches
since I don't think that is scales well enough for current throughput
requirements.

I woudl imagine that the internal bandwidth in a modern switch
would be sufficent to make the delays small.

You can still get linecards for the 6500 that operate on the "old"
32G broadcast bus.

If you did decide to implement it, it would be worth considering
giving the users a broadcast option (all Fs). Note also that
on a multicast enabled network (i.e. where multicast traffic is not
treated as an all Fs broadcast) the end nodes have to
join the group (IGMP) before the switch will send the traffic
towards that host.

I think that IGMP enabled stack is an extra cost add on for
windows. A quick look suggests that it might be included now.
Tibco is widely used by multicast developers but will not
be cheap.

[Rick Jones]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Then again, if you work at HP just ask the people in the ethernet
> switch section.

I just want to make certain my knowledge horizon doesn't begin and end
with a single vendor :)

rick jones
--
a wide gulf separates "what if" from "if only"