Miscellaneous Operating Systems/Hardware

Ja, the obvious conclusion is that Unix is not very well designed. It's not good for desktops and it's not good for mainframes.

It's just not very good


Ah ! Maybe there is our misunderstnanding. I would never say "spawn a thousand threads willy-nilly." My point is that in any activity there will be an optimum number of threads. For an exaggerated example, take pbzip. If you have 128 processors and a 256k zipfile, spawning 128 threads to unzip that file would be ridiculous. There is going to be an optimum number of threads for the task at hand . In general, the task at hand is not going to be determined by how many processors you have !

Figuring out the best way to structure a program is not so easy eaither, but I'm pretty certain that the count-the-processors approach is less than optimum.


This is a pretty crappy solution. Adjusting priority by which application has the focus is way better. Fixed priorities themselves are also fairly shitty. The OS/2 scheduler has 32 priority levels and they are dynamic.

This gives a responsive workstation.

People are so funny. There's a contingent of people in the OS/2 camp who are trying (or have tried) to create a layer that will allow OS/2 apps to run on top of Linux. The concept makes me laugh. That's exactly backwards. Do it that way and you have a reverse-rotation shaft-drive Yamaha pretending to be a Harley


Pretty crappy system.


People once built the pyramids using log rollers and thousands of slaves, too


Yup. Crappy system.


And I would never suggest that a program should do that. It makes no sense. This is the kind of thing a gnu "parallellizing libray" would do, choose a random number of threads based on what color the case of the computer is, rather than looking at what is most efficient for the task.

Let the application decide what tasks need what threads (this does not mean a program should say "hoo cool, there's 64 processors so i'm going to grab all of them !" - a thread should have a distinct job to do, suitable for one task) then let the damned scheduler figure out what's the best way to apportion resources in a dynamic world. And if the user is writing a report, then guess what ? getting that report done with no obstacles is a hell of a lot more important than losing a few milliseconds to context switches. Even a few seconds. Heck, if I have to go back and redo an edit I just made because the stupid computer hung up my interface for 1/3 second and I clicked three times so now have a butchered text, I'll sacrifice two minutes to context switches ! Foregound tasks are what count !

You're looking at this too much from a programmer's view. Look at it as a computer user for a change. We really don't give a shit if it takes ten seconds longer for the background task to finish. What is important to us is what we are doing. NOW !


I do not think this is a good approach.


And OpenMP sucks dead donkey balls for workstation loads. It's just not optimized for what a workstation should be doing. For some dedicated render machine or a box simulating nuclear explosions, fine. But not for a workstation.

It's got the wrong priorities.


Sorry. I should have mentioned that this is a rackmount Tezro


On a 2p O350, I have to disagree. If the point of having more than one processor is to actually use them, then having one do 70% of the work while the other sits idle and my desktop goes unresponsive, is just bad design.

