Linux-Advocacy Digest #721, Volume #27 Sun, 16 Jul 00 19:13:04 EDT
Contents:
Re: Linsux as a desktop platform ("Christopher Smith")
Re: Oracle on Linux Justification ("Joseph T. Adams")
Re: Linsux as a desktop platform (Gary Hallock)
Re: Linsux as a desktop platform (T. Max Devlin)
Re: Can we qualify the versions please!!! (Arthur Frain)
Re: Would a M$ Voluntary Split Save It? ("JS/PL")
Re: Linsux as a desktop platform (Gary Hallock)
----------------------------------------------------------------------------
From: "Christopher Smith" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Mon, 17 Jul 2000 08:26:12 +1000
"T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Said Christopher Smith in comp.os.linux.advocacy;
> >"T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
> >Hence multiple queues would probably solve this problem best, with the
> >process in a low priority queue in the former case and a high priority
queue
> >in the latter case.
>
> Could somebody explain the implementation of queues on Linux? I only
> have the reference on FreeBSD. Is it the same?
I'm not sure what you mean by implementation ? Do you mean the number of
queues and their relative priorities ?
I suggest you have a read at www.linuxdoc.org, specifically "The Linux
Kernel". I *think* Linux use a single priority queue algorithm.
In practice it is no better (or worse), than NTs (and probably Win9xs, if
Win9x wasn't hobbled by its 16bit legacy support - then again if Win9x
wasn't hobbled like that it would be NT).
> >> One can do anything in CMT one can do in PMT, if one designs a suitable
> >> CMT system.
> >
> >In the context of this discussion, no, you can't. The reason is because
> >ultimately CMT is at the mercy of the applications.
> >
> >There are a few simple and specific situations where a CMT scheduler
would
> >be a better choice, but these are irrelevant to the types of computers
we're
> >talking about.
> [...]
> >All PMT OSes have methods for manipulating priorities. Almost all have
> >included programs for manipulating priorities while a process os running.
> >Of those, the vast majority have GUI tools.
> >
> >As usual, your hypothetical problem was determined and fixed a very long
> >time ago.
> >
> >You also ignore the fact it is a very rare case for the vast, vast
majority
> >of people that a priority needs to be manipulated. Most people who need
to
> >be manipulating priorities, know what they are and how to do it.
>
> I am interested in expanding that group tremendously, if it will improve
> the control the user has over their experience with computers. "Speed
> this up" and "slow this down, I don't need it soon" are not beyond the
> capabilities of any user to understand.
But the point you're missing is it really won't make any difference because
for the vast majority of people the CPU is not the bottleneck - increasing
the priority a process has won't make a schmick of difference if that
process is idle, which most are most of the time.
Modern CPUs are more than fast enough for most people.
> The question remains whether
> they can deterministically implement such changes to an operationally
> effective degree. The fact that the problem seems hypothetical, and was
> fixe a very long time ago, are both reasons why I am trying to discuss
> them today. I do not know if there is any possible benefit to the
> end-user of a desktop system to re-examining scheduling.
There's not, because scheduling deals with the CPU, which is already more
than fast enough. The problem is the rest of the system is so slow, which
no scheduler can even affect, no matter how well implemented.
> All of the
> assumptions that it is not seem to be predicated on research done before
> there was such a thing as a desktop system, or a non-expert end user.
>From a CPU scheduling point of view, it makes no difference. The slowest
link in the entire chain is most likely the user.
> Constant suggestions that my questions aren't appropriate, rather than
> simple and civil (and, yes, ongoing and sometimes repetitive, since I'm
> still playing catch-up on the technical details) discussion, caused me
> to become frustrated.
I suggest next time you leap into a technical discussion you take a half
hour or so out to learn even the basics of what you're talking about.
You've done the equivalent of jumping out of a helicopter into the middle of
a jungle, naked, with two broken legs, no food and no water and then gotten
irate that people have called you stupid.
> >> Yes, but the nice value, it turns out, doesn't have anywhere near the
> >> impact as the other components of the algorithmic scheduling. I'm not
> >> sure really how much, though, as I'm not a CS graduate, and I really
> >> suck at math. Here's the piece where it comes up, I think:
> >>
> >> p_usrpri = PUSER + (p_cpu/4) + 2.p_nice
> >>
> >> And the description says that nice "cancels out some of the effects of
> >> high CPU loading". I'm not really sure how much impact that has on the
> >> over-all efficiency of algorithmic scheduling.
> >
> >It won't affect the *efficiency* at all. You'll still maximise the usage
of
> >system resources, assuming[1] you're running enough stuff to actually do
> >that.
>
> But it seems possible, if not probable, to me, that maximizing the usage
> of system resources may in fact be counter-productive for maximizing the
> perceived performance by the end user. It is not without precedent that
> a sacrifice in efficiency may be worthwhile to optimize effectiveness.
No, because mostly the user is the slowest part of the system, and at other
times the bottleneck is in parts the scheduler can do nothing about (eg disk
I/O).
> The theoretical (and I do not mean that disparagingly) basis of the
> current PMT systems does seem to be heavily weighted towards
> time-sharing systems:
There is no conceptual difference - you have a whole bunch of processes
time-sharing a given machine. The only diffeence is now you only have a
single user, rather than many. The end result is the same - if anything it
is even more apparent now - the CPU has cycles to burn waiting for the user
and/or the rest of the system.
> >A plethora of, say, xterms running at the highest priority that are all
> >waiting for user input will still result in a mostly idle CPU and a
highly
> >responsive system.
> >
> >It might affect the responsiveness of the system, if you bump something
that
> >actually uses a lot of cycles, but if you're messing with priorities
that's
> >a risk you've implicitly decided to take.
>
> Again, I'm unsure of your use of "responsiveness" in this technical
> sense matches what a general use of the term may indicate. Please
> consider the case of a desktop, where there aren't multiple users. Does
> anything change at all?
Not really. Responsiveness refers to how quickly a given process can
"respond" to an event, be it a hardware interrupt, a user event (button
click, keypress etc), a disk read completing - whatever.
In a CMT system, the responsiveness is entirely dependant on whether or not
the applications [can] co-operate, which is why if you're running more than
one process, it rapidly goes downhill. I've never actually bothered to
check, but I would imagine the rate at which responsiveness on a CMT system
degrades is exponential.
> >> Then again, I guess I'm still not sure how much impact algorithmic
> >> scheduling has overall on the handling of bottlenecks, or where those
> >> bottlenecks are.
> >
> >It reduces their impact on the efficient use of system resources.
> >
> >However, if a process is waiting for some slow device like a printer, it
> >will still have to wait for it, so if that's the only process you're
using
> >then you *will* notice the delay. Nothing can change that fact, although
> >PMT will lessen it from the OSes point of view.
> >
> >The fundamental different between PMT and CMT is that while that process
is
> >waiting for the printer (or some other device), on a PMT system the rest
of
> >the processes on the system can potentially do useful work (assuming they
> >have some to do).
>
> They can potentially do work in CMT as well; it is still multi-tasking.
Only if (and it's a *huge*, *huge* if) every process co-operates.
For example, let's say you're running two things, a word processor and a web
browser. Imagine that the word processor has been implemented so that when
it is told to print, it only yields after the print has completed. Imagine
that the web browser has been implemented so it only yields after a page has
completely loaded.
So, you start to print something and can't do anything else until the print
has finished. Since it's a 500 page technical report, that'll take a
while - you-re locked out of the system.
Or, you decide to load a web page - the same thing occurs until the webpage
has loaded.
On a PMT system this doesn't happen because the *scheduler* decides that
it's time to take the CPU off the word processor and hand it to the web
browser.
Aha, you say, but what if we wrote the word processor so it yielded after
writing, say 100kb to the printer port, and the browser so it yielded after
reading 5kb of the page ? Well then, lets say you've got a crappy printer
that can only take 10kb of data at a time and prints slowly - you're still
locked out until that printer has taken its 10kb, printed it, taken the next
10kb etc etc. Or, OTOH, you have a fast printer than can take 2MB at a
time - that means the word processor dumps its 100kb then yields, after
which the browser grabs hold of the CPU. But wait, we're browsing a really
slow website thats only download at 1kb/sec, so the web browser takes 5
seconds before it yields back to the word processor which can then dump the
next 100kb (on its way to 2MB) to the printer to print. Then the whole
cycle repeats.
Can you see why CMT is such a horrifically inefficient method ? Why it has
much worse responsiveness ?
> Consider: if the crucial difference, as I'm told, between CMT and PMT is
> the notion of a maximum quantum, would not a CMT system in which all
> processes internally implemented a convention of a maximum quantum be
> similar in most respects to PMT? Yes, I realize the problems of
> cognizance and reliability still remain; I just want to double-check my
> understanding.
To a degree, in theory, yes, but it would be an extrememly dumb thing to do.
Instead of the notion of the quantum, and its associated code being
implemented once, in the OS, you have it implemented numerous times
(probably with numerous ideas of what a reasonable quantum is) in every app.
This increases your chances of having someone, somewhere, make a mistake.
You also can't escape the inherent limitation that any app is still able to
monopolise the CPU and hang the entire machine if its "quantum code" screws
up.
> >> So I'm obviously floundering at this point.
> >
> >You've been floundering since your fist post. Even now, after many
subtle
> >and not-so-subtle suggestions to actually go and learn even the *basics*
of
> >the topic under discussion, then sit down and think about them for a
while,
> >you obviously haven't.
>
> So kill-file me. I'm sick to death of being taken to task, even if I
> did insult more people than I intended.
For an alleged teacher, you have an extremely poor learning methodology. I
would certainly hate to be one of your students, and I pity any of them you
have taught to learn by the "scream at everyone until someone answers"
method.
> >The intricacies of CPU scheduling is not something you can even learn
about,
> >let alone understand, in "20 minutes".
>
> Neither are the intricacies of ATM, but it didn't take me longer than
> that to develop a working understanding of the system suitable for
> explaining some of the subtleties to some who had supposedly been
> thinking about it for a vastly longer time.
I sincerely doubt that.
> >Not really. Everything's gotten faster and bigger, but there haven't
been
> >any fundamental changes (at least not in mainstream computing) in the way
> >computer resources are used - and faster and bigger is what makes the few
> >advantages CMT has over PMT irrelevant. That's why PMT is still around
> >after 30-some years.
>
> I think personal computing *should* change the way computer resources
> are used.
I would be interested to hear what fundamental changes you can foresee.
> PMT as currently implemented seems focused primarily on
> multi-user computing.
No, multi-*process* computing.
The last desktop non-multi-process oriented OS was DOS, and even it had
basic abilities to task-switch.
The reason for this is because people are inherently multitasking, even
though most wouldn't describe it as such.
> The thing that slows PCs down the vast majority
> of the time is certainly I/O bottlenecks, to be sure. Perhaps the real
> reason I've been ignorant enough to wonder about this stuff is because
> of that faster and bigger you pointed out. My CPU is so much more than
> I need over any long time scale (seconds, minutes) that it doesn't
> commonly go above 2% utilization, AFAIK. Yet a CPU-intensive task
> doesn't seem to happen almost instantaneously, in my time frame, as I'd
> expect.
That's because a CPU isn't like a bank - you don't save up spare cycles to
expend them all when they're needed most.
I'd also be interested in what type of CPU intensive things you're talking
about. Most likely the bottleneck isn't the CPU.
------------------------------
From: "Joseph T. Adams" <[EMAIL PROTECTED]>
Subject: Re: Oracle on Linux Justification
Date: 16 Jul 2000 22:24:08 GMT
[EMAIL PROTECTED] wrote:
: I'm looking for case studies to justify to our management why we should
: go with Oracle on Linux. We have the Oracle part nailed down, they
: just aren't so sure about Linux. If anyone knows of any big names or
: are themselves running this combination in a production environment, I
: would be interested to here about their/your environment. Any links to
: web sites or white papers would be appreciated as well.
Without more information about your needs it's hard to say, but in
general, I'd recommend Linux as a good entry-level platform for Oracle
because it's scalable, cost-effective, well-supported, and easily
customized for any unique demands you might have. On the other hand,
Linux is designed and optimized primarily for commodity-class
hardware, and although it does scale to enterprise-scale hardware, if
you need that kind of scalability, the proprietary Unices that run on
that hardware can offer some advantages in terms of performance,
reliability, and single-vendor accountability which may or may not
justify their additional cost and complexity compared to a Linux-based
solution.
If you can provide more information about your needs, there are
plenty of folks here and on the non-flame newsgroups (I'm reading this
from c.o.l.advocacy) who would be happy to try and point you in a good
direction.
Joe
------------------------------
Date: Sun, 16 Jul 2000 18:25:14 -0400
From: Gary Hallock <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
"T. Max Devlin" wrote:
>
>
> I never "refused" to learn anything in my life. If your explanations
> weren't clear enough for me to learn from, that's your fault, not mine.
What a totally arrogant thing to say. That's right, never take responsibly.
It's always someone else's fault.
>
> Remember, I'm the one who didn't already have the knowledge necessary to
> know what assumptions the explanations were based on, such as the fact
> that no maximum quantum whatsoever is implemented by convention in a CMT
> system.
>
Which means you should never had entered this discussion since you had
absolutely nothing to contribute.
>
> Much like, I still figure, most people just took their word for it when
> they were taught that CMT is not feasible. Much like those who insist
> the Mac was a stupid idea. All I did was point out that there seemed to
> be some inconsistencies in that argument.
It is not a question of being taught. It comes from experience and simple
logic.
>
>
> The reason you and Gary are being assholes, I figure, is because you
> simply refuse, despite numerous suggestions, to ever make the effort to
> teach.
Hu? Where in the world did you get the idea that this ng is a place to come to
be taught? Teaching you is not my responsibility.
> You expect your explanations are sufficient for those who don't
> understand something, simply because they make sense to someone who
> already knows what is being explained. But obviously your ability to
> teach someone something they didn't already know is severely limited.
> At least in Gary's case, that's what I'll presume. Since I've had a
> longer experience with your posts, I'd say you simply don't want to
> teach, as it is counter to your objectives. What they may be, I still
> haven't figured out. Self-aggrandizement, perhaps.
>
No, I simply have no desire to teach YOU. Go read a book or take a course.
Gary
------------------------------
From: T. Max Devlin <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Sun, 16 Jul 2000 18:26:20 -0400
Reply-To: [EMAIL PROTECTED]
Said Christopher Smith in comp.os.linux.advocacy;
[...]
>Your question was "is there some reason that the renderer fails under load?"
>in repsonse to dc's post about the rendering process "basically dying" when
>it is placed in the background. He was not talking about a functional
>failure, but a practical one, where the renderer slowed to such a point as
>to be useless - thus the "practically" part of "practically dies".
Well, that's a different issue, then. If the renderer has to
"practically die" in order to provide the foreground response I want, so
be it. That's the premise, anyway. Practical complications could be
addressed, though, once we get past this glitch.
>The *reason* this happens is due to the fundamental design of the CMT
>system.
I concur, and appreciate your addressing my concern directly. The
original quote was neither "practically dies" nor "basically dies", but
rather "dies, basically" which is not at all as clear in intonation.
I will, however, take some responsibility for the confusion. I am almost
as embarrassed by my own failure to understand what a poster means as I
am frustrated by others' apparent insistence on refusing to try to
understand my own intention. Apparently I have again fallen into the
trap of expecting that I can easily distinguish between an honest
response and an insinuative troll. That happens when you spend too much
time posting on Usenet.
My repeated apologies to one and all in that regard.
--
T. Max Devlin
Manager of Research & Educational Services
Managed Services
ELTRAX Technology Services Group
[EMAIL PROTECTED]
-[Opinions expressed are my own; everyone else, including
my employer, has to pay for them, subject to
applicable licensing agreement]-
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: Arthur Frain <[EMAIL PROTECTED]>
Subject: Re: Can we qualify the versions please!!!
Date: Sun, 16 Jul 2000 15:16:51 -0700
[EMAIL PROTECTED] wrote:
> And I am not saying the current versions from MS
> are perfect as they are far from perfect, but they are a lot better
> than they were 3 years ago. And so is Linux for that matter, even more
> so in fact.
> How about discussing Win 2k or Win98se or Linux SuSE 6.4 and Caldera
> 2.4 instead of RedHat 5.2 and Windows 95?
Based on recent experience, Win9x is sufficiently
descriptive. I don't know (or care) anything about
W2K or NT from personal experience, although I've
heard plenty of negatives from users.
The recent experience is about 2 days ago when I
bought my daughter a new HP computer with Win98SE
preinstalled - fully functional, original OEM
equipment and drivers, no new software installed
(that covers the usual "drivers/bad hw/bad sysadmin"
excuses). I hooked it up to our network (HP also
supplied the NIC and software was pre-installed;
all I did was assign a name and workgroup and
setup TCP/IP, with the usual reboots), so she
could copy *data* from her old machine.
The first time Network Neighborhood (NN) worked
fine. The second time NN couldn't find the
network (the eternal searching flashlight).
I could ping any other machine on the network,
so TCP/IP and all the hw and cables were fine.
Killed NN, and reopened it and it locked the
whole machine. CTRL-ALT-DEL produced the ever
lovely blue and white "System Busy" screen.
One more CTRL-ALT-DEL produced a blank screen,
with nothing else possible besides power down
and reboot. NN now works fine again.
This is, to repeat, a completely unmodified just
out of the box system from a reputable mfg with
no added hw or sw - just MS all the way. This is
no different than several years of similar
experience with Win95 - I find the suggestion
that MS is improving hard to believe.
Arthur
PS: The machine also refuses to shut down - it's
never safe to turn off her new computer. But
scandisk does run faster - is that what you mean
by improvement? I expect things will only get
worse as we install add'l software.
------------------------------
From: "JS/PL" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
Date: Sun, 16 Jul 2000 18:40:40 -0400
Reply-To: "JS/PL" <[EMAIL PROTECTED]>
"T. Max Devlin" <[EMAIL PROTECTED]>
> You argue from an intentional position of ignorance. Its boring.
No - a bunch of socialist personality types sitting around agreeing (and
insisting) that government should steer the design of their software is
boring.
------------------------------
Date: Sun, 16 Jul 2000 18:41:49 -0400
From: Gary Hallock <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Karl Knechtel wrote:
> [EMAIL PROTECTED] wrote:
> : On Fri, 14 Jul 2000 16:34:41 -0400, T. Max Devlin <[EMAIL PROTECTED]>
> : wrote:
> <snip>
> : If your frontmost task is waiting for human input in a CMT system, the
> : rest of the tasks get very little CPU time, and end up starving.
> : That's the major flaw in CMT.
>
> : If your frontmost task is waiting for human input in a PMT system, the
> : rest of the tasks get the vast, vast majority of the CPU time, and the
> : system continues to run cleanly. That's the major benefit in PMT. A
>
> I highly doubt that. Unless your computer is psychic, how is it supposed
> to know when will be the next time the foreground app actually *receives*
> input? It won't. And if you don't give very much processor time to the
> foreground app, there's a good chance (because the distribution is
> effectively random) that it won't have processor time at the moment the
> input is received. You're going to get either dropped keystrokes or choppy
> responsiveness, unless the timeslice is small (probably not a problem) *and*
> you have a way of buffering that input when the app that has to deal with
> it doesn't have CPU time. I'm not a hardware engineer, but that last bit
> seems to imply (to me anyway) that *something* has to be watching the input
> device on every cycle, possibly an additional processor. (I'm going to go
> further out on a limb, based on assorted things I've heard, and speculate
> that this is how Amiga handles it.)
>
What, did you and Max go to the same school? PMT is not simply a matter of
assigning fixed size chunks of time to processes in some round-robin scheme.
When you hit a key or click on the mouse, it causes an interrupt. It's called
an interrupt because it causes a temporary interruption in the flow of
control. The interrupt causes an interrupt routine in the OS to be called,
after saving any state information needed to later resume the code that was
interrupted. The scheduler then looks to see who might be waiting for input
from the device. It then marks the process that is waiting as runable and,
based on a variety of factors, chooses a process to be given control next. It
might be the process that was interrupted, the process that has just been marked
runable, or some other process. Typically, the process that was waiting and is
now runable will be given a higher priority than processes that have been
running for a while. So, in a matter of a few microseconds or less the process
that was waiting for input from the mouse or keyboard gains control even though
the process that had been running when the interrupt occurred had not yet used
up its time slice.
Gary
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.advocacy) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Advocacy Digest
******************************
