HDTenEightyP/NetNews huggingface dataset:
From: cng@poietics.UUCP (Chris Gayler)
Newsgroups: biz.sco.general
Subject: Re: Performance issues revisited
Date: 23 Dec 92 13:10:26 GMT
Reply-To: cng@poietics.UUCP (Chris Gayler)
Organization: POIETICS

In article <Duw8VB10w165w@zswamp.UUCP> geoff@zswamp.UUCP (Geoffrey Welsh) writes:
>sheldon@iastate.edu (Steve Sheldon) writes:
>
>>   time dd if=/dev/rhd0a of=/dev/null bs=131072 count=128
>
>   I know that the DMA controllers on PC-compatibles can't do a transfer of 
>more than 64K in a go.  In theory, the Adaptec (models 154x, 164x, 174x) need 
>not be limited by this, thanks to bus master DMA.  Does anyone know the size 
>limit for a single DMA burst from these devices?
>
>>  I'm curious if perhaps the configuration you have just doesn't like the
>> smaller block size.  I suppose it might be possible...
>
>   In my own experiments while constructing a count-oriented (for maximum 
>performance) yet time-regulated disk benchmark, I found that throughput 
>increases logarithmically with block size. (note: not exponentially; I mean 
>approaching the maximum, with each increment in block size having less effect 
>than the last.)  I ended up using 60K blocks, because they gave pretty much 
>the same figures as 63K blocks.  Some systems gave very low figures when 64K 
>block sizes are used, but others did not; I do not understand that 
>observation. 
>


Just to add more datapoints, I ran these tests against various controllers:

  time dd if=/dev/rhd0a of=/dev/null bs=2048 count=8196
  time dd if=/dev/rhd0a of=/dev/null bs=65536 count=256

Results (real times in seconds)
2048  65536 (Block sizes)

20    --        486/50 with Mylex DCE376 SCSI caching controller, SCO 3.2.4
                       Newer Maxtor disks.

33    10.6      486/50 with Adaptec 1740 SCSI, SCO 3.2.4, older Maxtors

34    33.9      386/25 with WD1007 ESDI controller, SCO 3.2.2

37    10.1      486/33 with Adaptec 1542 SCSI, fast Fujitsu disks, SCO 3.2.4

39    23.9      386/25 with UltraStor 12F ESDI controller, SCO 3.2.2

39    13.3      386/33 with Adaptec 1542 SCSI, fast Fujitsu disks, SCO 3.2.4


To summarize, SCSI and ESDI controllers have comparable performance on small
block sizes, but SCSI steps way out on larger block sizes. The exception is
the Mylex, which likely has the best performance on both ends (I didn't have 
access to the Mylex to run the large block test.) For the 1542, the mem=/L
boot option yielded about an 8% improvement on the 2048 test.

The downside is that the Mylex will bite you on installation time.  :-E 

Chris

Xref: sparky biz.sco.general:4812 comp.unix.xenix.sco:3536
From: jim@tiamat.fsc.com ( IT Manager)
Newsgroups: biz.sco.general,comp.unix.xenix.sco
Subject: Re: X-Windows Sources for 3.2.4
Date: 23 Dec 92 13:34:44 GMT
Followup-To: biz.sco.general
Organization: Ahlstrom Filtration - Chattanooga,TN

In article <1992Dec20.211009.12388@blkbox>, mknewman@blkbox (Marc Kraker Newman) writes:
> crouland@gmuvax2.gmu.edu (DES Cracker) writes:
> 
> 
> >Does anyone know where I can find full blown X11 for SCO Unix 3.2.4
> >running on a 386? Binaries preferred.
> 
> You could always upgrade to ODT 2.0.

Or, send mail to "sales@metrolink.com".  MetroLink sells X11 software
(current version X11R5) which runs on SCO Unix and ODT.  Their servers
are very good, they ship alot of clients in the default package, their
Dev. Sys. is very good, includes a copy of GCC and imake, and has
proved able to compile any X11 clients that I've tried.

We even put Metro's X11 onto ODT boxes, and then remove any native ODT
clients that are duplicated by the Metro package.  The few ODT X
clients that are left are actually quite useful.  On 3.2v4.0-based
systems and up it's pretty easy to use symbolic links to merge the
native ODT stuff into the Metro X tree and you end up with a really
nice system.

