Conference 7.286::fddi

>   OR SHOULD I USE THE ENET AND CONNECT THE VXT'S THROUGH A BRIDGE TO
>   AN FDDI NETWORK? 
    
    That sounds grand.  Concentrate multiple Ethernet LANs into one FDDI
    LAN by using DECbridge 6xx.  Should be cheaper than fitting many
    VXT2000s with FDDI interfaces.

    Since Ethernet is cost-effective, there is little motivation to connect
    FDDI to machines that don't frequently require more throughput than
    Ethernet can provide.  Put FDDI connections on powerful computers, and
    on terminals with networked live video or other high-bandwidth applica-
    tions.  I'm not aware that VXT2000 can make full use of FDDI's speed.

    Check the VXT conference for more authoritative comments on VXT2000
    network requirements (ROYALT::VXT).

    I would just like to add my 2 cents.  I can see that an FDDI controller
    for a VXT would be rather expensive at this time, but when the
    engineering costs become more resonalbe, I think it is necessary
    regardless of the load a VXT can or can not produce.  We seem to
    changing the purpose of bridges.  In the past we used bridges to
    segment network traffic.  Now, although we still try to do this,
    bridges are becomming expensive gateways to and from FDDI.  I have
    seen filtering percentages drop significantly.  More and more major
    sites are consolidating, and upgrading the existing server systems to
    handle the greater demands made by the increasing number of PC's
    and Window terminals.  These server systems would choke a 10 Meg
    Ethernet, so FDDI controllers are installed, and hence, the bridge
    has to forward just about everything.
    
    Mike

I think the FDDI connections will be be price competive in the near 
future, especially copper.  How are the current ethernet adapters
integrated into the terminals?  Through some kind of bus?  Are they
placed on the motherboard directly (seems like that would be the 
cost effective solution)?

doug

WHAT I HAD IN MIND WAS TO REPLACE THE THICK/THINET BOARD IN THE VXT WITH A NEW 
FDDI MODULE.  IS ANYONE WORKING ON THIS? IF SO LET ME KNOW. IF NOT, WHY NOT?
THE DECBRIDGE 6XX IS AN OPTION FOR THE APPLICATION I HAVE BUT, WILL IT CAUSE ANY
BOTTLENECKING OR SPEED REDUCTIONS IN THE NETWORK?

BRIAN

    You *really* have to ask in the VXT conference.  The software that
    runs on VXT2000 would have to support FDDI, and you need a hardware
    option.  These issues are controlled by the VXT design group.

Upgrading the Bridges or Repeaters to something like the PEswitch, but with 
the quantity of ports similar to the TM or GM would provide the best 
allaround solution.  "SWITCHING", instead of "BRIDGING" or "REPEATING".

I'm noticing that the 'other vendors' are waking up to the fact that 
"SWITCHING" is a Magnitude or Faster and will support the full bandwidth 
than "BRIDGING" can or does.

I just hope that Digital will awake to this FACT, before we get left 
behind.


Chris			:-(

Actually the "TM" and "GM" do "VERY ROBUSTLY" from "FDDI" to 10baseT for 
most any Workstation or VXT ...



Chris					:-)

    
    Switching vs. Bridging - switching and bridging are the SAME. There are
    different types of switching.
    
    	Cut-thru switch - Only looks at either the destination, source or
    	protocol and make a decision based on those fields. Kalpana was
    	one of the first. However, cut-thru switching for Ethernet can have
    	nasty side effects since you can't be guaranteed that the packet is
    	actually valid. Over time, Ethernet cut-thru switch vendors have
    	waited longer and longer bit times to guarantee a full packet, but
    	they still may switch bad packets. This technology may not be
    	appropriate for non-deterministic networks such as Ethernet. If
    	a customer puts a single station on an Ethernet port, cut-thru
    	switching can work. However, once you create a collision domain,
    	its value can drop dramitically. It is much for appropriate for 
    	determinstic networks such as FDDI and this kind of technology is 
    	the basis for our GIGAswitch/FDDI.
    
    	Cut-thru switch with buffers - similar to above trying to get more
    	of the packet before actually switching it. 
    
    	Store & Forward switch (really a bridge) - we changed the name to
    	compete in the marketplace. We originally marketed the DECbridge
    	900MX, but changed the name to the DECswitch 900EF. No change in
    	the code, we just created a new bezel. Some old DECbridge 900MX
    	products still report as this type of hardware, but run the same
    	code as the DECswitch 900EF. Store and forward technology is the
    	best for non-determistic network switching.

    Thanks Ted, you saved me the effort of entering the same response.
    
    Chris, our use of "switch" on our EE, EF and TX bridges is *really* 
    more of a marketing exercise than anything else. The competition
    started using "switch" as part of their product names, and we went
    with the flow, with the added commentary in our literature of the
    guarantees, of packet integrity, detection of bad, and runt packets,
    and the ability to provide full functionality with such features as
    support of redundant paths, & the ability to connect dissimilar
    networks such as FDDI to Ethernet, etc.
    
    Bob
    
    

    
    Thanks Bob, you entered the *EXACT* rationale from a field perspective
    as to why this was done. Combine both responses and you have your
    explanation.