HDTenEightyP/NetNews huggingface dataset:
From: belal@sco.COM (Bela Lubkin)
Newsgroups: biz.sco.general
Subject: Re: speed of high-buffers, Re: Performa[n]ce degradation under SCO
Date: 25 Dec 92 20:43:02 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

Geoffrey Welsh wrote:

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

That was my theory, too.  It is not borne out in practice; and I more or
less understand why, after discussions with a few hardware folks.

In every system, there are some memory areas which must not be cached.
For instance, the area between 640K and 1M may be used by I/O devices
which should not be cached.  Some part of that range may also be
occupied by (for instance) a RAM copy of the BIOS ROM, which would
benefit a lot from caching.  So current designs usually have fairly fine
control of which parts of memory are cached and which aren't.  They
don't usually give the user access to this fine control, though.

If an area should not be cached, it Should Not Be Cached.  Your system
would not work if the external cache cached your I/O ports, and it still
wouldn't work if only the internal cache did that.  Somewhere in one of
the ASICs that makes up a typical "AT chipset", a signal is generated
which is routed to a "disable the cache" pin on both the external cache
chip, and on the 486.  Yes, the 486 has an external signal meaning "I,
the motherboard, tell you, the 486, that you shouldn't cache this
address".

So we have areas which should not be cached because doing so would screw
them up.  We also have areas which, as we've seen before, should not be
cached simply because the external cache can't reach them, doesn't have
enough bits in its tag RAM to keep track of them.  For such areas, the
"AT chipset" *should* be smart enough to assert the "disable the cache"
signal only to the external cache hardware.  But in many designs it
isn't.  In many designs, the fact that an address is outside the
external cache's cachable range causes a "disable the cache" signal to
be sent to the internal cache.

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

Yep.  You know any we can pull in?  ;-}

>Bela<
From: watson@carssdf.UUCP (- Self Empl. Sys.Integrator)
Newsgroups: biz.sco.general
Subject: TCP on Notebook PC, or SLINK on Parrallel
Keywords: TCP Notebook
Date: 24 Dec 92 17:59:11 GMT
Organization: John Watson (Self Employed System Integrator)

I would like to run TCP to my (yet to be purchased) notebook to load up
large directries, 40 Mb or so.  I can't use my 8013EPT cards without buying
a large, expensive, awkward docking station.  SLINK might be ok but I don't
know how bad the transfer rate would be.

Some E-net cards are available for the parrallel port, but I don't think
they are SCO TCP supported. I can't see how they could be any faster than
a parrallel link using SLINK like lap-link does it.

Has anyone written a parrallel driver suitable for SLINK?

Alternativly, I could live with dedicating a 100Mb file system on my host
386 and using some kink of dos program transfer the whole thing to/from
the lap top.

John Watson
Newsgroups: biz.sco.general
From: cbuckley@unix1.tcd.ie (Colm Buckley)
Subject: Re: Changing SCO kernel to accept # !/bin/sh instead of :
Organization: Trinity College, Dublin
Date: Tue, 22 Dec 1992 21:46:40 GMT

>>> 	I saw a posting a while ago on how to modify the SCO kernel to
>>> accept # !/bin/sh notation on shell scripts instead of just :.  Could
>>> someone re-post this to me or tell me how?  
>>> 
>> On a SCO Unix 3.2v4.0 (or above) system (which includes ODT 2.0), make
>> sure the following line exists in /etc/conf/pack.d/kernel/space.c and
>> rebuild your kernel:
>>
>> int hashplingenable  = 1;   /* set 1 if "#!" recognized by exec */

You can have some problems with this, if you are using shells other than sh
- SCO's incredibly broken csh does weird things if the SHELL environment
variable and/or the alias for "shell" aren't set up properly. I don't use
it anymore, so I can't remember exactly what happens - however the problem
was that all the standard executable shell scripts use the ':' instead of
the '#! /bin/sh' system. I ended up writing a C program (could easily have
been a shell script either) which changed the first line of these files from
':' to '#! /bin/sh'.

-- 
Colm.
+-------------------------------------+----------------------------------+
| Colm Buckley                        | "My program doesn't work."       |
| Department of Computer Science,     | "You forgot the semicolon."      |
| Trinity College, Dublin 2, Ireland  | "But..."                         |
|                                     | "Line 376. Check."               |
| cbuckley@unix1.tcd.ie               | "But..."                         |
| CBUCKLEY@vax1.tcd.ie                | "Trust me."                      |
+-------------------------------------+----------------------------------+
Newsgroups: biz.sco.general
From: sheldon@iastate.edu (Steve Sheldon)
Subject: Re: NCSA Telnet connect vs SCO: Fix
Organization: Iowa State University, Ames IA
Date: Wed, 23 Dec 1992 14:59:02 GMT

