[openbeos] Re: Article on BeOS vs MacOS X
- From: Mark-Jan Bastian <markjan@xxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 19 Dec 2001 23:54:40 +0100
Hi Jim :)
Yup, you got it right - it's the responsiveness, or 'GUI latency'
that I was wondering about. A CPU load indicator only shows how much
time was left for the idle thread after all the other processes
were done, and doesn't say anything about the scheduling granularity or
responsiveness of various subsystems of the OS. A 80% pulse could
mean 70% of CPU time was allocated in one big chunk for some strange
reason, after which a (huge) 2% overhead for a context switch was
needed, and then 8% was needed for processing I/O and doing a display
update.
Software that logs context switches in the kernel and then a
client which graphically shows what was blocking on what, together with
visualisation of the managment of the scheduling queue's would be very
educational to show the differences. Does anyone know of this kind of
software being developed on various platforms ?
thanks,
Mark-Jan
On Wed, Dec 19, 2001 at 03:46:50PM -0600, lists@xxxxxxxxxx wrote:
>
> Guillaume <guillaume.maillard@xxxxxxxxxxx> wrote:
> > > It also seems to have the same unix-like scheduling problems. Resizing
> >> a terminal with top is a very nice test.
> >
> > It makes me smile :)
> >Because you see that a graphical operation take more than 3%
> >of your cpu, you conclude that the scheduling is the cause...
>
> I'm not sure whether Mark-Jan was obsessed about a specific CPU load
> factor (he didn't mention anything about 3% or n%, if I remember
> correctly). I think specific CPU loads are sort of irrelevant to the
> main point, actually.
>
> The experiment he mentioned is is not merely a "graphical
> operation"...it shows you what happens in the system under some
> degree of load, therefore scheduling complexity. (Try the same
> experiment in Linux with an FTP session open and playing an MP3, and
> I bet the experiment gets even more interesting.)
>
> The key here, and what I think (forgive me, M-J) Mark-Jan was getting
> at, is that the Linux kernel handles scheduling very differently from
> BeOS, leading to different user experiences. "Slow" becomes a matter
> of perception, not a CPU load percentage. (I don't care if a redraw
> takes 90% of the CPU in some cases, as long as the user experience is
> responsive in ways I want it to be, e.g., a typical BeOS experience.)
>
> Linux has great networking throughput, partly due to scheduling. BeOS
> makes a different compromise between making the GUI seem snappy under
> loads (something I find important, given my occasional forays into
> legacy Mac OS, in which the screen stops when I mouse down on a menu,
> and how nuts that makes me), but does so at the sacrifice of
> networking. Simple example. (On top of it, BeOS 5 networking
> is...um...subomptimal on its own, contributing to performance
> trouble, but I'm talking kernel scheduling issues.)
>
> As for "better performance" on Linux versus BeOS or any system, it
> all depends on what you feel is important. Last time I tried Linux
> (yesterday), it sucked (800-something PIII). It all comes down to
> your, in this case my, criteria for what makes a system feel fast.
> Creaky slow screen updates and resizes aren't what I look for (and
> it's *not* simply a windowing system problem, although that's part of
> it).
>
> Mark-Jan (if he doesn't mind my speaking for him) is interested for
> professional reasons in a responsive scheduler with a preemptible
> kernel--most Linux distros are simply not up to the task Mark-Jan
> needs.
Other related posts:
