Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-ncis!lll-lcc!ames!nrl-cmf!ukma!rutgers!bellcore!faline!thumper!ulysses!andante!alice!debra
From: debra@alice.UUCP (Paul De Bra)
Newsgroups: comp.unix.microport
Subject: Re: 286 serial port woes
Keywords: UNIX 286, uucp
Message-ID: <8766@alice.UUCP>
Date: 15 Jan 89 21:22:07 GMT
References: <11871@netsys.COM>
Reply-To: debra@alice.UUCP ()
Distribution: na
Organization: AT&T, Bell Labs
Lines: 48

In article <11871@netsys.COM> len@netsys.COM (Len Rose) writes:
>I am evaluating V/AT 2.4 on an 8 mhz clone 286 with 1 meg
>of ram. Can't reliably sustain a uucp transfer at speeds
>greater than 2400 baud. The system is extremely slow ,and
>is virtually unusable with a 16 bit compress running in the
>background.
>
>I despise Xenix yet it seems that SCO Xenix runs rings around
>V/AT on the same hardware. 
>
>My question is: Is V/AT really this bad,and if so, how can they
>still be in business? I am sure the hardware isn't the blame since
>Xenix performs "acceptably" give the fact that it's just a 286.
>

There are several aspects about V/AT that make it slow. I have tested
an earlier version and my conclusion at that time was the same as yours:
How can they still be in business selling this software that is virtually
unusable. There are however a few explanations:
1) The kernel is a large model program, compared to a middle model program
   in SCO Xenix. This has 2 implications:
   - it is slower, because accessing data is slower in the large model.
     however, it's not really that bad.
   - it is BIGGER. With only 1 meg V/AT is incredibly slow because there
     is not much room left for processes. However, with more memory having
     the large model kernel has the advantage that you can make system
     tables larger to increase the overall performance, and increase system
     limits on open files, processes, I/O buffers, etc.
2) Most newer 286 machines run at 10Mhz without wait states or faster
   (12, 16 or even 20Mhz). As the number of cpu-cycles per second for the
   "household" of the kernel is more or less fixed (a fixed number of clock
   interrupts per second) the kernel takes up a larger fraction of the
   available cpu-time on a slower machine.
3) V/AT used to have incredibly slow disk access and throughput (compared
   to Xenix on the same machine). This may be hardly noticeable when you
   are working single user and do not have anything in background, but in
   your case with a compress in background, that is a) using lots of cpu-
   cycles, b) doing disk I/O and c) being swapped in and out as your system
   does not have enough memory, the system ends up "thrashing".
I do believe V/AT can be quite comfortable on faster 286 machines with at
least 2 meg.

Paul.

-- 
------------------------------------------------------
|debra@research.att.com   | uunet!research!debra     |
------------------------------------------------------