In <-12366655@nemesis> uhclem@nemesis.UUCP writes:

>Problem:  I am fairly certain that the problem is with the SCO TCP/IP
>system, and NCSA is triggering it (KA9Q is stupid and doesn't do much,
>if any negotiation).  So SCO should investigate why this happens too.

 Hmm, we're running ODT 2.0 here and I haven't been having this problem.

 Perhaps it has been fixed?
-- 
sheldon@iastate.edu                Steve Sheldon
Project Vincent                    ICSS Resource Unit
SCO ODT, Arc/Info, Atlas GIS       2142 Agronomy Hall
                                   Iowa State University
Newsgroups: biz.sco.general
From: bill@Celestial.COM (Bill Campbell)
Subject: Re: Tape drive on floppy controller, no fun
Organization: Celestial Software, Mercer Island, WA
Date: Thu, 24 Dec 1992 17:53:24 GMT

In <9212231532.aa13151@dlpco.dlpco.COM> lee@dlpco.dlpco.COM (Lee Penn ) writes:

:DLP Votes DOWN THUMBS on Colorado J-Tape drives.  They should be 
:avoided at all costs.  We have several customers who have junked 
:these drives.  One just spent 2 solid weeks working with the 

This is the same experience we had when we last used CMS drives
about 3 years ago.  We only have one client who's still using his
and it's been replaced at least 4 times because of hardware
failures (only the first time was free).

:"experts" at Colorado.  He sometimes could write to the tape, 
:sometimes not, sometimes even read the tape he wrote to most of 
:the time not.

Sounds familiar.  CMS appears to know little or nothing about
Xenix/UNIX.  For some strange reason they decided to change their
/dev names from one release to another breaking some shell
scripts I had written (I guess they think people will use their
brain-dead backup utilities).

:Plus, the problem of not being able to boot from a floppy and 
:access the device.

Now why would anyone want to anything like that :-).

:I DON'T think they work well at all and would never recommend 
:them.

I hate it when I come across them.  I got a call to set up a new
UNIX system for a local school district and asked what kind of
tape drives they had (upgrading from old 286 Xenix system).  My
involuntary reaction of ``oh God!'' when she said the new system
had a CMS drive upset the client.  Then she told me that the
machine has a 200MB IDE drive and I knew it had been spec'ed by a
DOSoid (I had hoped to be able to take my external SCSI drive to
the client site to transfer data).

Bill
-- 
INTERNET:  bill@Celestial.COM   Bill Campbell; Celestial Software
UUCP:   ...!thebes!camco!bill   6641 East Mercer Way
             uunet!camco!bill   Mercer Island, WA 98040; (206) 947-5591
SPEED COSTS MONEY -- HOW FAST DO YOU WANT TO GO?
From: bob@consult.UUCP (Bob Willey)
Newsgroups: biz.sco.general
Subject: Re: BIOS shadowing, Re: Performance degradation under SCO UNIX
Date: 1 Jan 93 14:52:28 GMT
Reply-To: bob@consult.UUCP (Bob Willey)
Organization: CCS Enterprises, Inc.

In article <19@das13.snide.com> dave@das13.snide.com (Dave Snyder) writes:
>} 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
>post however got me thinking... did the DOS guy who built my machine do
>something unnecessary or even worse, something harmful in my BIOS.
>
>This is how the AMI BIOS for my 386/40 machine running SCO Unix 3.2.4.1 is
>set up:
>    Video   ROM Shadow    C000,32k    Enabled
>    Adapter ROM Shadow    C800,32k    Disabled
>    Adapter ROM Shadow    D000,32k    Disabled
>    Adapter ROM Shadow    D800,32k    Disabled
>    System  ROM Shadow    F000,64k    Enabled

Disable ALL of them.  We have seen various problems with them enabled,
and as previously mentioned SCO does not use the BIOS except during
the boot process.  So you get no real advantage.

>Does this look right?  My machine runs fine except for the problem with
>the tape drive and floppy drive not being able to work simultaneously.
>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.  Any pointers would be appreciated.

On one note:  You DOS weiney can be a REAL problem if configuring a system
for SCO.  If they don't understand how Xenix/UNIX works, they can create
all sorts of problems for you, like installing cheap parallel ports that
do not support IRQ and force the system into polling (can be a drastic
impact on the machine performance).  You will not see a lot of these 
problems in DOS.

Your problem with the tape drive/floppy working at the same time, could
be several things.  The most likely is that the controller for the tape
drive is set for IRQ 6, which is the IRQ for most floppies.  You might
want to look into this.  On most systems you have IRQ's as follows:
3-com2 4-com1 5-lpt2 6-floppy 7-lpt1   .  So if not 2nd parallel port
you will usually have IRQ 5 available.  You can sometimes use IRQ 2,
but you may have to reference it slightly different (25?).

