Xenix 386 2.3.2gt problems

Jay Curtis jcurtis at baron.uucp
Wed Mar 27 17:45:13 AEST 1991


Hi.  A while back I posted a plea for help concerning disk throughput
on a 33 MHz 386/Adaptec 1542b/Wren V machine.  This morning I
reinstalled the same software on a 25 MHz 486 with a Compuadd caching
ESDI controller and 90 Meg ESDI drive.  After installation, I ran
iobench2 and the Byte benchmark tests on this configuration.  I saw
only 120.3 Kbps disk throughput.  Here are all the particulars again
for both systems:

1)
	33 MHz 386 w/387, 64 K cache, 8 Meg Ram, 8 MHz bus speed
	Adaptec 1542B default configuration, ASYNC mode
	Imprimis Wren V 330 Meg SCSI drive, Read ahead cache enabled
	Digiboard Com8/i
	EGA card and Monitor
	SCO Xenix 386 2.3.3 with sls252b installed

	120 Kbps disk throughput

Disk was formated at a 1:1 interleave.  (I also tried 2-16:1
interleaes.  The highest throughput was at 9:1 with 184Kbps. 8-( )

Adaptec passed the bios DMA tests at 5.0, 5.7, and 8.0 M xfer rates.

2)
	25 MHz 486 w/64 K cache/8 Meg Ram/8 MHz bus speed
	Compuadd caching ESDI controller w/4 Meg Ram
	Seagate 90 Meg ESDI drive, 1:1 interleave
	mono monitor
	SCO Xenix 2.3.3gt 

	120 Kbps disk throughput

I tried with the cache on the controller enabled and disabled.  No
change.  

I have friends running Xenix 386 2.3.3AT getting much faster
disk transfer rates on similar equipment.  Is there a problem with the
early copies of the gt release?  My serial number is sco000360.
Anyone seen similar problems in the past?  The hardware is not to
blame in either case as I loaded dos on both machines and ran
coretest.  800 Kbps on the SCSI and 745 on the ESDI drive.

Could someone from SCO **PLEASE** help me?  I feel like I am beating
my head against a wall with the local SCO rep.  (Can you say "not real
swift!" ?)  My thirty days free support is long up but the problem has
existed from day one with this software.  Is there any way to get
assistance without having to purchase a support contract?  We have
done everything possible to elliminate the hardware as a source of
trouble before contacting SCO.  Now that I know the software is at
fault, what can I do to correct the situation?

--Jay
-- 
Jay Curtis  
jcurtis at baron.UUCP	
{nosc;ncr-sd;crash;}!baron!jcurtis
Of course my opinions are my own... Who would let me speak for them?!



More information about the Comp.unix.sysv386 mailing list