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

Conference hydra::axp-developer

Title:	Alpha Developer Support
Notice:	[email protected], 800-332-4786
Moderator:	HYDRA::SYSTEM

Created:	Mon Jun 06 1994
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3722
Total number of notes:	11359

3410.0. "Nectar Systems AB - Point 24201" by RDGENG::ASAP () Thu Mar 27 1997 05:03

    Company Name :  Nectar Systems AB - Point 24201
    Contact Name :  Mats Nilsson
    Phone        :  +46 (0)451 893 00
    Fax          :  +46 (0)451 817 30
    Email        :  [email protected]
    Date/Time in :  27-MAR-1997 10:03:29
    Entered by   :  Simon Cole
    SPE center   :  REO

    Category     :  vms
    OS Version   :  
    System H/W   :  


    Brief Description of Problem:
    -----------------------------

From:	ESSB::ESSB::MRGATE::"ILO::ESSC::santing"   26-MAR-1997 13:54:36.59
To:	RDGENG::ASAP
CC:	
Subj:	ESCALATION: POINT  24201, Nectar Systems AB

From:	NAME: ESCTECH@ILO            
	TEL: (822-)6704            
	ADDR: ILO                    <santing@ESSC@ILO>
To:	ASAP@RDGENG@MRGATE


Hello - 

POINT Log Number	 24201

Company Name 	Nectar Systems AB

Engineers name	Mats Nilsson

Telephone Number 		+46 (0)451 893 00

Fax Number		+46 (0)451 817 30

E-mail Address	[email protected]

Operating System, Version	OpenVMS 7.0
 
Platform			Alpha

Problem Statement		

In an Alpha with Open VMS 7.0 i do a sequesial read on an ordinary file
from a C-program as:

cc=read(ch,buf,rs);

I read 250 blocks of 802 bytes and it takes about 15 seconds

In VAX with OpenVMS 6.2 it takes about 3 sec.

and in a Unix environment (not Digital Unix because I can cot test it
there) it takes under 1 sec.

Are the anything I can do to increase perfornace to speeding up file read
and writes, because the system is very slow and we do a lot of random
accesses to files like above, by doing a lseek and then read a block.

Can shared libraries increase performans or does it only decrease the
program size?

Best Regards

Mats

+----------------------------------------------+
!                                              !
!    oooooo     ooooo  Nectar Systems AB       !
!    ooooooo    ooooo  Mats Nilsson            !
!      oooooo   ooo    Development Manager     !
!      ooooooo  ooo    [email protected]           !
!      ooo oooo ooo    Box 124                 !
!      ooo  ooooooo    S-281 22 H_ssleholm     !
!    ooooo   oooooooo  Tel. +46 (0)451 893 00  !
!    ooooo    ooooooo  Fax. +46 (0)451 817 30  !
!                                              !
! -For excellence in 4GL-                      !
!                                              !
+----------------------- http://www.nectar.se -+
Thanks,

Ben


		   QED Qualitas Est Demonstrandum
		   ==============================
Ben Santing, Technical Consultant		Phone:  DTN 822 4330
European Customer Service Centre		Phone:  DTN 822 4269
Digital Equipment International B.V.		FAX:    DTN 822 4445

	     In replying, please use [email protected]

T.R	Title	User	Personal Name	Date	Lines
3410.1		HYDRA::AXPDEVELOPER	Alpha Developer support	`Thu Mar 27 1997 09:21`	28
	From: HYDRA::AXPDEVELOPER "[email protected]" 27-MAR-1997 09:20:54.60 To: [email protected] CC: AXPDEVELOPER Subj: sequential read on OpenVMS Alpha V7.0 Mats, I need more information. There are several variables for i/o performance. One is the hardware configuration. What model of Alpha computer are you testing and what disk devices? OpenVMS uses RMS to do file i/o. You should examine the RMS buffer counts using $ SHOW RMS_DEFAULT and possibly experiment with values for multibuffers $ SET RMS_DEFAULT/BLOCK_COUNT=nnn You could skip RMS and write OpenVMS $QIO routines to do the I/O. This would give you the best possible performance. The file format is quite important. A file with stream_lf is best for performance. $ DIR/FULL <filename.ext> What does the open statement look like? On OpenVMS, if you allow file sharing, performance will be affected. Thank you, Mark Schafer Alpha Developer Support