Also, Ready-to-Run software sells a binary package of X11R5 for SCO
Unix.  We bought a few of their other ReadyPaks and the quality is
pretty good.  RTR's price is probably a little lower than Metro's, but
Metro's is probably a more technically advanced product.

Unless you're using X11 "casually" it would be worth it to pay one of
these guys for their X11 package (in the neighboorhood of $300).
You'll get good, professional, support and access to updates.

Later.



------------- 
James B. O'Connor                                     jim@tiamat.fsc.com
Information Technology Manager                        voice 615/821-4022 x651
Ahlstrom Filtration, Inc.                             fax   615/821-0616
Newsgroups: biz.sco.general
From: logica@lascar.puc.cl (Claudio Lopez)
Subject: SCO UNIX 3.2.4 spooler pager
Keywords: SCO spool pages
Organization: Logica S.A.
Date: Tue, 29 Dec 1992 12:44:42 GMT

I need to implement the capability of recovering a spooler job from a fail 
or from a hold, but resuming from a specified page. I was reading that this 
works if you have the right filter program, but the standard filter program 
does not come with this feature.

I need to know if someone knows of some filter program that implement this, 
for a proprinter, or any standard printer.

Also I need to know how to submit a job, having it printed, but letting a 
copy of the job hold in the queue.

I would appreciate any help on this.

Regards
Claudio Lopez 
LOGICA S.A.
From: belal@sco.COM (Bela Lubkin)
Newsgroups: biz.sco.general
Subject: ev_open(S), Re: Logitech C9 Serial Mouse at 9600 Baud
Date: 1 Jan 93 01:34:03 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

Whoops, forgot to include that man page!  >Bela<