-- 
>.. 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: mhl@genco.bungi.com (Mark Levy)
Newsgroups: biz.sco.general
Subject: Re: SCO Compability with OS/2?
Keywords: SCO ODT OS OS/2
Date: 27 Dec 92 01:56:15 GMT
Reply-To: mhl@genco.bungi.com (Mark Levy)
Organization: Gentry & Assoc. Excelsior Springs, MO

To: alexl@alvarez.COM
Subject: Re: SCO Compability with OS/2?
Newsgroups: biz.sco.general
Organization: Gentry & Assoc. Excelsior Springs, MO
Cc: 
Bcc: 


RE: Alternate root file systems

There doesn't seem to be a problem in specifing an alternate root
file system, and I have inplemented them on a number of SCO UNIX
machines I have installed.  The reason being that it can be much 
easier and faster to get a machine up and running again after a
crash (or someone being particularly nasty and doing something like
deleting all the device files and unix) than by using a floppy set.

I do believe that there is a restriction, however, that the root file
system reside within the first 1024 cylinders of the drive.

I seem to recall the syntax as being as follows

boot: hd(40,X)unix root=hd(40,X) swap=hd(40,1)

if booting from the hard drive, where X is the minor number of the 
alternate root filesystem, and hd(40,1) is the default swap device.

if booting from a floppy, just leave out the hd(40,X)unix part.

Good luck.

BTW...

The only way I was ever able to get OS/2 to co-reside with both SCO
UNIX and DOS was to install DOS first, then OS/2 in dual boot mode,
and then SCO.  The dual boot mode of OS/2 never worked, so to boot
UNIX, I would type unix at the boot prompt.  To boot to OS/2, I'd
type dos at the boot prompt.  To boot to DOS, I had to boot from a 
floppy

Mark
From: lee@dlpco.dlpco.COM (Lee Penn )
Newsgroups: biz.sco.general
Subject: Re: Tape drive on floppy controller, no fun
Date: 23 Dec 92 20:27:41 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

>From uunet.uucp!xenitec.on.ca!news Tue Dec 22 19:16:10 1992
>To: xenitec.on.ca!distribution@uunet
>Path: xenitec!olivea!uunet!shady!kevin
>From: Kevin Smith <xenitec.on.ca!uunet!shady!kevin@uunet>
>Newsgroups: biz.sco.general
>Subject: Re: Tape drive on floppy controller, no fun for crowbar+restore
>Message-Id: <65@shady.UUCP>
>Date:  Mon, 21 Dec 1992 11:45:00 -0500
>References: <1992Dec16.212627.27201@xenitec.on.ca> <Z2J1VB2w165w@zswamp.UUCP>
>Organization: ShadeTree Software, Inc.

>In article <Z2J1VB2w165w@zswamp.UUCP> geoff@zswamp.UUCP (Geoffrey Welsh) writes:
>:>edhew@xenitec.on.ca (Ed Hew) writes:
>:>
>:>> Next time you'll likely buy a different tape drive.
>:>
>:>   I think that it's worth emphasizing this: the Jumbo tape drives from 
>:>Colorado Memory Systems work well, provided that you buy the separate 
>:>controller card (to get away from the floppy controller conflict, as you 
>:>mentioned in your article), the UNIX software, etc... and, by the time you've 
>:>bought all of the pieces, you've spent a significant fraction of the money it 
>:>would have cost to put in a QIC-02 tape drive of higher capacity... and Jumbo 
>:>tapes need to be preformatted (a slow process not shared by QIC-02 tapes)! 
>:>
>:>   It may cost you a few more bucks, but in this case it's worth sticking to 
>:>the old standard ways.

>One of my customers has a colorado drive with the separate controller,
>under xenix, and we still couldn't get it to work from a floppy boot (even
>with help from their tech support).  Finally punted the drive.
>-- 
>           | Email - !shady!kevin uunet!shady!kevin kevin%shady@uunet.uu.net
>Kevin Smith | Voice - (908) 874-7980
>           | Mail  - ShadeTree Software, Inc., 192 Capricorn Dr. #10,
>           |         Somerville, NJ  08876


DLP Votes DOWN THUMBS on Colorado J-Tape drives.  They should be 
avoided at all costs.  We have several customers who have junked 
these drives.  One just spent 2 solid weeks working with the 
"experts" at Colorado.  He sometimes could write to the tape, 
sometimes not, sometimes even read the tape he wrote to most of 
the time not.

Plus, the problem of not being able to boot from a floppy and 
access the device.

I DON'T think they work well at all and would never recommend 
them.
================================================================================
Lee Penn,  DLP Technologies, Inc.                     Voice: 513 232-7791
SCO Advanced Product Center                           FAX: (513) 232-7801
7444 Jager Ct.
Cincinnati, OH  45230-4344                           email: lee@dlpco.COM
Newsgroups: biz.sco.general
From: tomh@wes.on.ca (Tom Haapanen)
Subject: Re: CD's and SCO NFS
Organization: Waterloo Engineering Software
Date: Mon, 21 Dec 1992 16:02:46 GMT

