[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::fddi

Title:	FDDI - The Next Generation

Moderator:	NETCAD::STEFANI

Created:	Thu Apr 27 1989
Last Modified:	Thu Jun 05 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2259
Total number of notes:	8590

1050.0. "Poor performance Pathworks with DEFZA, DECram" by BIGRED::SPARKS (I have just what you need) Thu Aug 05 1993 21:15

    We are seeing an interesting performance problem at my customer.
    
    This scenario is what we have been using
    
    DECram 1.?
    VMS 5.5-2
    Pathworks 4.1
    VAXstation 4000-90
         |                                DEMPR------ 486-33 PC
         |ethernet                          |
         |                                  |
     610 bridge                          610 bridge
        ==========================================
    
    In this scenario and many simular we get spetacular performance,
    to load Microsoft Excel takes between 4-7 seconds (faster than hard
    disk)  
    
    The server has the applications loaded in DECram as a Pathworks file
    service, and the machine is read only.
    
    We move to the following scenario 
    
    
    
      |                                             DEMPR ------ 486-33
      |                                               |
    610 Bridge          VAXstation 4000-90            |
                             DEFZA                 610 Bridge
    ====================================================
                        FDDI
    
    All we did wasput the DEFZA in the VAXstation and disabled the ethernet
    circuit and connect to the FDDI.
    
    This scenario resulted in performance of 14-45 seconds,  We went back
    and forth multiple times with the exact same results each time.
    
    Any ideas, is there some tuning we can do with the VAX, is it the
    turbochannel adaptor?
    
    We experienced almost identical results with and DEC 3000-400 AXP
    configured the same
    
    Thanks for any advice, this is become critical to both a major SI
    opportunity and multiple Alpha system sales.
    
    Glenn Sparks

T.R	Title	User	Personal Name	Date	Lines
1050.1		STAR::GAGNE	David Gagne - VMS/LAN Development	`Fri Aug 06 1993 10:59`	9
	The Ethernet does DMA on both transmit and receive. The DEFZA does DMA only on receive. All transmitted packets have to be copied to the DEFZA. This obviously costs CPU cycles. This could be where you are losing your performance. The DEFTA (an FDDI Turbochannel device) does DMA for both transmit and receive. The version of VMS that supports the DEFTA is V5.5-2H4. The DEFTA is not and will never be supported on VMS V6.0.
1050.2	I don't think it's the DEFZA...	SCHOOL::WASHABAUGH	Born to be Mild	`Fri Aug 06 1993 11:07`	14
	> The version of VMS that supports the DEFTA is V5.5-2H4. The DEFTA is > not and will never be supported on VMS V6.0. I think you meant "The DEFZA is not and never will be supported on VMS V6.0"... I don't think the problem is with the DEFZA. You are perfectly correct in stating the the DEFZA does not have transmit DMA. However, I don't think this would lead to the miserable performance that this person is reporting. I would think that the problem would be some sort of network configuration problem, maybe something that causes lots of dropped/retransmitted packets. However, I am most ignorant in that area and cannot be of any assistence... Doug [Former fimrware engineer on the DEFZA]
1050.3		CSC32::B_GOODWIN		`Fri Aug 06 1993 11:22`	7
	It may be that the DEFZA is transmitting so fast that the PC can't keep up and so retransmissions must occur. If you are using DECnet as your transport for Pathworks, I would look at some of the node counters under ncp and see if you are retransmitting alot. You might be able to reduce this amount of data retransmitted by lowering "pipeline quota" on the vax. The only other way to see if this is happening is to put a analyzer on the network and analyze the protocol.
1050.4		KONING::KONING	Paul Koning, A-13683	`Fri Aug 06 1993 11:53`	4
	I remember something about the DEFTA not being supported on one of the VAX 4000 models? Correct? If so, was it the -90? paul
1050.5	...	MUDDY::WATERS		`Fri Aug 06 1993 13:45`	3
	VAXstation 4000 model 60 (a.k.a. PMariah) does not support DMA on the TURBOchannel. So DEFZA/DEFTA won't work on VS 4000/60. 4000/90 supports FDDI for sure, or you would not be reading these notes... See 417.2.
1050.6	.1 is correct as it stands	STAR::GAGNE	David Gagne - VMS/LAN Development	`Fri Aug 06 1993 15:27`	5
	Regarding the comment in .2: .1 says that the DEFTA is not and will never be supported in V6.0 and that is correct. The DEFZA is supported in V6.0. The DEFTA will be supported in a release after V6.0 and is now supported on V5.5-2H4.
1050.7	Will keep you posted	BIGRED::SPARKS	I have just what you need	`Tue Aug 10 1993 22:46`	7
	I am going to re execute the tests myself, and will zero all counters and make snapshots after each test. I still think the DEMPR would slow the packets enough for the PC to handle them though, but it is worth a shot. I will post any results. I am on vacation this week, so it will be a few days, thanks for the replies so far. Sparky
1050.8	DEFTA seemed to fix it.	BIGRED::SPARKS	I have just what you need	`Wed Aug 25 1993 10:39`	8
	The customer upgraded to the DEFTA card and driver, did some system tuning and the performance is back on track with no major peaks. I'm not saying the problem was the DEFZA, but it went away when the card did, also there was some system tuning done at the same time. Thanks for the help. Sparky
1050.9		BIGRED::SPARKS	I have just what you need	`Thu Aug 26 1993 18:37`	8
	I talked with the system manager some more, and they made a couple other changes also. In the tests with the DEFZA they didn't have the logical netbios$device logical defined, also the PC was loading the last and lanses drivers. In the second test Last and Lanses were disabled and the logical defined, so everything is somewhat inconclusive. The performance now is very good though. Sparky
1050.10	No faster than Ethernet?	WARNUT::FORSHAWJ	Jon Forshaw	`Fri Apr 15 1994 05:27`	18
	I have a customer with PATHWORKS V4 and two Open VMS Alpha AXP 3000 Model 600 servers and about 1300 PCs. He has recently put his two servers on an FDDI ring using a DEFTA-FA card with a Synoptics bridge onto Ethernet segments with the PCs. To his surprise he has seen no improvement in performance and has asked is happening? Should he see an improvement in performance, how can he demonstrate this to himself, is PATHWORKS a bottleneck and so on? I have not yet qualified the extent of how he is measuring the performance and that he has everything configured correctly, but I thought I would drop a note in here to see if I could get some initial reactions to this situation. Any comments gratefully received. Regards, Jon.
1050.11	Bridge adds latency?	SSDEVO::PARRIS	RAID-5 vs. RAID-1: n+1 << 2n, in $$$	`Fri Apr 15 1994 14:43`	10
	Re: .10 I'd expect that the conditions under which you'd see a noticeable improvement would be if the Ethernet was saturated before the move to FDDI, and that by dividing up the clients across multiple Ethernet segments you eliminated that bottleneck. Moving the servers from Ethernet to FDDI does mean you're introducing additional latency in the bridge. How fast can the Synoptics bridge filter and forward between FDDI and Ethernet?