Conference netcad::hub_mgnt

            <<< NETCAD::KALI$USER3:[NOTES$LIBRARY]HUB_MGNT.NOTE;1 >>>
                   -< DEChub/HUBwatch/PROBEwatch CONFERENCE >-
================================================================================
Note 3846.0*                 VNbus real bus speed ??                  No replies
BIS1::dbc275.bro.dec.com::dewil "dewil"              20 lines   6-SEP-1996 09:07
--------------------------------------------------------------------------------
	Hello,

being a novice in the switching business, I possibly come with a 'stupid'
question : regarding the VNbus it is stated that "each operates at 400 Mbps
for a total VNbus capacity of 1.2 Gbps"  since "up to 3 VNbuses may exist
in one DEChub900 MultiSwitch".
What is the value of this 1.2 Gbps total VNbus capacity, compared eg. with
Xylan which states for its OmniSwitch that it has a "frame-bus operating 
at 640 Mbps (32 bit by 20 MHz)" or OmniCell "operating at 13.2 Gbps (400 bit
by 33 MHz)" ?
As far I can understand the VNbus description and the fact that each "VNswitch
can attach to only one VNbus at a time", the only meaningful figure is the
400 Mbps, and not the 1.2 or higher Gbps values which are spread around in
the specifications.
Can someone confirm or give a sensible explanation ?

How do we relate to the OmniCell cell matrix backplane ?
many thx.

If you have 6 VNswitches in the hub, with each pair
on their own VNbus, you have 1.2 Gbps
available on the backplane. How can that not be a valid
figure?

-Mike

	Thx.
	
	So, a configuration with four VNswitches with two 100 Mbps ports
	each, ie. 800 Mbps global capacity needed, should be no problem.
	I will be able toswitch data at full 100 Mbps from each port to any
	other at any time without bus congestion ?!

	rgds.

    
    Remember, however, that you won't be able to talk between VNbuses
    unless you link them with another technology such as FDDI or ATM or
    Ethernet.

    Also, doesn't each VNbus have some number of "channels" which can
    transmit to each other module independently?  The VNseries has a DME
    chip that has 40-something ports on it - you can have one 'virtual
    port' on module 1 with a connection to module 2 and another with a
    connection to module 3 doing independent conversations over the sams
    shared bus.
    
    People do forget that a shared bus is still shared.
    
    If it's busy - tis' busy.  It could be a googlebyte bus - but if only
    one person gets it at once, it's busy. Tough toenails. Wait.
    
    So, an important advantage with our architecture is that although it's
    a bus, it's bandwidth can be divided up and used as we best need to
    optimize it.
    
    At least, that's my understanding of it.
    
    For those who like to compare raw numbers, megabits per fortnights and
    flops per bip...that's mostly invalid.
    
    Rememebr what the USE sees is DATA THROUGHPUT.  THAT is the real
    question.  So I'd ask Xylan and Digital and Whomever...how much data
    can you pump through from ONE module to ANOTHER.
    
    Remember that CISCO cheats on benchmarks with Catalyst because
    they'll only submit ONE linecard which does NOT show their bus to
    linecard thruput which (I believe) sucks wind.
    
    So....again....if your user cares about speeds, feeds and is buying
    boxes on that alone - tell them to get a real job because THEIR
    customers really don't care - the LAN users (and buyer of LAN
    equipment) should really only care about thruput and scalability.
    
    (grin)
    j