tomh@wes.on.ca (Tom Haapanen) writes:
>> [About sharing a CD-ROM drive over NFS]
>> Yes, it apparently can be done.  However, our system is just over a year
>> old, and I'll have to upgrade everything in order to run NFS 1.2.  To
>> upgrade the OS, DS, TCP/IP and NFS will cost us almost $1100 from SCO.
>> It'd be cheaper for me to buy a CD-ROM drive for every PC!

>> On the other hand, ESIX has a competitive upgrade available for $508, and
>> complete BSD/386 costs under $1000 -- including X and source.

lee@dlpco.dlpco.COM (Lee Penn ) writes:
> Be warned.  Everex just announced that they are losing money like
> crazy.  I cannot believe that ESIX will be on their list of things
> to keep as I doubt that it can be profitable for them given their
> current problems. [...]  Before you consider ESIX, be really careful.

Thanks!  This is the great thing about the Net...

>> I'm happy with SCO's tech support, hardware compatability and performance,
>> but their upgrade pricing sucks rocks.  Right now I'm sufficiently pissed
>> off that I'm seriously considering switching.

This still stands: we paid about US$ 2000 for our Unix+networking, and less
than a year later we're asked to fork over another US$ 1100.

Current options include buying 2 more CD-ROMs for PCs (US$ 750), running
Windows for Workgroups alongside NFS (US$ 200), BSD/386 (US$ 1000, but
apparently the SCSI driver still has a nasty bug), and making do without a
CD-ROM.  Sigh.

[ \tom haapanen    "i don't even know what street canada is on" -- al capone ]
[ tomh@wes.on.ca                   "trust the programmer" -- ansi c standard ]
[ waterloo engineering software      "to thine own self be true" -- polonius ]
Xref: sparky biz.sco.general:4776 comp.unix.sysv386:17571
From: kevin@shady.UUCP (Kevin Smith)
Newsgroups: biz.sco.general,comp.unix.sysv386
Subject: Re: sigaction() and rescheduling interrupted system calls
Keywords: sigaction system call sco reschedule
Date: 21 Dec 92 08:16:25 GMT
Followup-To: biz.sco.general
Organization: ShadeTree Software, Inc.

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.
-- 
	    | Email - !shady!kevin uunet!shady!kevin kevin%shady@uunet.uu.net
Kevin Smith | Voice - (908) 874-7980
	    | Mail  - ShadeTree Software, Inc., 192 Capricorn Dr. #10,
	    |         Somerville, NJ  08876
From: eah@xenitec.on.ca (Ed Hew)
Newsgroups: biz.sco.general
Subject: Re: Configuring an Adaptec 1542B ...
Date: 31 Dec 92 21:41:27 GMT
Organization: XeniTec Consulting, Kitchener, Ontario, CANADA

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.
>Has anyone had any problems using the higher settings?  A friend (who set
>up this system) claims to have had some kind of disk corruption occur when
>the higher speeds were used.  What else needs to be changed (if any) to
>use the higher settings?
>	[...]

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 _do_ want to be careful that you don't tell your host adapter
to try to talk to a device at a rate exceeding that device's
physical capabilities.  This brings to mind a little experience a
while back....

I had installed a new scsi host adapter (which one doesn't matter
in this context), and plugged a couple of nice fast drives into it,
and installed ODT 2.<something I'm not supposed to talk about>.  A
few days later I went to support a 3rd drive, an older 600ish meg
Maxtor XT-8702S that I had sitting around.  The host adapter refused
to recognize it.  After a bit of fiddling, I broke down and pulled
out the drive doc and low and behold, it clearly stated that that
drive is rated for a _maximum_ SCSI bus transfer rate of 4.8
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
the drive was recognized and I've been using it ever since.  Note
that I'm still pushing my luck with it just a wee bit, but so far,
so good.  Manufacturer's tolerences are likely close enough in this
case, with this particular drive.

If you try to exceed the max transfer rate by too much, if you're
lucky, your host adapter will simply ignore the slow drive.  If
you're not so lucky, it will talk to it and you'll think all is
well, but all bets are off; you may at some point get all kinds
of bizarre corruption.  Beware.
--
  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]
Newsgroups: biz.sco.general
From: "Paul A. Fischer, Sr UNIX Sys Consultant" <paul@openage.com>
Subject: Re: time command
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Thu, 31 Dec 1992 18:14:55 GMT
Precedence: bulk

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

Interesting view point.  Realizing also that any multiport board will also off 
load the i/o processing from the CPU, and buffer the data.

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