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

Conference lassie::ucx

Title:DEC TCP/IP Services for OpenVMS
Notice:Note 2-SSB Kits, 3-FT Kits, 4-Patch Info, 7-QAR System
Moderator:ucxaxp.ucx.lkg.dec.com::TIBBERT
Created:Thu Nov 17 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5568
Total number of notes:21492

5168.0. "NFS VMS-VMS Slow transfer:UCX 4.0-ECO_4 ?" by PADNOM::CHEMINANT () Tue Jan 28 1997 11:32

  A  customer is complaining that the NFS VMS-VMS transfer is 
  very slow :

   a local file 104801 blocks ( Sequential file
                                Fixed length  86 Bytes records)
   to a DNFS device takes 10 mn time, 
  but,
   copying the same file from DNFS device to the local device
   takes 1:30 mn.

 1/ Looking at the NFS Server side, it appears that the NFS$SERVER 
    process stays often in LEF state.

 2/ I can reproduce the similar behaviour, here at Digital office :
    looking at the TCPIPTRACE file, it appears that most of the 
    NFS write request are sent twice (the reply NFS request isn't
    received in time ?)
    However , I take a quick look at the customer TCPIPTRACE file,
    but, it appears that NFS request are acknowledged in time.
    (I'm waiting for the complete customer TCPIPTRACE file)

 3/ Transferring the same file, at the customer site, through FTP
    takes : 53657980 bytes sent in 00:01:03.66 seconds (823.12 Kbytes/s)

 4/ Today, the customer is using DECNET to copy the files between the 
    two VMS nodes : the transfer time is closed to FTP transfer.

 Is this problem known ?

 Customer Environment : VMS 6.2 / VAX /UCX 4.0-ECO_4
   
 Best regards. Gait.
T.RTitleUserPersonal
Name		DateLines
5168.1LASSIE::CORENZWITstuck in postcrypt queueTue Jan 28 1997 12:1011
    Could you try editing the SYS$STARTUP:UCX$NFS_SERVER_STARTUP.COM file
    changing 
$ DEFINE/SYSTEM/EXE/NOLOG UCX$CFS_KEEP_ALLOC 0          ! Deallocate blocks
    to 
$ DEFINE/SYSTEM/EXE/NOLOG UCX$CFS_KEEP_ALLOC 1          ! Don't deallo blocks
    and restart the server?
    
    I'm not sure if that helps this case or not, but I think it might.  Let
    us know what happens, if anything.
    
    Julie
5168.2UCX$CFS_KEEP_ALLOC = 1 ===> EMPTY file.PRSSOS::CHEMINANTThu Jan 30 1997 12:0819
    Hi Julie,
    
    
    
    
    Thanks for your reply, but ... very bad news : 
    
     setting this logical name (UCX$CFS_KEEP_ALLOC to 1) on the NFS$server
     gets better performance, BUT the file is EMPTY :
    
      $DIR/SIZ 
      Directory DISK$USERS:[CHEMINANT.NFS]
      A.TYP;1                10926/0
                                   ~~~
    
     Are you aware of this bug ?
     regards.
     Gait.
5168.3with a success message ...!PRSSOS::CHEMINANTThu Jan 30 1997 12:1116
    
    $ ucx sh version
      DEC TCP/IP Services for OpenVMS VAX Version V4.0 - ECO Level 4
      on a MicroVAX 3900 Series running OpenVMS V6.2
    
    $ copy/log DISK$USERS:[CHEMINANT]UCXVAX_E2040.B;1 DNFS1:[NFS]a.typ
    HALLES::CHEMINANT 18:00:34 COPY      CPU=00:00:04.50 PF=1939 IO=433
    MEM=645
    %COPY-S-COPIED, DISK$USERS:[CHEMINANT]UCXVAX_E2040.B;1 copied to
    DNFS1:[NFS]A.TYP;1 (10926 blocks)
    
    $ dir/siz=all DNFS1:[NFS]a.typ
    Directory DNFS1:[NFS]                           
    A.TYP;1                    0/0
    Total of 1 file, 0/0 blocks.
5168.4LASSIE::CORENZWITstuck in postcrypt queueThu Jan 30 1997 13:503
    Better IPMT it then.  Include a reference to this note number.
    
    Julie