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

Conference noted::pwv50ift

Title:Kit: Note 4229; Please use NOTED::PWDOSWIN5 for V4.x server
Notice:Kit: Note 4229; Please use NOTED::PWDOSWIN5 for V4.x server
Moderator:CPEEDY::KENNEDY
Created:Fri Dec 18 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4319
Total number of notes:18478

4169.0. "FDDI trouble" by STKAI1::PTORLIND () Mon Feb 24 1997 12:36

    Hello !!
    
    I need some advice on a performance issue at a customer site, what side
    to trouble shoot !! This is the case...
    
    Customer has 1 Alpha 4000 with 512MB mem, VMS 7.1, UCX 4.1-ECO2
    PW 5.0E and 2 Prioris ZX with double CPU's and a lot of 
    memory running NT 3.51. 
    The A4000 is using DEFPA fddi interface, the Prioris i don't know yet.
    
    These system are connected to and FDDI ring, and customer is
    experiencing that file copy is slow to and from vms and nt.
    Protocol is TCP-IP only. No clients connected on no other activity on
    system.
    
    This is what we tested with a 5MB text file, copy using the File
    Manager in NT.
    
    Copy file --> NT to NT   2-3 seconds
                  NT to VMS  15-20 seconds
                  VMS to NT  35 seconds  ( using File Manager on the
                                           receiving NT server)
                  VMS to VMS 4-5 seconds (using DECnet, only for test)
                  VMS to VMS (FTP) 2 seconds 
                  NT to VMS (FTP)  5 seconds
                  VMS till NT (FTP) 12 seconds
    
    
    We tested doing the same thing but off the FDDI, on a Ethernet segment
    instead using an AXP150 with VMS 7.1, PW 5.0E, UCX 4.1 and an Celebris GL
    as an NT server.
    
    When copy the same file from NT to VMS it took about 23 sec
    and from VMS to NT about 21 seconds.
    
    So, what we can see here is that on the FDDI, when involving PATHWORKS
    in the file transfer, the performance decreases a lot.
    Without PATHWORKS performance is OK.
    
    Anyone have any hints in what direction to start ??
    
    Could TCP Window Size on the NT server improve anything ??
    UCX tuning on the VMS side ??
    
    I'm going to enable debug mode on the vms server and check the logs.
    
    If anyone have any ideas at all i will be thankfull.
    
    
    
    Per Torlind / PATHWORKS support, Sweden
T.RTitleUserPersonal
Name		DateLines
4169.1VMSNET::P_NUNEZMon Feb 24 1997 12:5618
    
    You may be better off using UCX's TCPIPTRACE facility rather than
    server debug mode to trace this.  Putting the server in debug mode is
    just going to slow things down more. 
    
    Do $ HELP TCPIPTRACE for usage info.
    
    Might also ask in UPSAR::FDDI regarding FDDI tuning/parameters.
    LASSIE::UCX is UCX notes conference and URL for UCX tuning is
    http://www-mcs.iso.dec.com/ucx_tuning.html.
    
    Do you have any non-NT clients you could test the transfer with (to
    eliminate the NT IP stack as the source of problems)?
    
    I assume you used the same disk device on the PATHWORKS server for all
    file copy/ftp tests?
    
    Paul
4169.2Try this.CPEEDY::FLEURYMon Feb 24 1997 13:0710
    RE: .1
    
    This may be a case where the internal workings of UCX may be playing a
    part.  Can you have the customer try the following:
    
    
    $ UCX SET PROTOCOL TCP /NODELACK
    $ UCX SET CONFIG PROTOCOL TCP /NODELACK
    
    Dan
4169.3.2 fixed half of the problem :-)BULAN::peoto.soo.dec.com::ptorlindTue Feb 25 1997 07:0219
Hi !!

.2   Fixed half of the problem

Now it takes 2-3 seconds to copy the same 5MB file as mentioned in 
.0 from NT server to VMS/PW server. Great. Compare that with
previous 15-20 seconds. Customer impressed

But, it still takes 35 seconds from VMS/PW to NT server.

I checked the manuals for NT and kan see that Delayed Acks is
default in NT and there is according to the manuals no configuration
parameter to disable Acks as we did in the VMS/PW server.

Anyone know if there is any undocumented parameter or any other 
to do the trick of getting this to work ???


Per Torlind / PATHWORKS support, Sweden
4169.4Problem fixedBULAN::peoto.soo.dec.com::ptorlindWed Feb 26 1997 07:3013
Hi !!

Update to .3

Setting TcpWindowSize in Registryt on the NT server fixed 
it.



Thanks 


Per Torlind / PATHWORKS support, Sweden
4169.5Details, details...VMSNET::P_NUNEZWed Feb 26 1997 09:096
    
    What's the old/new values and on what basis did you select the new
    value?
    
    
    Paul
4169.616k default, 64k maxBULAN::peoto.soo.dec.com::ptorlindThu Feb 27 1997 02:2822
Hi !!


The old value "should be" 16k TcpWindowSize for FDDI, default
value in NT. So what we did was to set it first to 64k, maximum
value for fddi in NT. And then it worked so fast that the customer just
went bananas. Then i asked the customer to try lower that value
but he wanted to test the max value for a while to see if it has any
effect on anything else. Otherwise he will run with the max value.

Since the TcpWindowSize is not in there by default, you have to enter
it manually. But that, you probably already knew.

With this customers hardware configuration, AS4000, Prioris 6000 with 
dubble CPU's and on FDDI. I would suspect that it would not be any
disadvantage to use the maximum 64k value for TcpWindowSize.

Or ?? Anyone have any input on the value 64k ?? Any side effects to ??



Per Torlind / PATHWORKS support, Sweden
4169.7UCX not the problemPCSERV::PTORLINDSun Mar 02 1997 10:0411
    Hi !!
    
    
    I got the customer to set the ucx parameter back to the default..
    DEFACK
    
    And then try again and it still works great, so the problem was that
    the default TcpWindowSize is too low for this configuration.
    
    
    Per Torlind / PATHWORKS support, Sweden