begin 600 ev_open.S.Z
M'YV0"A2 *&/GRQLX9=R@F)("A,.'$"-&C $#!)$R8\JT$5-&#H@8.7+$D$B2
M)$&#"!4R# CB"P(G+L.X;..R#,N')P\F!-$"A$XW<T"$<3/03D(Z(.+4*;,4
MA)DW'M.X@5.'#DN74USF<>G&)9V8+O'<=#@&P9BR8T"X0.!B;5NV/!&T8(. 
M31D$!!$8Q>L&@1LZ"*P*?#@"P8@T"*3Z14N731T$=<@@('.WC$,>"'C,03 G
M#X(\F^>\0/ ",!W/>> @0(@WM%LT"-#X0.!CL,/"AQ/W=<.X[N/(DRM?SAP:
M=>C1+U3#"8,@C!P$<IB':8.@S>O8LVM#Q(U8,6^SC7]+IHQWN&;.QCDC+_XY
M-/4VTM$^E_,&P1O7;&'+IFT;!'?=BX'G&V3C"0<"9N=UUIYZI"DGW1D(G%'9
M=?MI1YAAW>W6FV,$!E?>@<2AMZ!HI%5FAUZ5[68:A=GU]Y]W&XKGH64@\O!>
M?6_\%MJ$^6''7W\9^F7:0'B=6! "!MFG7(I^@8 " BB,]YYTH:V!P!HI()!"
M?U)61R5G5J[ATA=#JH" "EW"UUR55RJW P([7(4 $36Y-(=+8[@DATMIN 2'
M5WRZ] 978Q&9UY%)'K0:DT3]%-1011V5U%)-/1755%6Y  (5:%CFW!EUM"$I
M'&](14=0=+PA% ABI$$'?'.LT=\;9H! F1UI9 3":0C-H:F)>HV)XY)\-1D&
M'72$,4:GC]H11AILA"&&7;82E&L90=V!QGV6C1'M'$&E$12L:Y1!!I!N:&JH
MD<(JN6BQ1)D!+1OA$D5'IR"0NZNJ4I&1Z[&6:7LL"&OT&Q2MU>*:4;A6022O
M&V3X6BBGEK7Z:ABQ@B!NOF%0YE.M;[AA&53Y0C5RK4_5X9&W&,^![<<)7^NK
M0Q0[E:,<_;$,[LO.64;$G&-.@< 45"! A10(2)$$ DDX\=(1"!S! @(L6 0T
MDDA+400"13"! !-35_TSG4@&@4 00B @A-!3A.V31V./^00"3Q1-!1(((+%U
M$5FK&S>2;-N=]=)-/QTU"'*4849'J*JZK',M]*<L'1V!, <=B4\7\\(@L)%&
MN;OB6VX>8KSA'!F:_OU%UGM[S03BBC.^+^S1TI&&49V_,<:Q4'%I+>>>@][&
MM:E?_879:*O--NR+R]&X4&+,\89CE.>^>ZH>W2ISYY]7[.IR$;O0'\4N@^"L
M8SPG7NW#YFI,% \S">I2'7;6Y()+LHG?'["(#OMN0L9"ED;@<*K9_61S+T/8
MO2S#JY?UZU^4(X/[0N<I.8!*5'^1',0L5X8"+I!C&4N5^_QU/0;B2WN<FT,=
MSH*M.9BA#FQ@0QY\DA)S:2H)M7*#JB@3.8@H[&6[(PI'++?"A;D0AC*D84+,
M537^M4M1K $@41)'!Y4!A2<CP9A0B-(1^JPL9/[JX4-L%S+]002'ZPH6DOP7
MQ=T0D87FJI<2W2"5,VPQ4G^9%%,\M4$48JMJKH)=%>5PQ3#T1U[4HLP<QB"'
M-!"09):B(!Z1HI0]JJMFB+2,(AGI2.QI+"B1K$/Y[N J-/3G@SO"2V,J@Y8A
M=>9R&@'![F*X10G.85LPE* .D3)$4;8ODIGSEQOL2+([--)VPS3C0SBUL8V%
M 01PH,\9HM,&IT3G#!A$RKT&YJ@[$D12E6P**>^UJC;DJ'Q#D> "^S.ZTIU.
M*,A25J?(H(-"/00^4D'!EDBRA_X\A SD(I.MR+6#DA@4!"]0 0)!N 80J. %
M_G2(J9)B!C(4]* 8=4A")ZG'2D%+D]CBY",]\E![.N0D4G&5/B^:T9)L-*6V
M"X/G]&"9;^81/FX(@X1("M&(#A1C#>V!15;7-3[0B6A*<\(16"J1C?J1H3;S
MB#E]"0(3$$P,$BPI2>)041 (-2<I08$)  K4%#"UJ0K%W Q%>$";4I)2EM&J
M1-)0*Q105((\ $%%]MG2@>!!I3$P:U\UJM NDBQD<W1H3TE"5R>1-6,A$"H*
MZ*2UU_%AJ$AMVA%2P->6EN&O=$"!# 0[V(V.(4=LT.4;D'*L9"V+5:M% P*#
M(M?!VA:M' VG939VP-I"I ]R(EN?FN.2,W!%?IP!5&+P9*>)X8L^59&*9:AH
MQ4>!0&1G.-;M+..&4'$D*K4*I!F>12]E.B0)2*$N(8/2@I$T=H'JNX,6GWE:
M-\@+5-$A(Q?EX,4)?K"^]U69=D-VR(\&!04NJVF1U/B%(-$Q,:99"&?5Y<0U
MNJN-35+O%5L@ XV%%RED>,/+=NF4?FUQACSLSP^?UUIYWC"]':PN3V;@88TA
M96-UR.FT&*BJ _J1826&F,3.".-!;I@&-0XDCG5,+;:FQ)M&R:-NS8B5.I4'
M!:&S1H JYSSWBR!];C =UYR"-I,*#H$.YITA<I+$J5!4@789Y<@5:5&FA P2
"#@BS
 
end
Newsgroups: biz.sco.general
From: Jean-Pierre Radley <jpr@jpradley.jpr.com>
Subject: Imake & sco.cf
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Content-Type: text
Reply-To: jpr@jpr.com
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Sat, 26 Dec 1992 23:10:29 GMT
Content-Length: 925       
Precedence: bulk

 ODT 2.0
 
I'm getting tired of editing Makefiles by hand.

Has anyone fixed up /usr/lib/X11/configure/sco.cf to have imake
produce Makefiles that would use the shared C and the shared X libraries?

I just compiled a little file with and without, and we're talking about
having a binary of 66Kb instead of 1.2Mb.

While we're on this, I see the files:

/usr/lib/:
-rw-r--r--   1 bin      bin       221064 Nov 18 18:57 libX11_s.a
-rw-r--r--   1 bin      bin       418580 Apr 08  1992 libXtXm_s.a

/shlib:
-rwxr-xr-x   1 bin      bin       304438 May 07  1992 libXR4sco_s
-rwxr-xr-x   1 bin      bin      1213844 May 07  1992 libXtXm114_s
-rwxr-xr-x   1 bin      bin      1032412 May 07  1992 libXtXm_s

The first two entries in /usr/lib that I've show refer to the first two
entries in /shlib that I've shown. What's that third entry about?

-- 
Jean-Pierre Radley   Unix in NYC   jpr@jpr.com   jpradley!jpr   CIS: 72160.1341
From: paul@openage.com (Paul A. Fischer, Sr UNIX Sys Consultant)
Newsgroups: biz.sco.general
Subject: Re: Performance degradation under SCO UNIX
Date: 30 Dec 92 13:56:49 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

>>  Then make 
>> sure the BIOS shadowing is turned on.

>DOS Shadow BIOS?  Why?  Last I heard, this is just wasted RAM,
>not that we can address that range on most motherboards anyway.
>What do you know that I don't?

>>  You might also give more info on what 
>> ethernet boards are running, and wether this lotus slowdown is a DOS lotus slow 
>> down, or a UNIX lotus slowdown.

>Even if it's run under DOS, under, say Merge, we don't use DOS
>shadown BIOS, do we?

The way I understand it is this.  The OS (DOS and UNIX/XENIX) need to access 
the system BIOS quite often (a few times a second).  By copying this 
information from the BIOS chips which are 8-bit on a 8MHz bus, into RAM which 
is 32-bit and runs at the same MHz rating as the processor, we can access this 
information much quicker.  This is most noticable when SCO boots and displays 
the hardware information.  With BIOS shadowing off it takes several seconds, 
but it screams by with the BIOS shadow on.  You might try it for yourself.

Somewhere in the dark recesses of my mind I remember that UNIX/XENIX might 
internally cache this information when it boots.  I wonder if Bela or another 
SCO Wiz can tell us if this is true.

--------------------------------------------------------------------------------
Independent SCO support and service provider in the D.C. metro area.
Insert clever saying here...
Paul A. Fischer           | Open Age Inc.  | paul@openage.com
Sr. UNIX Sys. Consultant  | (301) 948-6422 | (301) 948-9644 Fax
Newsgroups: biz.sco.general
From: sl@wimsey.bc.ca (Stuart Lynne)
Subject: Re: Configuring an Adaptec 1542B ...
Organization: Wimsey Information Services
Date: Thu, 31 Dec 1992 23:28:19 GMT

In article <1992Dec31.214127.6866@xenitec.on.ca> eah@xenitec.on.ca (Ed Hew) writes:
>In article <9212301744.AA00859@jrsalb1.UUCP> Tim Northrup <jrsalb1!tgn@brspyr1.brs.com> writes:
>>It has an Adaptec 1542b controller with 2 Maxtor SCSI drives, and a SCSI
>>	[...]
>>Currently, the 1542b is configured for the default of 5 mb/s transfer speed.
>Mbytes/sec.  They weren't kidding.  I set my host adapter to talk
>to it at a max transfer rate of 5 (down from 10), and magically

Saw this recently with a WangDat 2600. On the Adaptec 1742 in enhanced mode you 
can set the maximum speed for each individual device. So it was easy to fix 
without too much degradation to other devices.

-- 
Stuart Lynne <sl@wimsey.com> ......................... UNIX Facsimile Software
Wimsey Information Technologies ................... moderator biz.sco.binaries
uucp login:nuucp passwd:nuucp .................... ftp.wimsey.com:~ftp/ls-lR.Z
PD Software for SCO UNIX .................... ftp.wimsey.com:~ftp/pub/wimseypd
Newsgroups: biz.sco.general
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: boot-time delay, Re: Two things....
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.30 $
Organization: Trumphurst Ltd.
Date: Thu, 31 Dec 1992 11:35:35 +0000

Michael B Garrett wrote:

> Also: Has anyone ever seen an ODT system that took about 1 minute to start
> reading the .text and .data files on bootup? Mine waits at least that long
> after you hit "enter" at the "Boot:" prompt. Since it has done this since
> ODT 1.0, I assumed it was just a SCSI kinda thing, but my last client
> got SCSI also, and it doesn't do it there. Both machines are EISA 486/33,
> mine is a Bustek 742A and the client's is a 1740A.
> 
> Is this slowness indicative of some problem I'm unaware of, or is it
> just because the disk is slower (Maxtor 660MB) ?

I had a problem with my 486/50 booting very slowly, and it went away when 
I turned the BIOS shadowing OFF.

It was probably a BIOS bug of some kind, and not relevant to your 
situation, but you could try turning shadowing off and eliminate another 
possibility.

-- 
Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Newsgroups: biz.sco.general
From: Bela Lubkin <belal@sco.COM>
Subject: BIOS shadowing, Re: Performance degradation under SCO UNIX
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Wed, 30 Dec 1992 17:58:54 GMT
Precedence: bulk

Paul Fischer wrote:

> The way I understand it is this.  The OS (DOS and UNIX/XENIX) need to access 
> the system BIOS quite often (a few times a second).  By copying this 
> information from the BIOS chips which are 8-bit on a 8MHz bus, into RAM which 
> is 32-bit and runs at the same MHz rating as the processor, we can access this
> information much quicker.  This is most noticable when SCO boots and displays 
> the hardware information.  With BIOS shadowing off it takes several seconds, 
> but it screams by with the BIOS shadow on.  You might try it for yourself.

The OS (DOS) needs to access the system BIOS possibly millions of times
per second; copying the BIOS into RAM makes DOS very much faster.

The OS (XENIX or UNIX) does not use the BIOS at all (*) and gets no
benefit from BIOS shadowing.

(*) The boot program runs under BIOS.  You will notice some performance
difference in booting.  Also, the VGA driver reads certain constants out
of the VGA BIOS ROM when switching modes.  The performance difference is
insignificant.

HOWEVER.  Shadowing is implemented various ways, depending on the
machine's BIOS.  Some implementations of shadowing are actively harmful
to UNIX and *must* be turned off.  I always recommend turning all
shadowing off if you are having any odd problems.  If you are absolutely
sure that it doesn't hurt your system, and you want the dots to move
quickly at boot time, then turn it back on.

>Bela<
From: alexl@alvarez.COM (/dev/null)
Newsgroups: biz.sco.general
Subject: SCO Xenix 386 2.3.4 Adaptec w/Archive ST 52
Keywords: Tape problems
Date: 28 Dec 92 07:00:55 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Cc: scogen@xenitec.on.ca
Precedence: bulk


        {Header deleted}


.>   Date: 28 Dec 92 03:20:10 GMT
.>   Organization: CCS Enterprises, Inc.

.>   We have been having problems with a new tape drive installed on our
.>   system (486 DX2/66Mhz, 16mb, SCO Xenix 386GT 2.3.4, Adaptec 1542B controller
.>   HP 667mb SCSI-2 HD, & Archive/Maynard ST 525mb SCSI Tape Drive).

.>   We are able to read and write 150mb & 250mb  (DC6150 & DC6250) tapes
.>   without any problems.  However, when we go and try to write to a
.>   525mb tape (DC6525) (and using several different tapes) we get:

.>   %tape    type=scsi  unit=2:0
.>   SCSI: ERROR: on tape ha=0 id=2 lun=0
.>   SCSI: WARNING: Host Adapter Detected Error
.>         SCSI Bus Data Over/Under Run
.>   tar: tape write error

.>   We have downloaded and installed from SCO's sosco system the SLS xnx316
.>   which is an Adaptec SCSI tape supplement for Xenix 2.3.4, but this did
.>   not correct the problem.  The above message was with this patch applied.

.>   Has anyone seen this problem before?  In looking in the release notes,
.>   I do not see the 525mb tape drives listed, and now this concerns me,
.>   but it is hard to beleive that it does not support them???  Hmmm...

                I use 525MB SCSI tapes all the time with out a 
problem. But I do remember something about this brand of tape 
drive and Unix. I think there is a jumper to be set somewhere. I 
use the sankyo drives, And I have no problems...



.>   -- 
.>   >.. Bob Willey, CDP          ..  |  ..  uunet!consult!bob  bob@ccs.com   ..<
.>   >.. CCS Enterprises, Inc.    ..  |  ..   Office: (410) 820-4670          ..<
.>   >.. P.O. Drawer 1690         ..  |  ..      FAX: (410) 476-5261          ..<
.>   >.. Easton, Maryland 21601 ......|......... BBS: (410) 476-5098 ...........<
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /  ) //            _//                   Alexander Lopez
 /--/ // _  _.,      /    _____   _  __.   Alex Alvarez and Associates
/  (_</_</_/ /\_    /___ (_) /_)_</_/  |_  alexl@alvarez.COM
                            /         (|   305-649-8900
From: dave@das13.snide.com (Dave Snyder)
Newsgroups: biz.sco.general
Subject: Re: BIOS shadowing, Re: Performance degradation under SCO UNIX
Date: 2 Jan 93 17:45:07 GMT
Organization: Snide Computer Services - Folcroft, PA

In article <ysaqwB1w165w@zswamp.UUCP> geoff@zswamp.UUCP (Geoffrey Welsh) writes:
} dave@das13.snide.com (Dave Snyder) writes:
} 
} >     Video   ROM Shadow    C000,32k    Enabled
} >     System  ROM Shadow    F000,64k    Enabled
} > [all others disabled]
} 
}    Looks right to me but, as Bela pointed out, it doesn't affect performance 
} past boot time.
} 
I've since disabled these two Shadows.  The machine boots a little slower,
but after that I notice nothing different (except an extra 128K of memory :-)

} > Which is weird, I have an Archive 2150L tape drive w/ an Archive VP402
} > controller card and I still can't use both simultaneously.  Could a
} > wrong BIOS setting be causing this.
} 
}    I wouldn't think so; it sounds more like an interrupt or DMA conflict.
} 
Bela said pretty much the same thing... so I changed
  name=tape base=0x220 offset=0x4 vec=9 dma=1 type=archive 
