home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!noc.near.net!inmet!bu.edu!decwrl!elroy.jpl.nasa.gov!nntp-server.caltech.edu!eql.caltech.edu!rankin
- From: rankin@eql.caltech.edu (Pat Rankin)
- Newsgroups: vmsnet.vms-posix
- Subject: Re: strange posix timing bevavior
- Message-ID: <10NOV199219584662@eql.caltech.edu>
- Date: 11 Nov 92 02:58:00 GMT
- References: <1992Oct31.003920.17824@wega.rz.uni-ulm.de> <2TN8ZVH@gwdu03.gwdg.de>
- Organization: California Institute of Technology
- Lines: 24
- NNTP-Posting-Host: eql.caltech.edu
- News-Software: VAX/VMS VNEWS 1.41
-
- In article <2TN8ZVH@gwdu03.gwdg.de>, moeller@gwdgv1.gwdg.de writes...
- [...]
- > I guess this problem is not particular to POSIX:
- >
- > The VAXC I/O library has always been famous for doing very inefficient
- > I/O to disk, spending 1 I/O per disk block read or written.
-
- VMS POSIX does not use VAXCRTL at all; it has an entirely separate
- C run-time library. However since the POSIX command itself executes
- from the regular VMS environment (from DCL that is), _it_ might be using
- VAXCRTL. POSIX$RUN.EXE is not linked to shareable VAXCRTL, but could be
- linked with the object library instead. The point is moot if it doesn't
- use C I/O to write to SYS$OUTPUT.
-
- How about testing a third case for additional comparison?
- $!test3.com
- $! ignore SYS$OUTPUT
- $ posix posix$bin:uuencode. "test.gif test.gif >test.uue
- $ logout/full
- This one would presumeably end up going through the UCX NFS I/O subsystem,
- so may be slow too. On the other hand, NFS probably uses substantial
- buffering to cut down on actual I/O.
-
- Pat Rankin, rankin@eql.caltech.edu
-