HDTenEightyP/NetNews huggingface dataset:
From: bob@consult.UUCP (Bob Willey CDP)
Newsgroups: biz.sco.general
Subject: Re: Performance issues revisited
Date: 22 Dec 92 13:36:11 GMT
Reply-To: bob@consult.UUCP (Bob Willey CDP )
Organization: CCS Enterprises, Inc. - Easton, MD

In article <92111533.3@dlpco.dlpco.COM> lee@dlpco.dlpco.COM (Lee Penn ) writes:
>On another machine that I worked with, we found out that the hard
>drive was the bottleneck.  I used the following command as a quick 
>test to see about the bytes/second off the drive and found it very
>very slow.
>        time dd if=/dev/rhd0a of=/dev/null bs=2048 count=8192
>This is a 16 meg copy to /dev/null.  On a lively machine, I expect
>to see 1 Megabyte/second or better.  On my customer's machine, we
>were getting around 200 K/sec.  Replaced the drive and he came back
>up to speed.

This was a very interesting post, and got me to thinking (look out!!)..

We are in the process of upgrading our internal machine and have been 
looking for some forms of measurement of determining the difference in
speed between the machine.  Running the above command on the new machine
yielded some interesting results, but NOT the ones that we wanted.

       OLD MACHINE                             NEW MACHINE
386/33 w/8mb memory 64kcache           486/DX266 w/16mb memory 256k cache
Ultrastor 12F ESDI controller          Adaptec 1542 SCSI controller
Maxtor 338mb drive (~ 16ms)            HP 667 SCSI-2 drive (~13ms)
CMS Enhancement 250mb tape             Archive ST-525 mb tape (SCSI)
                       Results of above command:
Real 25.3  user 0.3  sys 5.2           real 1:01.6  user 0.3  sys 3.6
                 Tape backup results when using CTAR
Typical:  2.3mb/min                    Typical:  5.8mb/min

While the backup time is noticeable faster, the dd command for disk transfer
appears noticeable SLOWER on the new machine???  Is there anything obvious
in the above configuration that can cause problems?  Is there anything
special that needs to be done to the Adaptec controller to get better
performance??  This is very uncomforting since we are upgrading to obtain
more throughput.

Thanks Lee for the very thought provoking command you offered to the
net.  (I think...) :*)

-- 
>.. 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 ...........<
From: belal@sco.COM (Bela Lubkin)
Newsgroups: biz.sco.general
Subject: Re: Performace degradation under SCO
Date: 22 Dec 92 21:12:19 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

> The problem may not be related to kernel parameters at all. Many ISA bus
> motherboards will exhibit major speed degradation when you go past 16 MB
> of main store.
> 
> The reason, simplified, is that the ISA bus has 24 address lines for doing
> memory access, which means it can only directly address 16MB. After that,
> when UNIX tries to do DMA, it must copy down or page memory chunks to a
> space below 16 MB. This is very slow. Some MB manufactures have worked 
> around this but for the most part, my experience has been that stock and 
> standard MB's ( read; the ones that work right) will have this limitation.

This is mostly a red herring: first, SCO UNIX 3.2v4/ODT 2.0 knows
whether your host adapter/bus combination can DMA above 16MB.  It goes
to a lot of effort to make sure that things that might need to be DMA'd
to/from, like the buffer cache and kernel .data & .bss areas, are stored
in DMAable memory, while things that will not need to be DMA'd to, like
kernel .text, are stored in non-DMAable memory if any is available.
Second, if you compare modern processor and memory speeds to disk
speeds, you'll find that the cost of doing the memory transfer is
miniscule compared to the disk I/O.  Let's just suppose that you're
running at 33MHz and that it takes 20 cycles per byte (a wildly
pessimistic estimate) to copy memory.  So to copy a 512-byte buffer
takes 512*20 = 10240 cycles, or 10240/33 uSec, or .31 milliseconds.
This is less than 1/50th of a single disk rotation on a typical drive!
Third, this only affects disk I/O, it shouldn't affect programs that are
running in memory (except when other processes are doing disk I/O, they
will have a small amount less CPU time to play with).