to
  name=tape base=0x220 offset=0x4 vec=5 dma=3 type=archive 
and now I have no more problems.

Thank you very much Bela and Geoff!

DAS
-- 
David Snyder @ Snide Computer Services - Folcroft, PA          Current Release
                                                               is db4glgen-3.9
UUCP:  ..!uunet!das13!dave   INTERNET:  dave.snyder@snide.com
Newsgroups: biz.sco.general
From: gerg@netcom.com (Greg Andrews)
Subject: Re: time command
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Thu, 31 Dec 1992 04:30:15 GMT

apl@world.std.com (Anthony P Lawrence) writes:
>
>I'm sitting here playing with a 115K baud terminal. I wanted to
>see how it compares to the system console, so I did 'time lr /etc'
>on both the console and the terminal.
>
>The console finishes first, as we would all expect.  But, 'time'
>reports LESS real, user and system time for the command run on
>the terminal.
>
>The only rational explanation is that either the multiport card or the
>terminal (or both) are doing a lot of buffering so that 'time' thinks
>the command is complete when it actually isn't.  
>

I see it differently.  Running a 386 box from a terminal is a primitive
form of "client/server" computing.  Running it from the console is not.

With a terminal, your application simply shoves its output to the
terminal.  The terminal does the work of placing the character into
the screen buffer, moving the cursor to the next position (which can
include wrapping to the first column of the next line), and scrolling
the screen if you're on the last line.

