mo@seismo.CSS.GOV (Mike O'Dell) (07/16/87)
Someone reported that A/UX on the Mac II only gets about 50 KBytes/second out of its disk and wondered why. He also suggested the cause in his list of possibles: The System V Filesystem Shucks, folks, I've got a SysV machine with 4 12.5 Megahertz 68000's with Eagle disk drives that only gets 50 KBytes/second through the filesystem. That's only 1/6th the speed I get out of a SUN 3/160 with two ST506 drives on an Emulex SCSI controller (measured at 250 to 300 KBytes per second). Anyway, take heart folks - V6 used a 512 byte transfer size and could get only about 25 KBytes/second. System V with its 1 KByte transfer size gets 50 K - that's a 100% improvement. Yours for more amazing technology, -Mike O'Dell PS - "System V - Consider It Standard."
howard@amdahl.amdahl.com (The Toolmaster) (07/16/87)
In article <44025@beno.seismo.CSS.GOV> mo@seismo.CSS.GOV (Mike O'Dell) writes: > >Shucks, folks, I've got a SysV machine with 4 12.5 Megahertz 68000's >with Eagle disk drives that only gets 50 KBytes/second through >the filesystem. Shucks, folks, I wanted to post the transfer rate for my SysV machine but time just doesn't have the resolution to handle "cat /usr/dict/all >/dev/null" It just keeps coming back with zero. >That's only 1/6th the speed I get out of a SUN 3/160 with two >ST506 drives on an Emulex SCSI controller (measured at 250 to >300 KBytes per second). Oh, I should say my machine is an Amdahl 5890 running two processors, with your standard channel attached 6380E disk drives. >Anyway, take heart folks - V6 used a 512 byte transfer size and >could get only about 25 KBytes/second. System V with its 1 KByte >transfer size gets 50 K - that's a 100% improvement. And UTS uses 4K blocks, for an infinite improvement :-) > Yours for more amazing technology, > -Mike O'Dell But I still prefer the amazing technology on my desk, a MacSE. UTS makes a great backend though. >PS - "System V - Consider It Standard." PS - BSD4.x - Consider it Adhoc. -- "Plan for the future because that's where you Howard C. Simonson are going to spend the rest of your life." {hplabs,ihnp4,nsc}!amdahl!howard - Mark Twain - [ The disclaimer for this message may be found in my next article ]
lad@eplrx7.UUCP (Lawrence Dziegielewski) (07/17/87)
In article <10252@amdahl.amdahl.com>, howard@amdahl.amdahl.com (The Toolmaster) writes: > > >PS - "System V - Consider It Standard." > > PS - BSD4.x - Consider it Adhoc. > > -- I do not consider Sys V a standard. In engineering, 4.x is the standard. We here at the Engineering Physics Lab have one Motorola machine running Sys V, and it's a real bear working on it after I've been using my bsd 4.3 system from Mt Xinu all day. Just an opinion. Lawrence A. Dziegielewski E.I. DuPont Co. (302) 695-1311 EPL - ENGG ...dgis!eplrx7!lad Wilmington, DE 19898 >
julian@riacs.edu (Julian E Gomez) (07/22/87)
In article <443@eplrx7.UUCP> lad@eplrx7.UUCP (Lawrence Dziegielewski) writes: : In article <10252@amdahl.amdahl.com>, howard@amdahl.amdahl.com (The Toolmaster) writes: : > >PS - "System V - Consider It Standard." : > PS - BSD4.x - Consider it Adhoc. : : I do not consider Sys V a standard. In engineering, 4.x is the standard. : We here at the Engineering Physics Lab have one Motorola machine running Sys : V, and it's a real bear working on it after I've been using my bsd 4.3 : system from Mt Xinu all day. I don't consider it a standard either. Nor do most universities and research institutions. SYS V lacks too many useful features that 4.x supports as standard. "Enhanced" versions are only slightly better. It qualifies more as "ad hoc" than 4.xBSD, especially since they've had so many years to study and learn from a good example. AT&T can start by supporting control-Z and signal(SIGSTOP... and signal(SIGCONT..., which are much more useful to me for development than shared memory. -- Scientists will study your brain to learn more about your distant cousin, Man. Julian "a tribble took it" Gomez julian@riacs.edu || {...decvax!}ames!riacs!juliant
tim@hoptoad.uucp (Tim Maroney) (07/23/87)
A/UX runs on top of the Mac OS. If the UNIX file system is not "real UNIX"
but merely a front-end to the Mac HFS software, then the single-threaded
nature of HFS could be expecvted to present extreme performance obstacles,
since only one process's file system request can get serviced at once, and
the rest are sleeping. I don't have an A/UX to play with, but if it runs
Mac disks, then it is almost surely not a real UNIX file system.
--
Tim Maroney, {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)rpd@apple.UUCP (Rick Daley) (07/23/87)
In article <2495@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > A/UX runs on top of the Mac OS. If the UNIX file system is not "real UNIX" > but merely a front-end to the Mac HFS software, then the single-threaded > nature of HFS could be expecvted to present extreme performance obstacles, > since only one process's file system request can get serviced at once, and > the rest are sleeping. NO! NO! NO! A/UX does NOT run on top of the Mac OS. It is a "real UNIX" and uses a "real UNIX" file system. A/UX is based on System V.2 with extensions from V.3 and BSD 4.[23]. The file system is System V. Performance problems in the A/UX file system stem from three problems: 1) The software needs tuning. A/UX is still pre-release and we have been more concerned with completeness and robustness than tuning. We have been doing work in that area, but none of the beta sites have seen the results. 2) The file system is System V style, not the Berkely "fast file system." I, for one, hope that the fast file system will be an option in future releases of A/UX, but it will not be so for the first release. The fast file system yields better performance and supports long file names. 3) The Mac II does not have any DMA hardware. This does not hurt the native Mac OS too badly as long as only one process is really active at a time. It is very rare for a Mac program to do anything during a read but wait for the read to complete. Therefore, it doesn't matter if the CPU has to move the bytes itself. This lack of DMA hardware means that disk I/O will always be a weak point of A/UX performance on a Mac II. Since I spend my days (and nights) working on the A/UX Toolbox, I'd like to think Tim got confused when he saw a demo of A/UX looking and feeling like a Macintosh. However, this is the Macintosh Toolbox running on top of A/UX, not the other way around. Rick Daley rpd@apple
jww@sdcsvax.UCSD.EDU (Joel West) (07/23/87)
In article <2495@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > A/UX runs on top of the Mac OS. If the UNIX file system is not "real UNIX" > but merely a front-end to the Mac HFS software This is a common misconception. Actually, A/UX junks the Mac OS. The file system is by Unisoft from AT&T and BSD. The current mount command recognizes V.2 and 4.3 file systems, and the default seems to be V.2. As for HFS, unless I'm mistaken, there is no way currently to read or write HFS disks, so it certainly isn't layered. You couldn't use the old OS anyway, since it is not multi-tasking, re-entrant, and uses the Macintosh Memory Manager instead of malloc and memory mapped by the 68851. Someone who's read the manuals... -- Joel West, Palomar Software, Inc. (c/o UCSD) {ucbvax,ihnp4}!sdcsvax!jww or jww@sdcsvax.ucsd.edu
fnf@mcdsun.UUCP (Fred Fish) (07/23/87)
In article <2495@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >A/UX runs on top of the Mac OS. If the UNIX file system is not "real UNIX" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Just to nip any misconception in the bud, this is simply not true unless things have changed drastically in the last year. >the rest are sleeping. I don't have an A/UX to play with, but if it runs ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ah ha, that accounts for your confusion... :-) -Fred -- = Drug tests; just say *NO*! = Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA = seismo!noao!mcdsun!fnf (602) 438-3614
mark@rtech.UUCP (Mark Wittenberg) (07/24/87)
From article <2495@hoptoad.uucp>, by tim@hoptoad.uucp (Tim Maroney): > A/UX runs on top of the Mac OS. If the UNIX file system is not "real UNIX" > but merely a front-end to the Mac HFS software, then the single-threaded > nature of HFS could be expecvted to present extreme performance obstacles, > since only one process's file system request can get serviced at once, and > the rest are sleeping. I don't have an A/UX to play with, but if it runs > Mac disks, then it is almost surely not a real UNIX file system. > -- > Tim Maroney, {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp) > hoptoad!tim@lll-crg (arpa) A/UX doesn't run on top of the Mac OS, and uses UNIX file systems, not HFS or MFS. There may be utilities to read those disks, but A/UX doesn't recognize them as filesystems. You're right, a single-threaded UNIX filesystem would have disastrously poor performance. -- Mark Wittenberg Relational Technology, Inc. Alameda, CA ihnp4!zehntel!rtech!mark or ucbvax!mtxinu!rtech!mark
elwell%tut.cis.ohio-state.edu@osu-eddie.UUCP (Clayton Elwell) (07/24/87)
In article <2495@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >A/UX runs on top of the Mac OS. Wrongo. A/UX runs *instead* of the Mac OS. If the UNIX file system is not "real UNIX" >but merely a front-end to the Mac HFS software, then the single-threaded >nature of HFS could be expecvted to present extreme performance obstacles, >since only one process's file system request can get serviced at once, and >the rest are sleeping. I don't have an A/UX to play with, but if it runs >Mac disks, then it is almost surely not a real UNIX file system. >-- >Tim Maroney, {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp) >hoptoad!tim@lll-crg (arpa) Actually, the Mac emulation mode (which was basically a by-product of the A/UX toolbox) translates HFS calls into the appropriate UNIX calls. There is a little utility that will gleep things off of Mac disks (only MFS last I checked, though). A/UX is UNIX. The A/UX toolbox with a little tweaking is amost the Mac OS. -=- Clayton Elwell Arpa/CSNet: Elwell@Ohio-State.ARPA UUCP: ...!cbosgd!osu-eddie!elwell Voice: (614) 292-6546
rpd@apple.UUCP (Rick Daley) (07/24/87)
In article <1353@apple.UUCP>, rpd@apple.UUCP (Rick Daley) writes: > ... A/UX is based on System V.2 with > extensions from V.3 and BSD 4.[23]. ... In my best Steve Martin impression, "I was WRONG!" A/UX does not include any enhancements from System V.3. When I said this, I was thinking about System V streams, but it turns out that A/UX streams are based on V.2.1, not V.3. The difference may seem insignificant, but there are some nasty licensing issues. Oops. I'm told that streams from V.2.1 are a functional subset of streams from V.3 and contain nearly all of the functionality of V.3 streams. Obviously, I have had nothing to do with that end of A/UX. My efforts have been concentrated on the A/UX Toolbox.
lad@eplrx7.UUCP (Lawrence Dziegielewski) (07/24/87)
In article <1353@apple.UUCP>, rpd@apple.UUCP (Rick Daley) writes: > NO! NO! NO! A/UX does NOT run on top of the Mac OS. It is a "real UNIX" > and uses a "real UNIX" file system. A/UX is based on System V.2 with Oh please. Rick, is there any chance a developer ( like myself ) could get his hands on AU/X to explore the possibility of porting a 'Real Unix (bsd 4.3) to the II? > 2) The file system is System V style, not the Berkely "fast file system." > I, for one, hope that the fast file system will be an option in future > releases of A/UX, but it will not be so for the first release. The fast file > system yields better performance and supports long file names. Amen. Implementing the FFS under AU/X would be a real plus. (no pun intended). > move the bytes itself. This lack of DMA hardware means that disk I/O will > always be a weak point of A/UX performance on a Mac II. How's about an ESDI disk interface for the II? lad@eplrx7 (302) 695-1311 "With every mistake, we must surely be learning...." - George Harrison
gardner@prls.UUCP (Robert Gardner) (07/24/87)
In article <1353@apple.UUCP> rpd@apple.UUCP (Rick Daley) writes: >NO! NO! NO! A/UX does NOT run on top of the Mac OS. It is a "real UNIX" >and uses a "real UNIX" file system. Can A/UX read/write Mac OS files and vice-versa? I understand that currently you need to reboot in order to switch from A/UX to Mac OS and vice-versa. Roberdo trstyM>
tim@hoptoad.uucp (Tim Maroney) (07/28/87)
In article <1353@apple.UUCP> rpd@apple.UUCP (Rick Daley) writes: >Since I spend my days (and nights) working on the A/UX Toolbox, I'd like to >think Tim got confused when he saw a demo of A/UX looking and feeling like a >Macintosh. However, this is the Macintosh Toolbox running on top of A/UX, >not the other way around. > Rick Daley > rpd@apple I accept this as true, however I feel I should note that the information I originally conveyed was straight from Apple's mouth: to be precise, it was stated explicitly at a MacSEF meeting in Apple corporate headquarters earlier this year, in response to a question concerning compatibility between Mac software and Apple's UNIX. I was not in the least confused - I was simply told the wrong facts by people who were in the know. Perhaps the design has changed since? Or perhaps it was simply a case of the wrong person answering a question? Regardless, I merely wanted to show that I am quite aware of the need for standards of evidence in my postings, and that the source I used *should* have been a reliable one. -- Tim Maroney, {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp) hoptoad!tim@lll-crg (arpa)