(The .31ms result is so low -- so much lower than I expected -- that I'm
wondering if I didn't blow a step somewhere.  Anyone see a mistake?)

> Before ODT came out, we didn't see this often because > 16MB of memory
> was the exception rather than the rule on x86 hardware. ODT's hunger
> for main memory has pushed this ISA amonaly into many unsuspecting 
> faces. 
> 
> Prove this by yanking the top 16MB out, and seeing if you still have
> the problem. Don't let swapping (if any) fog your results.
> 
> Fix == EISA

Ok, but pulling the top 16MB will also fix the not-enough-cache problem
that's *really* making the system slow.  ;-}

>Bela<
Newsgroups: biz.sco.general
From: perry@johann.jpunix.com (John Perry)
Subject: .plan and remote fingering problem
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Content-Type: text
Cc: perry@johann.jpunix.com (John Perry)
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Tue, 22 Dec 1992 21:37:30 GMT
Content-Length: 935       
Precedence: bulk

Hello Everyone,

	I had an interesting problem pointed out to me when a friend
tried to "finger" my account on my SCO ODT 2.0 system.

	When he "fingered" my account, rather than display the
contents of the .plan file, the finger command stated there was no
.plan file. When I logged in to check there was in fact a .plan file
there. When I fingered myself locally on the machine, the .plan file
was displayed as it should have been. But if I finger my account from
a remote host, the contents of the .plan file is NOT displayed and
instead says "No Plan". The permissions on the file are set so all can
read the .plan file but only the owner can write. Can someone tell me
what I need to do so that my .plan file is displayed when I am
remotely fingered?

-- 
 John A. Perry  -  perry@johann.jpunix.com
                   jpunix!johann!perry
From: eah@xenitec.on.ca (Ed Hew)
Newsgroups: biz.sco.general
Subject: Re: Slow login and u386mon
Date: 31 Dec 92 21:55:24 GMT
Organization: XeniTec Consulting, Kitchener, Ontario, CANADA

In article <76@shady.UUCP> kevin@shady.UUCP (Kevin Smith) writes:
>My guess is, and I refuse to accept responsibility if wrong, that you
>can edit these files in multiuser.
>	[...]
>Make backups of the files before starting and ask everyone to sit still
>while you are editing (i.e. no logins or logouts).

You can do just about anything while multi-user.  That doesn't imply
that it's a particularily good plan.

I come from the school of little faith.  You're going to trust all
your end-users to sit still just because you asked the ones at hand
to do so?  You may even go so far as to turn off all your modems and
shut down your TCP/IP to ensure no one from outside accidently tries
to log in.  Sure enough, somebody is going to come out of the washroom
and want to get back to work.

Do yourself a favour and take the system single-user for the 5 minutes
this exercise will take.  Mess up, and cleanup will almost certainly
take longer.
--
  Ed. A. Hew,    <edhew@xenitec.on.ca>    ....!uunet.ca!xenitec!eah
  XeniTec Consulting Services, Kitchener ON, Canada +1 519 570 9848
          [biz.sco.* newsgroups and mailing lists godfather]
From: develop@aerie (PRN Development Lab)
Newsgroups: biz.sco.general
Subject: Xenix EFAULT on read
Date: 31 Dec 92 21:14:58 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Cc: develop@mthvax.cs.miami.edu (The Eagle's Aerie)
Precedence: bulk

Our system occasionally gives EFAULT errors on read system calls
for valid buffer addresses.  This happens under Xenix 2.3.2 286
and also 2.3.4 for 386, using large-model 286 binaries.
In our case, the file is being extended, more than one process
has the file open, and the buffer address is within the sbrk area.
When an EFAULT occurs, the data is not read.  Subsequent reads to
the same file seem to also give the error.
 
Has anyone seen this problem before?  Anyone have a fix?
 
This problem is crashing our application more than once per day
on any system that is multi-user for our database, so it is a
critical problem for us.  
 
Alan Wendt
 
-- 
 _ __   _ __   _ __
' )  ) ' )  ) ' )  )   PRN Development Lab
 /--'   /--'   /  /    mthvax!mamia!aerie!develop