When you're on the console, the computer must handle your command *and*
perform all the character and cursor manipulations for the screen.  Thus,
the work that normally would be off-loaded to the terminal is seen by the
cpu and it leaves that much less available to the rest of the system.

-- 
:::::::::::::::::::  Greg Andrews  gerg@netcom.com  :::::::::::::::::::
ObGuindon:  "I got the four major food groups:
            Junk, Fast, Frozen, and Spoiled."
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Newsgroups: biz.sco.general
From: jens@tfs.com (Jens Andersen)
Subject: Soundcard support
Organization: TRW Financial Systems
Date: Tue, 22 Dec 1992 06:52:24 GMT

Hi!

Many PC nowadays run BOTH native DOS/WINDOWS and UNIX. And many of us
equip the native DOS side with multimedia extensions like the Creative
Labs Soundblaster Pro and maybe more sophisticated equipment.

What kind of support does SCO (ODT) have for soundcards in general and
SBPRO specifically. Can I use the SBPRO CD ROM drive under ODT? Can I
install the CD-ROM distribution via the SBPRO CD-ROM drive? In other
words, is there support for the SBPRO CD-ROM drive in the installation
kit?

 +============================================================================+
 !                        Jens Andersen - jens@tfs.com                        !
 !                  Phone: +47 2 898298 - Home: +47 9 867379                  !
 !                  Fax.: +47 2 217026 - Pager: +47 96 77600                  !
 +============================================================================+