HDTenEightyP/NetNews huggingface dataset:
From: paul@openage.com (Paul A. Fischer, Sr UNIX Sys Consultant)
Newsgroups: biz.sco.general
Subject: Performance degradation under SCO UNIX
Date: 29 Dec 92 15:32:08 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


>This posting is on behalf of a friend of mine who is having a problem
>with an SCO UNIX upgrade.  A customer of his originally had a 486/33
>with 16M of memory and a 1G SCSI drive.  Recently, the system was upgraded
>to a 486/50 with 32M of memory and an additional 1G drive was added. The
>upgrade was principally done because the customer wanted to network their
>existing PCs with the UNIX box (using PC-Interface by Locus) so that
>their business could be put "under one roof". Unfortunately, the system
>is now crawling along at a snail's pace.

>Oh, yes, before I forget, it's a pretty standard box. UNIX 3.2v4.1,
>has a Bustek SCSI, and I believe a couple of Equinox 24-port boards.
>They currently have about 30 or so dumb terminals, about 15 PCs and
>around 8 printers (HPLJs and CI line printers).

First make sure the interanal and external 486 caches are turned on.  Then make 
sure the BIOS shadowing is turned on.  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.

--------------------------------------------------------------------------------
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
From: kevin@shady.UUCP (Kevin Smith)
Newsgroups: biz.sco.general
Subject: Re: time command
Date: 31 Dec 92 20:54:56 GMT
Organization: ShadeTree Software, Inc.

In article <1992Dec31.043015.28653@netcom.com> gerg@netcom.com (Greg Andrews) writes:
:>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.
:>
:>-- 

As I see it, real time is real time.  Since the real time to the
terminal was shorter than the console or the "observed" time the only
answer is buffering in the serial controller or driver or the
terminal.  The user and system times reflect how much effort the cpu
put into the io.  Interrupt driven dumb serial controllers can kill a
cpu at 9600 baud.  Intellegent controllers can impose a wide range of
loads depending just about everything.  A recent issue of SCO magazine
had a multiport serial controller review that addressed actual CPU
loads from different boards.  Also keep in mind that sending data out
a port is always easier that receiving.  The computational load of
managing the console screen is probably pretty small.

You should put a stop watch on it and figure the actual transfer rate
to the screen.  Furthermore you should cat a large file rather than
'lr' since listing files involves far more cpu and disk processing.
FurtherFurthermore a lot of terminals cannot actually handle continous
input at their rated speed and will revert to some form of handshaking
to moderate their input.  I like to create a huge file of lines of 79
'#'s.  Disable any terminal handshaking and let it fly.  Watch the
output for ragged right margins that indicate data loss.  This is
also good for testing printers.
-- 
	    | Email - !shady!kevin uunet!shady!kevin kevin%shady@uunet.uu.net
Kevin Smith | Voice - (+1) (908) 874-7980
	    | Mail  - ShadeTree Software, Inc., 192 Capricorn Dr. #10,
	    |         Somerville, NJ  08876, USA
From: apl@world.std.com (Anthony P Lawrence)
Newsgroups: biz.sco.general
Subject: Re: time command
Date: 31 Dec 92 11:43:04 GMT
Organization: The World Public Access UNIX, Brookline, MA
X-Newsreader: Tin 1.1 PL3

gerg@netcom.com (Greg Andrews) writes:
: 
: 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.

Yes, from the point of view of freeing up the cpu to do other work,
you (and 'time') are quite correct.  That wasn't exactly my point,
though (and as usual I did a lousy job explaining what I was driving at).

In the first place, in the context of evaluating a terminal, the job
isn't done until the output is complete.  That's obvious, and it's
also obvious that 'time' can't help us there.

But more in line with what I was thinking about is this: Suppose we
have a verrry sloooow disk drive.  Something that takes, oh, 20 seconds
to write a track (I said sloow!).  Now suppose we front-end it with
a very fast 100 megabyte buffer.

That buffer is going to make the drive look real good for simple tests
like writing less than 1 track in any 20 second period.  But the
minute you exceed that rate, the performance is gone.

So what I was fumbling at last night was the fact that you really
need to be aware of the nature and size of any buffering before
trying to run tests to compare the speed of things.


		Tony   apl@world.std.com