/      /  \_  /  (_    9300 SW 87 Ave. Miami Florida 33176 USA
Newsgroups: biz.sco.general
From: vancleef@netcom.com (Henry van Cleef)
Subject: UUCP woes on 3.2.0 to 3.2.4 upgrade
Organization: Netcom--posted from Andover, Mass.
Distribution: biz
Date: Mon, 4 Jan 1993 01:08:56 GMT

As it says, I upgraded my machine from 3.2.0 to 3.2.4 last week, and now
uucp and cu won't play.  I've looked at all the obvious things:

1. permissions correct on /dev/tty1A, port set off in inittab.
2. Devices and Systems entries were copied from the old installation.
3. Configuration is Tbit 1000.  I have tried using the old dialTBIT
binary in case the new one was different.

Symptom:  Dial and connect work OK, and I get the login: response.
But when I try to send (either uucico OR cu) characters don't echo
(cu) and uucico never sees sword: or Shere=sysname (uutry -x9).
The returns on cu echo one letter per cariage return and evidently are
sent that way.  

Kermit works fine through the same port, and I tried going straight to
connect so that the modem would not see the Kermit dialer; dialed in
manually.  Looks like a cbreak problem with the port, but if that's the
case, why does kermit play happily?  Any bright ideas?
-- 
Hank van Cleef  vancleef@netcom.com vancleef@tmn.com  Andover, Mass.
Unix systems consultant---kernel, device drivers, networking, X11
SysV, BSD, Sun, Ultrix, AIX, SCO. Porting a specialty. 
	     The Union Institute  History of Science
Newsgroups: biz.sco.general
From: georgn@noweh.com (Georg S. Nikodym)
Subject: Re: sigaction() and rescheduling interrupted system calls
Followup-To: biz.sco.general
Organization: Noweh Software, Mississauga, CANADA
Date: Wed, 23 Dec 1992 07:23:31 GMT

In article <64@shady.UUCP> kevin@shady.UUCP (Kevin Smith) writes:

   In article <1992Dec16.100827.10097@dd.dk> wes@dd.dk (Mads Westermann) writes:
   :>I'm running SCO ODT 2.0 (SCO Unix 3.2.4) and have run into the problem
   :>of rescheduling an interrupted system call after a signal has occured.
   :>
   :>In my AT&T Sys V.4 manual there's reference to a SA_RESTART flag on
   :>the sigaction() function that causes interrupted system calls to be
   :>transparently restarted.
   :>
   :>In my Ultrix 4.2 manual there's reference to a SV_INTERRUPT flag that
   :>does the same.
   :>
   :>My SCO manual doesn't know of any such thing - It seems like the only
   :>possibility is to manually check the return code and the errno from the
   :>system call and manually restart the system-call if errno equals EINTR.
   :>
   :>Has anybody solved the problem ? Is there a way to solve it ?
   :>
   :>Any input on this subject would be greatly appreciated.
   :>

   Since most system calls are not interruptable the problem is not as big as
   it might seem.  Terminal and printer I/O, pause(), wait(), messages and
   semiphores are about it (and probably any network/socket read and writes)
   Ok so there are a few.  Your basic disk and tape IO are, however, not
   interruptable so the interrupt actually occurs immediatly after the system
   call.

Interrupted system calls are a reality and should be dismissed out of
hand.  One of the more annoying signals that usually needs special
treatment for this is SIGWINCH (I'm not sure that it exists in SCO,
but certainly does in the BSD and SVR4 worlds).  But this is secondary
really since SCO UNIX claims to be POSIX.1 conformant.  Must it not,
therefore, have a sigaction() call with all the trappings?
-- 
Georg S. Nikodym  -  (416) 272-5198 / 720-4729
Noweh Software - Mississauga, Ontario, CANADA
UUCP:	{comspec.com, lsuc.on.ca, uunet.ca}!noweh!georgn
RFC822:	georgn@noweh.COM
Newsgroups: biz.sco.general
From: david@infopro.com (Dragon [David Fiedler])
Subject: Re: Performance degradation under SCO UNIX
Organization: InfoPro Systems: Writers, Consultants, and Dragons
Date: Mon, 21 Dec 92 05:56:34 GMT

mike@pacsoft.com (Mike Stefanik) writes:

>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.

Is this big fancy fast box still on the outmoded ISA bus? If so, try
booting with mem=/L added to the end of the boot string and I bet you see
some results...
-- 
David Fiedler UUCP:infopro!david Internet:david@infopro.com or david@utoday.com 
USMail:InfoPro Systems, PO Box 220 Rescue CA 95672 Phone:916/677-5870 FAX:-5873
"Do I still have to sleep in the cupboard?"
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: biz.sco.general
Subject: Re: speed of high-buffers, Re: Performa[n]ce degradation under SCO
Date: 25 Dec 92 05:21:36 GMT
Organization: Izot's Swamp

Bela Lubkin <belal@sco.COM> writes:

> Dave Van Allen wrote:
> 
> > If you don't have the cache, then yanking the extra memory is your only 
> > recourse anyway. Right?  
> 
> No, actually there's a much better one.  Simply disable the external
> cache completely, but *leave the internal cache enabled*.  Now, I
> realize that not all motherboard/BIOS combinations allow this, but if
> yours does, do it.  Remember those performance figures: no cache=1,
> external only=3, internal only=8, both=11.  So with internal only, you
> run about 75% of full speed, which is much better than (sometimes full
> speed) (sometimes 1/11 speed).

   Does not the internal cache cover all of memory anyway?  In theory, a well-
designed board should give (sometimes full speed)(sometimes 8/11ths speed).

   One very definite problem with this discussion is that we've got 
participants ranging from experienced software engineers through hackers 
who'll benchmark *anything* to users who don't care why as long as they're 
getting the performance they paid for; however, we don't have any PC hardware 
designers around... 

  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_
Xref: sparky biz.sco.general:4919 comp.mail.uucp:2481
From: bill@twg.bc.ca (Bill Irwin)
Newsgroups: twg.sco-list,biz.sco.general,comp.mail.uucp
Subject: Re: Trouble configuring UUCP on TCP/IP
Keywords: sco uucp tcp/ip
Date: 1 Jan 93 01:21:25 GMT
Reply-To: bill@twg.bc.ca (Bill Irwin)
Organization: The Westrheim Group, Vancouver, B.C., Canada
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk


unilabs!chare@uunet.UU.NET (Chris Hare) writes:

: In article <2808@twg.bc.ca> bill@twg.bc.ca (Bill Irwin) writes:
: >
: >I am having trouble configuring UUCP to use the TCP/IP network as
: >its "device".  I have two systems, both running SCO UNIX 3.2.4,

: I went through this recently.  this is what you need to do.

: In Devices, create an entry which reads

: TCP TCP,e     -       Any     TCP     540

: Note:  this instructs uucp to use the 'e' protocol, and to connect on port
: 540.

I have the uucico accessing the TCP device now, but it is failing
after the password is given to the remote system.  Following is a
portion of the -x9 log:

mchFind called (SystemB)
list (rmail) num = 1
fillFlds: entered
fillFlds: returning
list (/) num = 1
list (/) num = 1
list (ALL) num = 1
_Request (TRUE), _Switch (TRUE), _CallBack (FALSE), _MyName (), _Commands ALL
chdir(/usr/spool/uucp/SystemB)
conn(SystemB)
ProtoStr = e
Device Type TCP wanted
Internal caller type TCP
tcpdial host SystemB, port 540
family: 2
port: 7170
addr: 02029384
set interface TCP
processdev: calling setdevcfg(uucico, TCP)
getto ret 5
sendthem (^M)
expect: (gin:)
login:got it
sendthem (systema^M)
expect: (word:)
 Password:got it
sendthem (password^M)
msg > Login incorrect.^Jimsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg >imsg

The ">imsg" stuff keeps going and going until the log is is over
700Kb in size.  Then it fails.  I have seen this type of output
on a normal modem connection before, but can't recall what it is
a symptom of.

Any ideas?

: BTW, don't forget to uncomment the line in /etc/inetd.conf for uucpd on
: both systems.

I didn't forget.  Thanks.

BTW, Rick Gwilt says hi.  He says you were his manager at Coreo.
-- 
Bill Irwin    -       The Westrheim Group     -    Vancouver, BC, Canada
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uunet!twg!bill            (604) 431-9600 (voice) |     Your Computer  
bill@twg.bc.ca            (604) 430-4329 (fax)   |    Systems Partner
Newsgroups: biz.sco.general
From: darkshot@rock.concert.net (Michael B Garrett -- Chudys)
Subject: Two things....
Organization: CONCERT-CONNECT -- Public Access UNIX
Distribution: usa
Date: Mon, 28 Dec 1992 21:26:13 GMT


I've lost the patch for the scologin bug, and also the address of whoever
it was that sent it to me. Someone cleaned up a little too well, it seems.
Anyway, if someone has it, I'd appreciate. 

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) ?