If you'll remember, Unix resisted the very idea of threads for years ! Both OS/2 and even Windows were threaded while Unix was standing proud with processes. A few people almost had to shove pthreads down Unix' throat. And Linus himself said that "Linux will never run on more than one processor." (That's when I lost interest in Linux. Talk about short-sighted ... Torvalds, not me)

Unix has never really figured it 0ut. They are latecomers to the party and they don't drink or have fun.

Of course now that 1984 has come and gone everyone revises history to suit the marketing needs, but this is the truth. Unix has got some honkin' big structural weaknesses.


It makes a lot of sense if it means that my editing or browsing or whatever does not freeze at awkward moments. I'm not being obstinate for fun (at least not this time ) ... use OS/2 for a while. OS/2 has plenty of problems but it does not do this shit. Interface hangups happen way too often on this 2p machine. Waaaay too often. Once a month I could tolerate. Once a day is ridiculous.


Nice. It should distribute them to other processors now , not in fifteen minutes.


I don't care if it's inefficient, I want it to do that because I goddamned well want that application running NOW because that's what I am doing NOW. I didn't pay thousands of dollars for a computer to tell me, "Oh no, you'll have to wait a second because it's not efficient for me to run your program on that other processor."

Dear computer, stfu and do what I say, thank you very much.


Actually, in real life this is not the case. Grab an old dually something and put OS/2 or BeOS on it.

(BeOS is, unfrotunately, not a good test. All you can do is spin the teapot while typing in a terminal. If you had Framemaker to work in while it was doing something else, then you could get pissed if the system hung you up. But since you can't do anything in BeOS, it's hard to get pissed off at your work getting screwed up by the computer. Or not get pissed off because the scheduler actually works, which would be my point ... Haiku is very pretty tho. If there were any decent gnu applications that you could compile it might be a nice system.)


Agreed. Been there, done that, it works well. Alas, none of the programs I needed. OS/2 is also superior to Unix in this respect but same situation, no CAD programs

Neither of them have much OpenGL support either. Okay, BeOS does but no applications that use it. For general-purpose computing there's no way you'd catch me running Irix. And Linux is worse. I haven't tried other Unixes enough to render a judgement (but I'd use a paper and pencil before I'd run Solaris on a desktop. Nice from a command line but holyshit awful as a desktop.)

And ja 2, a single-user workstation is looking more and more attractive. What the hell do I really want all these users and groups for ? For most people it's pointless additional complexity. How many users do you really run your desktop as ?

Sometimes, just because everybody does it this way, doesn't mean it's a good way.


Disagree. Remember the Personal Iris ? Indigo ? Indy ? Even the Crimson and Onyxes were "desksides", meant for one or two users, not a cast of thousands. They got into the hpc server schtick later on.

The underlying problem here is that Unix does not make a good workstation and it's not good on a mainframe, either. It's primitive. It's not well thought-out. In fact, it's not very good.

It's just better than Windows.

IBM uses Linux -- they virtualize thousands of Linux sessions on a mainframe like a herd of DOS boxes, kind of funny


Ja, unless we build our own computers from scratch, all we can do is choose between evils Irix so far is the best compromise for me so I'll stick with it ... but it sure ain't the Immaculate Collection.

The fact is, in many ways Yewnix is one huge kluge .... so we get new toolkits by the dozens while the underlying structural problems are wallpapered over. Post-modern society, whoopee


It was always clear - it's just that I disagree that that's a smart thing to do

Hamei, if you want to install Linux on your SGI workstations, I may be able to help.

Unix is primitive to be sure (it was designed from the bottom up), but its architecture has been proven and refined over a few decades now. It's familiar, flexible, and scalable. Part of its consistency is in not knowing what types of processes are what, or what types of files are what. A process is just a process, and a file is just a bag of bytes. The mere fact that it can run on phones or supercomputers, and that it is widely used for "big" systems sold by IBM, HP, Oracle, etc., is proof enough that it is still widely regarded as a "serious" operating system.

If I want a nice workstation experience, I will just install XFCE and be done with it. It's not perfect, but no desktop experience ever is. I have no problem trading the extra desktop polish for nice software management (APT) and all the command line goodies.

Interesting you say that. IBM did some studies decades ago and they found producitivity was directly correlated with response time of the machine. I wish I had the results in front of me. I can't find the article and everything is now behind a paywall. But one thing stood out: if it takes more than a second for the system to respond to you it destroys your thought process and productivity goes down the drain. This was 20 or more years ago. I am sure now when people are used to subsecond response times everything is recontoured around expectations. For development, editing etc. response time surely matters if you care about getting anything done. It is very frustrating to switch applications on a normal desktop and wait to be swapped/paged in again or have your mouse freeze when you have a process reading from disk. Try doing a long find and then getting anything else done at the same time on a normal desktop. Not happening.

What I notice with myself is that the computer trains me. If everything I do goes boom boom boom, then I work boom boom boom. But if I do a swipe-n-drop but the text doesn't drop, then I have to go back and clear it out, then drop again s-l-o-w-l-y , after this happens two or three times then I start doing everything s-l-o-w-l-y.

There is a screwup in soundplayer - if you try to play a variable-bitrate mp3 it will not play. Then the next mp3 you try to open it crashes and locks up and you have to kill -9 it, bla bla. So now if I hit a variable bitrate mp3 and soundplayer won't play it, I close soundplayer entirely. Then go on to open another mp3. There are some issues with the fm as well, so there are some functions I avoid.

Neither one is a big deal but the point is, if something bad happens often enough, then you slow down everything to keep that from happening. I flip out when the Assistant clicks the mouse more than three times in a row because that overloads the input queue. Computers train us very well.

So the point is, yes, I believe you. If the computer does not respond quickly even one time out of ten, then a smart user will instinctively slow himself down enough so that that one time does not happen, either.

Which slows everything down way more than it logically should.

I really don't think context switches are our main problem in desktop computing.

I think their results show it goes further than just slowing down. It actually kills productivity because people can't work at their own rate. If it only made things slower that would be one thing. But it seems much worse, and that's my experience also- that if your editor or debugger or other tools get in the way they change from tools to another part of the problem. What the study showed was that bad response time disrupts the creative process in destructive ways. As usual, the answer will be to throw more hardware at the problem. But try as they might, that just does not seem to do the trick.

pbzip is IO-bound, so what you said is true. But for most CPU-bound tasks, the number of CPUs you have _is_ the optimal number of threads!

Path tracing (a rendering algorithm) is a task which scales linearly with the number of CPUs available (for all practical purposes... on a NUMA system with 256 cores and more you need to tweak memory placement as well to maintain the speedup, but that's not really important to this discussion). For this task, spawning as many threads as there are CPUs _is_ optimal. If you know a better solution to this that doesn't involve knowing the number of CPUs, then please say so

There are plenty of other CPU-bound workloads which have the same behaviour.



And which application has the focus on a multi-user system?



So what you're saying is that the kernel should have a magic crystal ball and use that to determine which process you find more important?

But still, the kernel will age the priority of processes if it figures out they're CPU-bound. The longer a CPU-bound process runs, the less important it becomes to the scheduler. So it should favour IO-bound processes (including GUI).

However, when you're compiling something, the compiler also does IO operations, which causes the kernel _not_ to lower its priority, which explains why you would experience responsiveness issues in this scenario.

Adjusting the nice value of a process will hint the kernel that the process is either less or more important from the start and will keep the system responsive.


If you want to use a UNIX system, help the kernel and run the background tasks at a lower priority, and the system will work exactly as you want it to

If you want the OS to handle UI tasks in a special way, then UNIX is not what you should be using. On UNIX, every one of your processes is equally important to the kernel, unless you tell it otherwise or it figures it out on its own.

IRIX also has a special scheduling class for (soft) real-time processes. If the GUI used that, you wouldn't see any issues with responsiveness. However, SGI must have decided against that for some reason and they use real-time priorities only for recording video and similar tasks.



What would be a good approach then? You've agreed that spawning one thread for each image line isn't the right thing to do, so what is the optimal number of threads for a renderer if you can't get the number of CPUs?



It's possible to lower the priority of individual OpenMP threads, so in that case it works just fine on workstations. Within the same app you just check if the user ran the simulation/render job from the GUI or from the command-line and adjust priorities so it doesn't get in their way. Or you could just always use a lower priority. This is similar to the Maya example in my previous post.



Did you read the rest of my explanation? Spreading threads to other CPUs just because they're free would give you worse overall performance, including GUI apps.

The unresponsiveness isn't caused by the thread placement policy.


It would also be inefficient for the usage scenario you describe. If you want the kernel to treat your programs preferentially, then just tell it so!


Both of those OSes were made for much simpler hardware where cache locality and similar concepts didn't matter as much as they do today. If you changed their schedulers to take that into account, they would run even better on new hardware, thread placement isn't responsible for sluggishness. For a single-user machine, I agree, an OS like those would be better.

Speaking of schedulers... I took another look at Miser , the batch system on IRIX. It's not a fully-userspace implementation, as I had previously thought, but it has a kernel component too. It runs batch jobs from various user-defined queues whenever the system is idle. This kind of batch system is exactly what I had in mind when I talked about this in a previous post.

Next time, try using "nice gmake -j2" instead of just "gmake -j2". If you're still not happy with the responsiveness of the system, try using Miser. I've used IRIX even under heavy loads and have never experienced the kind of responsiveness issues you describe. It works well enough for me.

Did you experience similar UI responsiveness issues on other SGIs you have?



It is useful if you want to ssh into your machine from another location. On single-user OSes like BeOS or classic Mac OS, you'd have to run a VNC server and then you wouldn't get a separate session, you'd just control the session that's currently active.

If you don't need that, then yes, it would be a bit faster and more responsive


That's what I wrote. The last version of IRIX is used in both scenarios and everything in between.

Even in the Personal Iris era you had the Power Series racks with 8 CPUs and multiple users, so a single-user OS like you describe wouldn't have been useful there.

A big reason why it took off is that you had the same OS on both the low-end workstations and large servers, same behaviour everywhere. This made it easy to develop and test software for it.


You might like Plan 9, it was designed from ground up to fix the kludge that UNIX has accumulated over the years. However, since most people think that UNIX-like systems are good-enough (or aren't bothered enough to look for alternatives), it doesn't get much attention.

Another problem with alternative operating systems like BeOS and such is that they lack software. An OS without software is useless. If every program you need to do your work is only available on UNIX or crappier alternatives, then you don't really have much of a choice

The green screen is a bodge, not how it was meant to look: an A680 was designed for high resolution mono (1152 × 896, not bad for 1988) but can be persuaded to drive a decent multisync with BNC inputs, using one colour and one sync (you can see the two output BNCs at http://acorn.chriswhy.co.uk/Pics/A680G.html and it's how I run my R140 on the rare occasions it gets an outing). So you can have green, red or blue screen!


I think that rules RISC iX out - AFAIK it never had what one could call widespread use in any degree!

A simple kludge to fix the problem for Hamei would be to schedule a cron job that runs as the root user, and renices any processes running as user "hamei" with priority 0 to a negative value like -10. That would make their priority higher than the system processes.

Maybe a line like this in /etc/crontab ...


That should renice all the processes owned by user "hamei" every minute to a high priority level. That means that for any significant interactive work, the process is guaranteed to take higher priority than other things on the system. The command basically takes no time to complete, so it should never affect system performance in any negative way.

An alternative would be to run a script that identifies just some GUI programs running as hamei, and renices them appropriately. That is if he would want to separate out GUI work from terminal stuff. Basically it shouldn't take more than a few minutes to write up a script like that. Here's an idea....


Of course, there may be eloquent or more efficient ways to do this than the example code... but that's the idea. It would have to run as root because only root is allowed to renice programs to a higher priority (negative number). It could be similarly scheduled through cron.

This will also renice any compile jobs and other background tasks that are running under that username, so it will be worse than before

I think it's still best to use "nice -n 20 [command]" (or "nice +20 [command]" in csh/tcsh) to run any jobs which are known to cause heavy loads. They will then run only when the system is idle and should greatly improve interactive performance.

jwp's method sounds much more... UNIX-y to me

It depends on which is the most reliable way to select the processes to modify. For example, if it's a "Hamei vs. System Processes" issue, then doing it by user ID will work fine. But if it's Hamei himself who is running processes that hog resources from himself, then that's a different issue. If he knows that some program will do intensive work, then he can just run in with nice, and that's a pretty good fix for the problem. If he runs the program from an icon or shortcut, he could even modify it to include "nice" in the invocation. I'm not sure what the exact situation is, though.

If he wants to run certain programs at a higher priority, though, then normal users aren't able to do that, so root would have to make the adjustment. That's what the second example does with the little script.

On the subject of reponse time, I just wanted to add that I can't imagine Ken Thompson and Dennis Ritchie working on Unix using ed as the text editor, printing out to a teletype. Yet they wrote the basic operating system this way, and that was more or less the "standard editor" until vi came along (and even longer at Bell Labs). It seems they were working on a totally different level. These days everyone uses big LCD monitors and multiple terminal windows, but who would claim to be more productive than Ken Thompson was using ed?