Lawrence & Clark, Inc		(617) 762-0707	(206) 323-2864
Xenix/Unix support,etc 	 	 Boston		 Seattle
       Kevin Clark is embarrassed by most of what I say.
Newsgroups: biz.sco.general
From: sl@wimsey.bc.ca (Stuart Lynne)
Subject: Re: Performance issues revisited
Organization: Wimsey Information Services
Date: Tue, 22 Dec 1992 22:14:19 GMT

In article <9212211533.aa29993@dlpco.dlpco.COM> lee@dlpco.dlpco.COM (Lee Penn ) writes:
>This did not make it thru to mike via direct address, so thought I would
>just shoot it back thru scogen.
>
>Mike: There was a very long series of messages about machines being
>upgraded to more than 16 Megs RAM and the secondary cache memory.  
>Have your friend check to see if his machine as 64K of cache or 
>256K.  He NEEDS 256k and I suspect that if he has only a 64k cache
>that that is the problem as only the lover 16 megs are being cached
>and the upper 16 megs are being accessed at a snail's pace.

The only time I've seen this problem it was due to the machines have a 
configuration point in the low level BIOS setup that set the amount of memory
to cache. The machine in question was field upgraded from 16MB to 32MB and
the user didn't realize he had to change the BIOS CMOS setup.

So be sure to check that your machine has cache enables for all the memory
you have installed.

-- 
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,biz.sco.opendesktop,comp.unix.admin
From: clay@haapi.mn.org (Clayton Haapala)
Subject: Re: Busmouse not working on ODT 2.0
Organization: Haapi's Hangout
Date: Thu, 31 Dec 1992 06:04:30 GMT


I use a Logitech busmouse on my Xenix system.  As I understood the
docs, you can use any IRQ you want for the busmouse, as long as you
use IRQ5.  (Like the San Miguel Beer joke, right?  Eh? ...)

Seriously, I thought it said to use IRQ5, so things like VP/ix will
work, as well.  I believe this restriction/recommendation carried over
to ODT 1.1 and SCO Unix 3.2v2, too.
-- 
Clay Haapala				"Behold the Holy Pogo Stick"
clay@haapi.mn.org
From: jpr@jpradley.jpr.com (Jean-Pierre Radley)
Newsgroups: biz.sco.general
Subject: strftime(S)
Date: 31 Dec 92 06:29:57 GMT
Reply-To: jpr@jpr.com
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Content-Type: text
Content-Length: 264
Precedence: bulk

Unix 3.2.4
The mention of strftime() in ctime(S) should go bye-bye; that function is no
longer in libc.a, but in libintl.a.

Indeed, it has its own strftime(S) man page reference.
-- 
Jean-Pierre Radley   Unix in NYC   jpr@jpr.com   jpradley!jpr   CIS: 72160.1341
From: sfrazier@norstan.com (Steven E Frazier)
Newsgroups: biz.sco.general
Subject: Capturing data from a RS232 Port
Date: 30 Dec 92 21:04:44 GMT
Organization: Norstan Communications - Columbus, Ohio


Is there a way to use an existing program on SCO to open a file and capture
data coming from say a RS232 port /dev/ttyak and then use cron to drop 
DTR @ say 0200 then open the port back up?  I am thinking cu could do
that but can than be run in the background?

The purpose is to capture CDR (Call Detail Records) from a PBX, at 0200
close the port copy them to another file and then reopen the port again
for data capture.  

Thanks in advance.

Steve

-- 
Norstan Communications, Inc.        | Steven E. Frazier
8101 N. High Street Suite 100       |---------------------------------------
Columbus, OH   43235                | Local : sfrazier
Voice 614-785-7335 Fax 614-785-7337 | Remote: sfrazier@norstan.com
From: kuo@weber.cis.nctu.edu.tw
Newsgroups: biz.sco.general
Subject: NE2000 driver
Date: 29 Dec 92 06:33:26 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk


Dear Netters:

I've install SCO-UNIX V3.2.4 and have a problem with my network card
NE-2000. Can anyone tell me is there any solution to making my system
working on TCP/IP with NE-2000 card.

Thanx in advance.

  =======================================                 Z
   Kuo ( Ching-Yii Kuo )                              Z
   Email:  kuo@weber.cis.nctu.edu.tw               z
           kuo@beethoven.cis.nctu.edu.tw        z   ,;:;,
   Taipei , Taiwan , R.O.C.                   z     <OoO>
  =======================================    z       |^|