Thanks in advance,

'Shot
From: darkshot@rock.concert.net (Michael B Garrett -- Chudys)
Newsgroups: biz.sco.general
Subject: Re: Logitech C9 Serial Mouse at 9600 Baud
Keywords: logitech serial mouse
Date: 31 Dec 92 06:35:13 GMT
Organization: Not much

I would say to look in the mkdev mouse script, offhand. You should find the
needed "stuff to change" in there. (I'm logged on now with a CP/M machine
so I can't check it for you, but that's where I'd look first for clues).

Query: Why in hell? What benefits are gained by running a serial mouse
at 9600 baud? If it's on the typical COM1, and not on a co-processed
multiport server, I'd expect it to have a detrimental effect systemwide.
I could be wrong, but running a Telebit Worldblazer on COM2 at 9600+ 
REALLY bogs my system down.....I dunno about a mouse, but I expect it
would be much the same situation. Hard to say.

'Shot
Newsgroups: biz.sco.general
From: sl@wimsey.bc.ca (Stuart Lynne)
Subject: Re: Logitech C9 Serial Mouse at 9600 Baud
Organization: Wimsey Information Services
Date: Thu, 31 Dec 1992 09:03:14 GMT
Keywords: logitech serial mouse

In article <1992Dec31.063513.10725@rock.concert.net> darkshot@rock.concert.net (Michael B Garrett -- Chudys) writes:
>Query: Why in hell? What benefits are gained by running a serial mouse
>at 9600 baud? If it's on the typical COM1, and not on a co-processed

It makes the mouse more responsive by reducing the latency of the data transfer.

>multiport server, I'd expect it to have a detrimental effect systemwide.
>I could be wrong, but running a Telebit Worldblazer on COM2 at 9600+ 
>REALLY bogs my system down.....I dunno about a mouse, but I expect it
>would be much the same situation. Hard to say.

I think it would be pretty hard to get the same data flow from a mouse as
file xfer through a modem :-)