3410.2	sequential read on OpenVMS Alpha V7.0; further infor from netcar	HYDRA::AXPDEVELOPER	Alpha Developer support	`Wed Apr 02 1997 11:01`	104
	Subject: sequential read on OpenVMS Alpha V7.0 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Reply to the message of Thursday March 27, 1997 14:22 +0100 ----------------------------------------------------------------- Hello >I need more information. There are several variables for i/o >performance. One is the hardware configuration. What model of Alpha >computer are you testing and what disk devices? It is a Alpha 200 4/100 and the disk is device type HP C3724S, a small maschine, but I am alone in it. >OpenVMS uses RMS to do file i/o. You should examine the RMS buffer >counts using $ SHOW RMS_DEFAULT and possibly experiment with values for >multibuffers $ SET RMS_DEFAULT/BLOCK_COUNT=3Dnnn This are the default values: Necutv>show rms_default MULTI- \| MULTIBUFFER COUNTS \| NETWORK BLOCK \| Indexed Relative Sequential \| BLOCK COUNT \| Disk Magtape Unit Record \| COUNT Process 0 \| 0 0 0 0 0 \| = 0 System 16 \| 0 0 0 0 0 \| = 8 Prolog Extend Quantity Process 0 0 System 0 0 I have increased BLOCK_COUNT to 32 and also set up BUFFER_COUNT to 32 and i makes no difference when I am alone in the system. >You could skip RMS and write OpenVMS $QIO routines to do the I/O. >This would give you the best possible performance. Do you know of anybody who has written all C-I/O-functions like open,lseek,read and write with QIQ, and are the fileformats compatible with the standard C I/O-functions ? >The file format is quite important. A file with stream_lf is best for >performance. $ DIR/FULL <filename.ext> Necutv>dir/full zntref.dat Directory NEC:<NECTAR.DAT> ZNTREF.DAT;1 File ID: (2543,1,0) Size: 394/411 Owner: [SG,NECUTV] Created: 3-JAN-1997 13:54:38.51 Revised: 2-APR-1997 09:26:37.67 (1889) Expires: <None specified> Backup: <No backup recorded> Effective: <None specified> Recording: <None specified> File organization: Sequential Shelved state: Online File attributes: Allocation: 411, Extend: 0, Global buffer count: 0 No version limit Record format: Stream_LF, maximum 0 bytes, longest 32767 bytes Record attributes: Carriage return carriage control RMS attributes: File statistics enabled Journaling enabled: None File protection: System:RWD, Owner:RWD, Group:R, World: Total of 1 file, 394/411 blocks. >What does the open statement look like? On OpenVMS, if you allow file >sharing, performance will be affected. I have read some reports from net of I/O performance, and tried to conver= t the file to inhibit file defragmentation but this file is record oriented (no LF's) so I get the following when I try Necutv>convert zntref.dat zntref.new %CONVERT-I-RTL, record longer than maximum record length %CONVERT-I-RSZ, invalid record size Today we have installed OpenVMS 7.1 and that was a positiv surprise, the file I/O handling increased about five times. Best regards Mats +----------------------------------------------+ ! ! ! oooooo ooooo Nectar Systems AB ! ! ooooooo ooooo Mats Nilsson ! ! oooooo ooo Development Manager ! ! ooooooo ooo [email protected] ! ! ooo oooo ooo Box 124 ! ! ooo ooooooo S-281 22 H=E4ssleholm ! ! ooooo oooooooo Tel. +46 (0)451 893 00 ! ! ooooo ooooooo Fax. +46 (0)451 817 30 ! ! ! ! -For excellence in 4GL- ! ! ! +----------------------- http://www.nectar.se -+