Newsgroups: biz.sco.general
From: jp@tygra.Michigan.COM (John Palmer)
Subject: WANTED: Stories about SCSI Tape Backups under XENIX
Organization: CAT-TALK Conferencing System
Date: Sun, 3 Jan 1993 04:54:16 GMT

Earned a few bucks and am looking to get a SCSI tape for my
SCO Xenix (2.3.2) system. I'm looking in the 250MEG range. 

Anyone got any war stories??
-- 
Its most likely a     | E-MAIL: jp@michigan.com  CAT-TALK IS BACK as a FREE
forgery, so save your | SYSTEM!! 313-882-2209 300-14400 V.32/V.32BIS/TurboPEP
flames for someone    | Anon-UUCP: System: tygra, Login: nuucp, no pw
who cares  :->        | Get file "/cat/pub/filelist" for a list of files.
Newsgroups: biz.sco.general
From: sl@wimsey.bc.ca (Stuart Lynne)
Subject: Re: Performance issues revisited
Organization: Wimsey Information Services
Date: Thu, 24 Dec 1992 21:39:27 GMT

In article <1992Dec24.180433.18528@netcom.com> alanm@netcom.com (Alan H. Mintz Cons) writes:
>bob@consult.UUCP (Bob Willey CDP) writes:
>
>> We really need to get our hands on the
>>SCSICNTL.EXE program so we can see what is going on.
>
>I got a copy off a BBS in Arizona somewhere. Check nixpub or
>perhaps comp.periphs.scsi.

It's available here on wimsey. In ~ftp/pub/scsi.

It tends to get updated when I buy a new drive.

-- 
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
From: fietze@kagcpd01.ag01.kodak.COM (Roman Fietze@kagcpd01.ag01.kodak.COM,KAG CP Development@kagcpd01.ag01.kodak.COM, 49 711 406 2839)
Newsgroups: biz.sco.general
Subject: Re: Slow login and u386mon
Date: 31 Dec 92 00:15:28 GMT
Reply-To: fietze@kagcpd01.ag01.kodak.COM
Organization: Kodak AG, Office Imaging, Product Engineering and Development
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Return-Receipt-To: fietze@kagcpd01.ag01.kodak.COM
Precedence: bulk

Hello Kevin,

> SOLUTION: Make sure /etc/auth/system/devassign has the correct entries.
>           For example:
>     
>                tty1a:v_devs=/dev/tty1a,/dev/tty1A:v_type=terminal:chkent: 
>                tty2a:v_devs=/dev/tty2a,/dev/tty2A:v_type=terminal:chkent: 
> 
>           Add the entry tty1A (or necessary tty) to /etc/auth/system/ttys
>           manually:
> 
>                 tty1A:t_devname=tty1A:chkent:
> 
>           or using Sysadmsh->Accounts->Terminal->Create.
>           Delete all the duplicate entries except the original one. 

The problem seems to be that there are entries starting with
"/dev/tty...:" instead of just "tty...:".

Important to say that you cannot delete these entries or change them
in multiuser, probably because the data is somehow cached (maybe
somebody from SCO, Bela?!, can help). I did some testing because I had
similar problems, but with devices ttyA0[1-8] which are created by the
Specialix serial multiport adapter. As long as there is only a device
starting with /dev this entry gets copied over and over.

I cannot change or delete these entries from here, because I cannot go
to single user from here (logged in via modem) and would appreciate
any help how to remove these entries without going to single user.

Roman

---------------------------------------------------------------------
Roman Fietze (Mail Code 2201)                    Hedelfinger Str. 154
Copier and Printer Development                      7000 Stuttgart 60
Kodak AG                                                      Germany
fietze@kagcpd01.ag01.kodak.COM                  VOICE 49-711-406-2839
fietze@kodak.COM                                    K-NET 28-631-2839
Newsgroups: biz.sco.general,biz.sco.opendesktop,comp.unix.pc-clone.32bit
From: mju@mudos.ann-arbor.mi.us (Marc Unangst)
Subject: Re: Busmouse not working on ODT 2.0
Date: Sat, 26 Dec 1992 17:23:26 GMT
Organization: The Programmer's Pit Stop, Ann Arbor MI

