Conference 7.286::fddi

918.0. "FDDI -- Ethernet ; Does DECnet limit packet size to 576?" by MLTVAX::PUDER (Karl Puder, DFS Engineering) Fri Apr 02 1993 16:59

I don't know if this is the right place to ask this, but here goes...

I have a customer complaining of network perfomance problems.  (They thought
is was a DFS T1.3 problem, but then discovered that it was not, but now I'm
involved anyway).  His characterization of the situation is included below.
What I'd like to know is whether his theory of what's going on is correct
or even makes sense, since I am ignorant of this level of detail of DECnet
software and hardware.

Thanks,
	:Karl.

  


	Investigation of exactly what changed led to the following:

    1.	Good performance under DFS V1.2 was observed when the DFS server
	was running on the VAX 8830 with only the Ethernet interface.

    2.	Poor performance under DFS V1.2 was observed when the DFS server
	was running on the VAX 6000 model 500 with the FDDI interface which
	is bridged to the Ethernet.

A reexamination of the DFS T1.3 performance data leads me to beleive that the
phenomenon which I initially reported in QAR 23 is in fact a consequence of
DECnet's interaction with the DEMFA which results in a buffer size of 576
bytes being selected even if the DECnet cluster alias is disabled.


This would appear to imply that either the DECbridge 610 is failing to properly
"translate" the "on Ethernet" bit when Ethernet frames are translated into FDDI
frames (and vise versa), or the DEMFA interface/drivers are not properly
interpreting the "on Ethernet" bit if it is present in the translated FDDI
frame.

No.  DECnet Phase IV currently treats FDDI as Ethernet

    The bridges, the FDDI controllers, and the FDDI drivers on VMS do not
    look at the ON-NI bit.  They don't even know where it is because it's
    not part of the data link layer header.
    
    Remember that using cluster alias will affect the use of the ON-NI bit.

    For something like DFS (or anything else that runs on top of DECnet),
    you should never see FDDI perform worse than Ethernet, right?
    
    Except, of course, if they the configuration error where both the FDDI
    and Ethernet adapters are defined as DECnet LINEs in NCP and are both
    connected to the same extended LAN.  I thought this was mentioned
    somewhere else in this conference but I can't find it now.
    
    If the 6000 had an ethernet controller connected to an ethernet which
    was bridged onto the FDDI... and now they are adding an FDDI
    controller... if they leave the ethernet controller connected to that
    ethernet, they will have a problem unless they PURGE the ethernet line
    definition from NCP and reboot.
    
    In this case, DECnet has "modified" the address of both the ethernet
    adapter and the fddi adapter and therefore both adapters have the same
    address (ie aa-00-04-00-xx-xx).  The system is then receiving every
    packet twice and/or the bridges are getting confused.

Thanks for the information.  I'll find out whether my customer has a
misconfiguration.

	:Karl.