VPix & Dos partition (Was: Simple database software for sysV?)

[Thomas Hoberg]

In article <88612 at unix.cis.pitt.edu>, erast1 at unix.cis.pitt.edu (Evan R
Aussenberg) writes:
|> In article <1991Feb07.011850.19550 at chinet.chi.il.us> les at chinet.chi.il.us
|> (Leslie Mikesell) writes:
|> 
|> |[I say]:
|> | >writing [ with VPix & ISC ] to our Micropolis 320meg scsi is
|> | >noticably slower than if I access the DOS partition via native DOS...
|> 
|> | >For your reference, the computer is an Intel model 302, 25mhz, 8meg.
|> 
|> |On mine, there is only a slight difference, but I'm running a Conner
|> |IDE drive which has on-board buffering.  Perhaps you are close to
|> |missing the interleave on the disk and the overhead of VP/ix is
|> |enough to miss and require another disk revolution.
|> 
|> |Les Mikesell
|> |les at chinet.chi.il.us
|> 
|> The Micropolis we have is a voice coil hd with on-board cache as
|> well.  The interleave of the whole drive is 1:1 because our adaptec
|> scsi board supports it.  It may well be that the drive is too fast
|> at 1:1 for VPix.  I don't think you can change the interleave of 
|> a partition?
I did once on an MFM drive. 2:1 was ideal for DOS, but Micoport Unix 286 was
too slow for that. So I wrote a small Turbo Pascal program and reformatted the
Unix partition 3:1. Once Microport added RLL support, an Adaptec 2372 made it
at 1:1. I don't think you can and in any case you wouldn't want to do that on
a SCSI drive.
|> 
|> The slowdown is typically in the writing.  Reading the DOS partition
|> under VPix is at least as fast as naitive DOS.
|> 
I don't think it's interleaving but ISC's super careful approach to writing
on a DOS file system. It's not a VPIX problem but a DOS-file-system problem
as writing times deteriorate just as badly when the writing is done via Unix.
VPIX talks to Unix for all file i/o and cannot tell a DOS partition from a 
Unix file system.
I had planned to back up my DOS partitions under UNIX with a streamer. Backing
up is no problem, but the restores are too slow to be useful.
I believe that ISC immediately writes back any changes to the FAT and all data
blocks. This incurrs lots of seeks for every data block written and causes 
write rates to drop below floppy values.
Since changing this behavior for the DOS file system seems to be a major effort
the only solution here is to use the Unix file system even under VPIX, but then
some people need to use native DOS on their data, too...
|> On a semi-related note.  The adaptec 154xB scsi board we have supports
|> synchronous data transfers to/from its peripherals.  The Mircropolis
|> drive has a jumper which puts it in "synchronous mode" if available
|> (that's the best I gather from the docs).  Is there any way to know
|> for sure that the two are talking synchronously?
|> 
Roy Neese's SCSI tools will tell you. For me sync vs. async changed the
performance from 1295KB/s to 1300KB/s, so it's not really worth it. You should
not set the sync mode on both the Adaptec and the drive as least if the 'sync'
jumper on the drive means 'negociate for sync mode' rather than 'enable sync
mode'. That would cause conflicts.
|> Also, how high has anyone set the transfer rate on the adaptec board.
|> From memory, I think I put the shunt on the 6.x transfer rate.
|> (It goes to 10ish I think).
|> 
According to what I remember from one of Roy's comments, 6.7 MB is considered
ideal. By the way, the best tool I found to measure the effects of all that
jumpering and bus tuning is called 'bonnie'. I am quite happy to be faster in
all cases than a Sparc 470...
|> 
|> Evan
|> -- 
|> Evan Ron Aussenberg
|> erast1 at unix.cis.pitt.edu
|> IN%"erast1 at pittunix"
--tom
----
Thomas M. Hoberg   | UUCP: tmh at bigfoot.first.gmd.de  or  tmh%gmdtub at tub.UUCP
c/o GMD Berlin     |       ...!unido!tub!gmdtub!tmh (Europe) or
D-1000 Berlin 12   |       ...!unido!tub!tmh
Hardenbergplatz 2  |       ...!pyramid!tub!tmh (World)
Germany            | BITNET: tmh%DB0TUI6.BITNET at DB0TUI11 or
+49-30-254 99 160  |         tmh at tub.BITNET