XFree1-2 + 386BSD performance
M.C. Wong
I have a question about the performanc of running XFree1.2 on
386BSD 0.1. In multi-user mode running 3 xterms, xeyes, xclock,
xload and xbiff, when I do serious compiling in one of the window,
I realize that the performance of the overall X activities are
intolerable slow and it chokes very very much, and I can hardly
see my mouse moving/appearing on the screen for 5-10 seconds.
I wonder :
1) does the system resource limit (set by limit from tcsh) has
great effect on the performance ?
2) I am running on 486/33 with 16M of RAM, is this considered
the expected performance ? Besides I am running on a local
bus board.
3) has anyone tried fine-tuning the performance of 386BSD + XFree
such that it runs better ? If so, can u please post some
useful guidelines, as I think many of us will like to know.
4) Is the choking a pure limitation of the 486 CPU power, or
is it the size of memory ? If I go on to > 16M, say 20M,
will that gives me better performance ?
5) Does the size of the swap space affect that ? If so, how can
I increase the swap space size ?
Many thanks in advance!
Marc Wandschneider
>Hi,
> I have a question about the performanc of running XFree1.2 on
>386BSD 0.1. In multi-user mode running 3 xterms, xeyes, xclock,
>xload and xbiff, when I do serious compiling in one of the window,
>I realize that the performance of the overall X activities are
>intolerable slow and it chokes very very much, and I can hardly
>see my mouse moving/appearing on the screen for 5-10 seconds.
This is rather bizarre---I ran XFree86 and 0.1 on my 486/50; and
with Xeyes, Xclock, and three compiles running, the load average
hit about 2.27, but the machine was still quite responsive, and
the mouse and windows still moved around as fast as they had
before I started all the builds.
Toodlepip!
Marc 'em.
--
----------------------------------------------------------------------------
st...@cs.mcgill.ca SOCS Staff, McGill University
Marc Wandschneider (514)398-5924
386bsd--ftp agate.berkeley.edu:/pub/386BSD/386bsd-0.1, mail for FAQ info
Paul
>In article <1993May12.0...@latcs1.lat.oz.au> wo...@ipc5.lat.oz.au (M.C. Wong) writes:
>>Hi,
>> I have a question about the performanc of running XFree1.2 on
>>386BSD 0.1. In multi-user mode running 3 xterms, xeyes, xclock,
>>xload and xbiff, when I do serious compiling in one of the window,
>>I realize that the performance of the overall X activities are
>>intolerable slow and it chokes very very much, and I can hardly
>>see my mouse moving/appearing on the screen for 5-10 seconds.
>
> This is rather bizarre---I ran XFree86 and 0.1 on my 486/50; and
> with Xeyes, Xclock, and three compiles running, the load average
> hit about 2.27, but the machine was still quite responsive, and
> the mouse and windows still moved around as fast as they had
> before I started all the builds.
I wish I was so lucky.
When doing compiles that access disk a lot my system hangs until the
disk activity stops. I think what's happening is that disk interrupts are
crowding out everything else. Is there some way of preventing this, it
would make it a lot easier to run background compiles. At the moment
it's like running a single tasking system because when the disk is being
accessed nothing else happens.
Incidentally, my drive is an IDE, I get the feeling that this doesn't
happen with SCSI which is why not everyone sees it.
--
Paul Richards, University of Wales, College Cardiff
Internet: pa...@isl.cf.ac.uk
David E. Wexelblat
> I have a question about the performanc of running XFree1.2 on
> 386BSD 0.1. In multi-user mode running 3 xterms, xeyes, xclock,
> xload and xbiff, when I do serious compiling in one of the window,
> I realize that the performance of the overall X activities are
> intolerable slow and it chokes very very much, and I can hardly
> see my mouse moving/appearing on the screen for 5-10 seconds.
>
> I wonder :
>
> 1) does the system resource limit (set by limit from tcsh) has
> great effect on the performance ?
No (I think).
> 2) I am running on 486/33 with 16M of RAM, is this considered
> the expected performance ? Besides I am running on a local
> bus board.
Unfortunately, yes. With an SVGA board (non-accelerated), the CPU must
move all of the video memory around. There's a LOT to move, and hence
this is a serious CPU hog. Conversely, when the server gets knocked out
of the CPU by a CPU-bound task, the server essentially stops.
This, specifically, is what accelerated hardware will deal with. Hardware
cursor, BitBlt, etc, will have the most visible impact on things like this.
> 3) has anyone tried fine-tuning the performance of 386BSD + XFree
> such that it runs better ? If so, can u please post some
> useful guidelines, as I think many of us will like to know.
'nice'ing the server up and your compiles down MAY help; I don't know.
Nothing except accelerated hardware (and servers upport for same) will
help much.
> 4) Is the choking a pure limitation of the 486 CPU power, or
> is it the size of memory ? If I go on to > 16M, say 20M,
> will that gives me better performance ?
No, it's a function of the CPU-intensive nature of moving the data around.
Hence there's not much that can be done about it.
> 5) Does the size of the swap space affect that ? If so, how can
> I increase the swap space size ?
Probably not.
>
> Many thanks in advance!
>
> --
> - wo...@latcs1.lat.oz.au
--
David Wexelblat <dw...@mtgzfs3.att.com> (908) 957-5871 Fax: (908) 957-5627
AT&T Bell Laboratories, 200 Laurel Ave - 3F-428, Middletown, NJ 07748
XFree86 requests should be addressed to <xfr...@physics.su.oz.au>
"How many times must good men die? How many tears will the children cry,
'til we suffer no more sadness? Oh, stop the madness. Stop all the madness."
-- Molly Hatchet, Fall Of The Peacemakers.
Marc Wandschneider
>When doing compiles that access disk a lot my system hangs until the
>disk activity stops. I think what's happening is that disk interrupts are
>crowding out everything else. Is there some way of preventing this, it
>would make it a lot easier to run background compiles. At the moment
>it's like running a single tasking system because when the disk is being
>accessed nothing else happens.
>
>Incidentally, my drive is an IDE, I get the feeling that this doesn't
>happen with SCSI which is why not everyone sees it.
Hrm. I was running a no-name 486/50DX with a 12ms Maxtor IDE
drive, and a 14ms Quantum SCSI disk. Most of the builds were
running on the IDE drive.
However, it might be worth pointing out that I was running X386mono,
since the 8514 isn't quite supported yet....
Amancio Hasty Jr
>In article <1993May12.0...@latcs1.lat.oz.au> wo...@ipc5.lat.oz.au (M.C. Wong) writes:
>> 5) Does the size of the swap space affect that ? If so, how can
>> I increase the swap space size ?
This a FAQ question if you install NetBSD you have the option of
specifying how large your swap swap space is going to be.
Under 386bsd, the swap space can affect your performance depending
on the amount memory in your system. X (for 386bsd) does not have officially
shared library support so a couple of X terms will cost you
at least 2MB of memory add the server and a couple of X apps
and you start swapping on a 8MB memory machine.
However, David is right in that X server performance is directly
proportional to the load on the system but such is not the case
for accelerated cards such ATI or S3 chipsets with a server that
supports the hardware functions on the cards.
Amancio Hasty
--
This message brought to you by the letters X and S and the number 3
Amancio Hasty |
Home: (415) 495-3046 | ftp-site depository of all my work:
e-mail ha...@netcom.com | sunvis.rtpnc.epa.gov:/pub/386bsd/incoming
Vassilis Prevelakis
>In article <C6x8...@cbnewsj.cb.att.com> dw...@mtgzfs3.att.com (David E. Wexelblat) writes:
>[...]
>shared library support so a couple of X terms will cost you
>at least 2MB of memory add the server and a couple of X apps
>and you start swapping on a 8MB memory machine.
I thought that the BSD4.3 vm allows sharing of the text of entire
executables. If 386BSD follows the same policy (my 386BSD system is at
home so I can't check it now) then the Xterms will definately NOT eat
up 2 megs.
**vp
-----------------------------------
Vassilis Prevelakis | v...@csi.forth.gr
Thoukididou 10A | old style address:
Plaka, Athens 105 58 | ...!mcvax!ariadne!vp
GREECE |
Tel. +30 1 32 32 867 | FAX +30 1 72 24 603
Amancio Hasty Jr
>ha...@netcom.com (Amancio Hasty Jr) writes:
>
>>In article <C6x8...@cbnewsj.cb.att.com> dw...@mtgzfs3.att.com (David E. Wexelblat) writes:
>>[...]
>>shared library support so a couple of X terms will cost you
>>at least 2MB of memory add the server and a couple of X apps
>>and you start swapping on a 8MB memory machine.
>
>I thought that the BSD4.3 vm allows sharing of the text of entire
>executables. If 386BSD follows the same policy (my 386BSD system is at
>home so I can't check it now) then the Xterms will definately NOT eat
>up 2 megs.
>
Amancio
Callum Gibson
> wo...@ipc5.lat.oz.au (M.C. Wong) who laments about the performance of XFree:
> > 3) has anyone tried fine-tuning the performance of 386BSD + XFree
> > such that it runs better ? If so, can u please post some
> > useful guidelines, as I think many of us will like to know.
>
> 'nice'ing the server up and your compiles down MAY help; I don't know.
> Nothing except accelerated hardware (and server support for same) will
> help much.
Yes, I was also going to recommend nice-ing the server up. I've used the same
thing here at work on Sparcs since the main thing is to get feedback from your
windows - you don't care if a (relatively) long compile takes a little longer.
The machine in question here is a Sparc2 with GX (which admittedly is an
accelerated card - though not as good performance as XS3, it gets about 80k)
but the speed up after nice-ing is noticeable while compiling. Give it a go -
it's a cheap fix.
regards,
Callum
--
Callum Gibson cal...@frost.bain.oz.au
Fixed Income Division, DB Bain & Co. 61 2 258 1620
iv...@cc.usu.edu
> When doing compiles that access disk a lot my system hangs until the
> disk activity stops. I think what's happening is that disk interrupts are
> crowding out everything else. Is there some way of preventing this, it
> would make it a lot easier to run background compiles. At the moment
> it's like running a single tasking system because when the disk is being
> accessed nothing else happens.
>
> Incidentally, my drive is an IDE, I get the feeling that this doesn't
> happen with SCSI which is why not everyone sees it.
Welcome to the wonderful world of IDE! That's right, IDE _doesn't_ do DMA;
the CPU has to block-transfer the data to and from the data register. Why?
Because on the stock 6 MHz AT, the block output instruction is significantly
faster than 16-bit DMA (the DMA controller runs at _3_ MHz, you see).
Roger Ivie
iv...@cc.usu.edu
Peter da Silva
downright ridiculous. What's it doing with all that memory?
--
Peter da Silva. <pe...@sugar.neosoft.com>.
`-_-' Har du kramat din varg idag?
'U`
"Det er min ledsager, det er ikke drikkepenge."
Piercarlo Grandi
Wong> Hi, I have a question about the performanc of running XFree1.2 on
Wong> 386BSD 0.1. In multi-user mode running 3 xterms, xeyes, xclock,
Wong> xload and xbiff, when I do serious compiling in one of the window,
Wong> I realize that the performance of the overall X activities are
Wong> intolerable slow and it chokes very very much, and I can hardly
Wong> see my mouse moving/appearing on the screen for 5-10 seconds.
Easy: GCC (which is what you will be using under 386bsd) can generate
*immense* (dozens of megabytes) temporary tables. It can easily crowd
out everything of a 16MB machine.
Even if it does not, if it gets large enough (a few MB will be enough,
and it is very easy to see GCC grow to a few MB even on rather common
programs), it can be swapped out; and if it is swapped, everything will
freeze while the system is swapping in/out several MB of memory image.
The same effect will happen if it is the X server to be swapped out.
As a palliative you can avoid running xeyes, xclock, xload and xbiff,
this will save you some MB of resident (because they are all continuosly
active) memory, and thus minimize the possibility of GCC (or the X
server) being swapped out.
If you run vmstat in one of your xterms you will see that things are
getting swapped out almost surely; I cannot guess whether the X server
or the GCC process are getting swapped out/in.
scott allen long
It's called static libraries. Take a look at the program called 'xlogo'.
500k+ to display an X in a window. Sick, huh? btw, how is the work on
shared libraries coming?
-sl
Lee Essen
|> In article <C72C0...@sugar.NeoSoft.COM> pe...@NeoSoft.com (Peter da Silva) writes:
|> >A couple of Xterms eat up *megabytes*? I knew X was fat, but this is just
|> >downright ridiculous. What's it doing with all that memory?
|> >--
|>
|> 500k+ to display an X in a window. Sick, huh? btw, how is the work on
|> shared libraries coming?
I think this unquestionably a big argument in favour of shared libraries, some
of use can afford to have 32 Meg systems, and even those that do probably dont
like the idea of 28 Meg of it filled with several copies of the static libraries.
Why is there so much 'anti-shared-library' feeling?
Lee.
Marc Wandschneider
>
>I think this unquestionably a big argument in favour of shared libraries, some
>of use can afford to have 32 Meg systems, and even those that do probably dont
>like the idea of 28 Meg of it filled with several copies of the static libraries.
>
>Why is there so much 'anti-shared-library' feeling?
I fail to see where you're getting this 'feeling' from. I see
countless posts daily, asking when shared libraries will be
available for 386bsd. There are already some crude implmentations
out there that seem to be workable.
Last I heard, some (generous) people were working on it, and one
had some code that was ready to go alpha.
I'm eagerly looking forward to them.
Toodlepip!
Marc [patiently waiting] 'em.
Amancio Hasty Jr
>In article <1ta5ro$i...@zaphod.axion.bt.co.uk> les...@axion.bt.co.uk (Lee Essen) writes:
>>
>>I think this unquestionably a big argument in favour of shared libraries, some
>>of use can afford to have 32 Meg systems, and even those that do probably dont
>>like the idea of 28 Meg of it filled with several copies of the static libraries.
>>
>>Why is there so much 'anti-shared-library' feeling?
>
into minor problems. When they are ready they will be posted :-)
About bsd performance, one side of the equation is the support
for shared libraries, the other side is that drivers execute
at ipl level thus locking out servers like X. What people have
done in the past is to split the driver into at least two parts,
one basically, that handles interrupts and writing to the devices
and the other at an interruptable priority.
So if we get shareable library support we will still run into
performance problems while compiling.
Cheers,