""   --
ftdock optimization
[ 17:03:39, Tuesday, July 11 2006 ]
Note: in this entry I'm describing how to optimize for ftdock, but the same steps can be taken to run any program with a high priority

One of the things that's very common in computer gaming circles is the optimization of ones computer to play games much more efficiently than a system with default settings.
This process had its start way before fanatical gamers, however. System administrators have been making judgement calls about which programs should have precedence over others since multithreading operating systems have been around.

First, a few notes on the history of multithreading. Since I'm running ftdock on a mac, we'll start there.

For the first several iterations of the macintosh operating system (up to 6.0 I believe), the Finder (that program that all other programs were windowed through) was restricted to running a single program at a time. That meant that if you were typing in a word processor, you couldn't immediately switch to a paint program, or any other for that matter.
Note that at the time, this was no great problem, because people had been used to swapping in program disks to run different programs in a similar manner.

However, with the advent of [MultiFinder], this all changed. Multifinder originally started as a clever hack that allowed more than one application to run at a time, basically by halting one program and activating another. When Mac OS 7 appeared, Multifinder became a integral part of the finder and the instantaneous switching between programs was here to stay.

When Mac OS X was written upon a Unix kernel (BSD to be exact), it brought along with it the tried and true fine-grained permissions and capabilities model of the server world. The Unix OS(es) were written from the ground up to give administrators complete control over what programs could run, what they could do, and (the crux of this story), how fast they could execute.

You see, a computer's OS can't just allow all the programs currently running to run in an uncontrolled manner. Some programs aren't very important (like internet browsers or IM programs), while others are vital (like the kernel, the TCP/IP stack, servers, etc.)
Therefore, the OS can be instructed to allow some programs more time to execute, and others not as much time. When their allotted time is up, the program must relinquish control back to the OS. When they fail to do this, your computer has hanged, or "crashed".

In a true multi-threading environment (such as nearly all unixes, and lately Windows XP), the OS is able to keep all the programs execution cues separate, meaning that even if one application crashes, the system (and other applications) are able to continue running.

So, how can a user tell the OS which programs absolutely must be given as much processor time as possible, and which programs are dispensable?
It's quite simple really. As long as you have administrator access on your Mac, and have a cursory knowledge of the Terminal utility, these instructions will be quite simple.

Note: If you need instructions on how to compile ftdock, you're in luck: [ftdock installation].

The first thing you'll need to do is renice the running ftdock application. To do this, you'll need to get the Process ID or "PID".
There are two ways to do this. The easiest way is to fire up the "Activity Monitor" and simply scanning the list for the correct process name and corresponding PID. You can also get the answer by typing in the command "ps" into the Terminal.

[ftdock_process_a.png]

Notice that with aggresive use of renice and the halting of non-necessary system processes, I'm able to get over 90% of processor time available to the ftdock process (96% CPU). More on how to halt system processes in a second.

Once you have the PID, you can tell your mac to assign it a high execution priority with the "renice" command, like this: sudo renice -20 28920 (28920 is the PID for ftdock on my computer). The "-20" assigns a negative nice value, which means that ftdock will now take precedence over all other programs. The more negative the nice value, the more time that program will have to execute. A postive 20 value, on the other hand, means that the program will only execute if no other programs are currently needing time.
Having a range of 40 possible priorities might seem like overkill, but it's this fine-grained allocation of resources that the Unix operating systems are known for.

Notice the sudo command before renice. To assign any program a negative nice value, one must be superuser. (An administrator). The sudo command allows you to execute the following command as superuser.
Note: you might be asked to enter your password when using the sudo command. If you're not an adminstrator, it will be rejected.

After renice, you should probably take a look at the Activity Viewer utility to see if there are any system processes that are taking up lots of computation power. More often than not, there's some unimportant processes that you can freeze to free up processor power.

Freezing system processes is not for the faint of heart. If you freeze the wrong process, you could end up crashing your system, or making it unresponsive. With that in mind, you should probably read over [this list] and [this list] first.
The easiest way to free up resources (of any kind) is to simply quit the applications they belong to. This means having only the fewest open applications necessary. If you renice a program with a nice value of -20, your entire computer will be very unreponsive, in any case. You should also open up the "Sharing" preferences control panel, and make sure that no servers are running either.

In the following picture, I noticed that the process "loginwindow" was regularly taking up over 20% of available CPU time. The loginwindow process (in this example PID=250) does a variety of non-critical things, including login/logout, some system noises, etc.
To temporarily hang (or freeze) a system process (or any process for that matter), all you have to do is issue the "kill" command like so: sudo kill -STOP 250 (250 being the loginwindow PID in this example).

Freezing a process will cause to to show up as "hung" in the Activity Monitor, like so:

[ftdock_process_b.png]

Notice the "windowserver" process. Don't freeze this process, or you'll have all sorts of trouble. I'd recommending only freezing the top CPU hogs, and only the ones you know won't screw up your system. Determining which ones these are is sort of a trial-and-error process, although an internet search on the offending process name will often give you some insight.

To "un-freeze" a given process, issue this command in the terminal: sudo kill -CONT 250.
Note that the "kill" command is something of a misnomer, as it can do lots of things beyond just killing processes. Incidentally, ever had a process you just couldn't kill? By using the -9 kill option (kill -9 ), you send a non-ignorable, immediate halt signal. If that doesn't terminate the rogue process, nothing will.
By the way, the kill -STOP signal is really useful if you need to temporarily stop the process you've set up to have top priority. Because it has such a high priority, any other programs will run as slow as mud, so being able to temporarily freeze the monster process is very helpful.

Note that on my system, I had to disable my screensaver, as well as automatic logout, because these were handled by the loginwindow process. The moral of the story is that the effects of freezing a given PID might not show up right away, so be careful. It's not (at all) likely that you'll mess up anything that a quick reboot won't fix, but don't come crying to me if you lose something.

As you can see in the two above figures, I'm able to provide almost 100% (sustained) CPU availability to the ftdock process. This is contrasted to ftdock's previous CPU usage of 40-50%. This means I've effectively halved the time necessary for a docking run. Nice (ha ha).
Leave Comment
Comments are owned by whoever posted them and I am not responsible for their content. However, I do reserve the right to edit and/or delete inappropriate comments as I see fit.
 
< Prev [11:28, 07/11] (Elihu) Next > [11:28, 07/11] (Elihu) (this author)
< Prev [15:15, 07/04] (June) Next > [15:15, 07/04] (June) (other authors)
Calendar (July 2006)
[powered by cable]
a [steelsnowflake] construct. all rights reserved.