In article <1992Dec26.035527.1820@blkbox> mknewman@blkbox (Marc Kraker Newman) writes:
>I attempted a upgrade to SCO ODT 2.0 from 1.1 today, and everything worked 
>fine except the mouse.  I tried an upgrade, a install leaving the other
>partitions in place and a full, wipe disk install, but I was unable to get
>my Logitech Mouseman Busmouse to work.  It is configured at interrupt 2,
>which I know is a bit flakey.  I checked SOS, and there was an article saying
>something about if the barrel on the mouse connector is a round one, it is a
>keyboard mouse.  Can anyone tell me if my Logitech Mouseman Busmouse is a
>Keyboard mouse and not a busmouse?

Well, first of all, you didn't have to go through all those different
installations -- just do a "mkdev mouse" once the system is installed
to reconfigure the mouse.

And no, the Mouseman is not a keyboard mouse.  It is either a
Microsoft-compatible bus mouse or a "new-style" Logitech bus mouse,
depending on which driver you configure.  ODT 2.0 should have drivers
for both.

As for interrupt 2 -- yes, it can be a bit flakey if you have an older
VGA card.  The EGA used IRQ 2 for the vertical retrace interrupt, and
older VGA cards frequently implemented this for compatibility reasons.
Newer cards either have it disabled, or have a jumper to select
the behavior, because few (no?) programs depend on it anymore.  Your
best bet would be to move the bus mouse to IRQ 5 or some other unused
interrupt and try it again.

-- 
Marc Unangst, N8VRH         | "Of course, in order to understand this you
mju@mudos.ann-arbor.mi.us   |  have to remember that the nucleus of the atom
                            |  is squishy."
                            |    -W. Scheider, from a Physics lecture
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: biz.sco.general
Subject: Re: Configuring an Adaptec 1542B ...
Date: 2 Jan 93 02:35:16 GMT
Organization: Izot's Swamp

eah@xenitec.on.ca (Ed Hew) writes:

> I believe that someone else has (correctly) commented that the
> scsi controller negotiates directly with scsi devices plugged
> into it, so there's really nothing else to change or set, other
> than the usual stuff like scsi id on the drive and ensuring you
> have your terminating resistor packs at the end of the scsi chain.

   You can fine-tune things on the host adapter: we've been discussing the bus 
master DMA rate, and someone recently mentioned using a jumper to tell the 
adapter that it should try to negotiate a synchronous transfer (something I 
just set on a 1542B today, but it didn't help because the Conner 3100F didn't 
co-operate).

> I set my host adapter to talk
> to it at a max transfer rate of 5 (down from 10), and magically
> the drive was recognized and I've been using it ever since.

   I have not seen anything on an Adaptec 1542A, 1522, or 1542B that set the 
speed of the SCSI transfers (short of the synchronous negotiation enable).  
I'd be interested in seeing any such info for any host adapter...

  Geoffrey Welsh, 7 Strath Humber Court, Islington, Ontario, M9A 4C8 Canada
geoff@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff (416)258-8467
                Now I've lost everything, I give to you my soul
           And the meaning of all that I believed before escapes me
                  In this world of none, no thing, and no one
                            - Genesis, _Afterglow_
Newsgroups: biz.sco.general
From: fred@genesis.demon.co.uk (Lawrence Kirby)
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: biz.sco.general
Subject: Re: Configuring an Adaptec 1542B ...
Date: 2 Jan 93 02:42:41 GMT
Organization: Izot's Swamp

sl@wimsey.bc.ca (Stuart Lynne) writes:

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

   The very next article and I'm eating my words.  I do recall seeing 
something like that when setting up a 1740 in enhanced mode last February.

  Geoffrey Welsh, 7 Strath Humber Court, Islington, Ontario, M9A 4C8 Canada
geoff@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff (416)258-8467
                Now I've lost everything, I give to you my soul
           And the meaning of all that I believed before escapes me
                  In this world of none, no thing, and no one
                            - Genesis, _Afterglow_
From: kevin@shady.UUCP (Kevin Smith)
Newsgroups: biz.sco.general
Subject: Re: Slow login and u386mon
Date: 31 Dec 92 20:38:30 GMT
Organization: ShadeTree Software, Inc.

