On Sunday 15 April 2001 06:30, you wrote:
> Bruce F. Press wrote:
> > Yes, yes, we've heard this before. It is not a satisfactory answer,
> > clearly the "idle" loop in kapm-idled could use a nice sleep(15) or
> > something!!
>
> What would be a satisfactory answer?
>
> Are you concerned because top shows the system being far busier than it
> really is?
>
> (Then maybe we need a modified top that does not count kapm-idled as
> processor usage in the "CPU States" percentage.)
>
> Do you disbelieve what you are being told (that, IIUC, the time used by
> kapm-idled is really system idle time that will transparently and
> instantaneously be applied to a real task if one exists and is ready to
> run)? If so, do you have any evidence of this -- is your system running
> slowly or more slowly than you would expect / are used to?
>
> I'm serious about these questions, not trying to be a smart ass. The
> story being told is believable to me. But, I keep hearing that Linux's
> approach of using all available RAM (not paraphrased accurately) is the
> best approach, yet in a Windows 95 system with 64 MB of memory I can
> keep 30 IE 5 windows open and get snappy response switching between
> windows, yet in a Linux (Mandrake 7.2) system with 128 MB of RAM (and
> comparable processors, identical motherboards and video cards),
> everything works much slower even with only one window open, and by the
> time I get to 15 to 20 open (Konqueror 2.0 or 2.1) windows, the system
> is like molasses.
>
> I think part of the problem is theat kde/konqueror need to learn some of
> the tricks that Windows uses. I can't describe those tricks accurately,
> but I see the results. One example: in Windows, if I create a new
> instance of IE, it appears almost instantly, and the disk doesn't make a
> peep. In Linux, if I do the same thing in konqueror, the disk starts
> chugging, and 15 to 45 seconds later the new instance of konqueror
> appears (and on the wrong desktop if I've switched desktops in the
> interim).
>
> Don't get me wrong, I want Linux to succeed, but I think some new tricks
> are needed. (Also, in Linux, if I make some wrong keystrokes, it seems
> that they are all queued up and executed (slowly) one after the other.
> In Windows, it seems that if I type (or click) the wrong command, but
> then type (or click) the right command, the initial incorrect command is
> interrupted and never completed (at least under some circumstances). I
> know I am not describing this stuff accurately or completely, but it
> sure makes a Windows system much more responsive than a Linux system.
>
Well, the price of the snappy response is that the code for IE is part of the
op system. Even if you decide you want to use another browser, you still
have the IE code sitting there. There was a utility issued independently
that turned off the IE code and then Netsxape on Windows appeared pretty
fleet while beforehand it CHUGGED along.
The price you pay is security. Even with the current IE, I can construct a
website that destroys your computer's data in a single step if you open it
with IE.
Still, even though there is overhead for the walls between the programs and
the op system, which are necessary for your protection, your linux machine
should be running faster. I would suggest you check the daemons you have
activated.
> And yes, "until it crashes" -- but I have learned to watch my resource
> usage in Windows and reboot once or twice a week whether I need to or
> not, and thus rarely if ever get a crash. Yes, I would prefer not to
> have to reboot periodically, but I get more done quicker in Windows
> between reboots that I do in Linux waiting for the molasses.
>
> If you (anyone) can collaborate these stories, and help me get them to
> the right developers, it would be to the benefit of all of us. I don't
> know whether these things need to be addressed at the OS level or the
> desktop level, or someplace else, but someone needs to consider them.
>
First rule of optimisation--the speed of a non-working program is irrelevant.
You are looking at desktops growing at an astounding rate, but the usual
course of development is -- get something working, then add features, then
improve speed.
Still all-in-all my experience has been radically different from yours. I
have noticed the snappier response time in linux. But then I do take the
time to tune my disks.
So, what does
hdparm -t /dev/hda
say? Run it three times, and run it without any caching programs active
(like netscape or squid or konqueror).
Also, do windows and linux run off the same disk? Is it a disk that can use
DMA or udma? Do you have a VIA chipset, because the kernel is deliberately
disabled of several fast disk features to avoid a hardware bug that is
corrupting some windows installations.
In other words, compare apples to apples. I will assist if you want to test,
but right now your test may not be a fair assessment. many of the things you
speak of are disk-speed dependent.
Civileme
> (And, if the desktop developers tell me they can do nothing, it all
> depends on the OS developers, I will not believe them. I might believe
> that the cleanest fix must be done at the OS level (if that's what they
> tell me), but I believe that fixes can also be done at lower levels.
> Perhaps performance can be improved by always keeping a buffer of free
> RAM large enough to immediately clone a konqueror window. At the
> desktop level, one or more such buffers can be created, even if you do
> something dumb like precreating an unused instance of konqueror. Then,
> when an instance of konqueror is requested, display this one immediately
> (with no disk chugging). Then start the disk chugging to create another
> free buffer for the next request.
>
> I know these kind of things can be done. I am not enough (or any) of a
> programmer to do them myself. I imagine all the developers are busy
> doing important things. Are they aware of and planning to implement
> techniques like these, or better?
>
> If this email has any value, please feel free to copy or quote portions
> of it to anyone, anywhere, anytime.
>
> Thanks,
> Randy Kramer
>
> > Chmouel Boudjnah wrote:
> > > SI Reasoning <[EMAIL PROTECTED]> writes:
> > > > There are good stretches of the day where my CPU spins
> > > > at around 50% or more and the process spinning is
> > > > kapm-idled. This is not a problem in 7.2.
> > >
> > > --=-=-=
> > > http://www.tux.org/lkml/#s14-1:
> > >
> > > 1.Why is kapmd using so much CPU time?
> > > (REG) Don't worry, it's not stealing valuable CPU time from
> > > other processes. It's just consuming idle cycles (normally
> > > charged to the idle task, which is displayed differently in
> > > top). Normally, when your system is idle, the system idle
> > > task is run, and this is shown as idle time (i.e. the "unused"
> > > CPU time is not charged to a specific process). With APM
> > > (Advanced Power Management), a special idle task (kapmd) is
> > > required so that greater power saving techniques can be
> > > enabled. So now, the "unused" CPU time is charged to the kapmd
> > > task instead.
> > >
> > > --=-=-=
> > >
> > > --=-=-=
> > > http://olstrans.sourceforge.net/release/OLS2000-apm/OLS2000-apm.html:
> > >
> > > In 2.2 and before, we basically had a hook into the idle loop, so that
> > > if we had APM enabled, we would just tell the BIOS that we're
> > > idle. In 2.3, Linus thought it would be a good idea if we had a
> > > separate power management idle loop, so (he) we invented the
> > > kernel APM daemon and I started getting bug reports about this
> > > process that was using all our time, called kapmd. And if you sat
> > > there just running top on a 2.3 kernel, the top process, if you're
> > > not doing anything else, will be kapmd and it will be using like
> > > 85% or 90% or 95% of your CPU time. These people were worried
> > > because it was idle: why is it using all of the time? Well
> > > actually, it's just that the time is getting accounted to that
> > > process. It's not doing anything, it's the idle loop. [26m, 12s]
> > > --=-=-=
> > >
> > > --
> > > MandrakeSoft Inc http://www.chmouel.org
> > > --Chmouel
> >
> > ---------------------------------------------------------------
> >
> > Name: brucefp.vcf
> > Part 1.2 Type: text/x-vcard
> > Encoding: 7bit
> > Description: Card for Bruce F. Press