-- 
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: kevin@shady.UUCP (Kevin Smith)
Newsgroups: biz.sco.general
Subject: Re: BIOS shadowing, Re: Performance degradation under SCO UNIX
Date: 31 Dec 92 18:20:55 GMT
Organization: ShadeTree Software, Inc.

In article <9212300958.aa07997@scoke.sco.COM> belal@sco.COM (Bela Lubkin) writes:
:>
:>(*) 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<

On my AMI bios you can relocate the RAM reserved for shadowing, thus
giving me another 256K in the never ending battle for more memory.
-- 
	    | 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
From: dave@das13.snide.com (Dave Snyder)
Newsgroups: biz.sco.general
Subject: Re: SCO Unix V/386 3.2.2 C2, Remove lines from /etc/passwd?
Date: 25 Dec 92 15:39:53 GMT
Distribution: na
Organization: Snide Computer Services - Folcroft, PA

In article <1992Dec23.030440.13374@news.acns.nwu.edu> jlacour@casbah.acns.nwu.edu (John Lacour) writes:
>I have SCO Unix 3.2.2 installed w/ security enabled.  Id like to remove
>entries from /etc/passwd.  Is it possible without screwing up the protected
>databases?  I can easily disable the accounts, but there are several of them
>and I'm someone who cares about aesthetics.
>
Do the following steps:

  1)  Delete the entry from /etc/password
  2)  Delete the entry from /etc/auth/subsystems/dflt_users
  3)  Delete the file from /tcb/files/auth/?
      (ie: if you want "john" removed, the file is /tcb/files/auth/j/john)
  4)  Delete the home directory
  5)  Delete the cronjob (if applicable)

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