In article <9212310115.aa21881@kagcpd01.ag01.kodak.COM> fietze@kagcpd01.ag01.kodak.COM writes:
:>Hello Kevin,
:>
:>> SOLUTION: Make sure /etc/auth/system/devassign has the correct entries.
:>>           For example:
:>>     
:>>                tty1a:v_devs=/dev/tty1a,/dev/tty1A:v_type=terminal:chkent: 
:>>                tty2a:v_devs=/dev/tty2a,/dev/tty2A:v_type=terminal:chkent: 
:>> 
:>>           Add the entry tty1A (or necessary tty) to /etc/auth/system/ttys
:>>           manually:
:>> 
:>>                 tty1A:t_devname=tty1A:chkent:
:>> 
:>>           or using Sysadmsh->Accounts->Terminal->Create.
:>>           Delete all the duplicate entries except the original one. 
:>
:>The problem seems to be that there are entries starting with
:>"/dev/tty...:" instead of just "tty...:".
:>
:>Important to say that you cannot delete these entries or change them
:>in multiuser, probably because the data is somehow cached (maybe
:>somebody from SCO, Bela?!, can help). I did some testing because I had
:>similar problems, but with devices ttyA0[1-8] which are created by the
:>Specialix serial multiport adapter. As long as there is only a device
:>starting with /dev this entry gets copied over and over.
:>
:>I cannot change or delete these entries from here, because I cannot go
:>to single user from here (logged in via modem) and would appreciate
:>any help how to remove these entries without going to single user.
:>
:>Roman

My guess is, and I refuse to accept responsibility if wrong, that you
can edit these files in multiuser.

My entries all resemble the ones listed above (i.e.  no /dev in the
first field).  What does Sysadmsh->Accounts->Terminal->Assign have to
say? Do they show up in Examine.  If so, I would delete and re-add
them.

Make backups of the files before starting and ask everyone to sit still
while you are editing (i.e. no logins or logouts).
-- 
	    | Email - !shady!kevin uunet!shady!kevin kevin%shady@uunet.uu.net
Kevin Smith | Voice - (+1) (908) 874-7980
	    | Mail  - ShadeTree Software, Inc., 192 Capricorn Dr. #10,
	    |         Somerville, NJ  08876, USA
Newsgroups: biz.sco.general
Subject: Performance questions. Benchmarks?
From: a_millsbs@ccsvax.sfasu.edu
Date: 2 Jan 93 15:17:48 CST
Organization: Stephen F. Austin State University

After all the recent discussion on performance and bios shadowing I still have
a few questions of my own.

(1)  What type of CPU/FPU benchmark programs are available on the net?  I know
     about iozone for disk I/O performance but has anyone written a tools to 
     display info such as Whetstones, Drystones, Spec Marks, etc.  I would love
     to have such a tool and here is why...

(2)  A freinds 386-40 SCO machine seemed slow and while playing around we
     disabled the 64k onboard cache and things seemed to speed up.  Its a
     generic clone board with 91 AMI bios and the UMC chip set. This really has
     me puzzled.  Any ideas?

(3)  I recently replaced my 386-40 motherboard with a Cyrix 486dlc-33
     motherboard with an onboard Cyrix FPU.  Its a new board designed for the
     DLC ship and has the new ACER Award 486dlc bios and a 64k cache.  The unit
     runs great and hasnt given me a lick of trouble but I dont really see any 
     performance increase.  All I did was swap the motherboards and reboot no
     other changes where made.  If I boot the machine under MeSsy-DOS I see a
     BIG performance increase and the bechmark programs such as SI, SYSINFOm
     and CHECKIT show that it is about 2.5 times as fast CPU-wise as the 386-40
     and about 50 times as fast for math operations (no fpu on the 386-40). 
     Still under ODT 2.0 I really dont see a performance increase.

Any help or thoughts will be greatly appreciated....

Thanks in advance,

------------------------------------------------------------------------------
B. Scott Mills                            (409) 568-1363
Computer Center -- Technical Support,     Stephen F. Austin State University
a_millsbs@ccsvax.sfasu.edu                P.O. Box 13012 SFA Station
root@calvin.sfasu.edu                     Nacogdoches, TX  75962
------------------------------------------------------------------------------