In Case You Want To Try It, Too

The iMac project got abandoned. I got an ancient notebook for free that is now running Linux itself. However, if you ever want to do it yourself, check out freeNX. I've been using it from my Powerbook 12" to my big Linux box. It works very well.

Interesting Idea

I've come into the possession of an iMac Blueberry, which is a 450MHz G3 with 192MB of PC-100 ram (YAY!). I stuffed a 120GB disk in it (it had none, having been declared 'dead' by the school it came from), successfully ejected the disk in the DVD drive, which involved disassembling the computer, as the disk was too thick for the slot and kept binding. Then I installed Linux on it (Mac OS X on a 450MHz machine with 192MB ram? Really?)

After messing with it for a bit, I got it to work as a client to my other machine (read my other posts for an idea as to why I'd try to do that). The idea is to create a machine for homework that isn't expensive because I'm tired of spending hundreds of dollars fixing computers destroyed by the kids. Since I've got that other machine just sitting there, as I have to go to a real job these days, it makes sense to employ it as an application server.

I'm so close, too. If the audio can be made to work (my sysadmin friend is working on it) then I can use it for almost all uses the kids put a computer to. Unfortunately, setting up audio in is somewhat harder, and necessary for some of the apps. I guess I'll need to run a Mac for that. Maybe I'll just set up the multimedia machine for that.

Mourning The Loss of Threading

I've used many different platforms. Through the years, I've gravitated towards systems with native threaded UIs. OS/2, for instance, had a threading system that led to accidental threading. The original idea behind COCOA on Mac OS X was to have one UI thread and one worker thread per app. Java UI is easily threaded.

However, many of these systems now run apps with no threading at all in them, leading to unresponsive UI elements. The user has no idea why the app is unresponsive; they're just upset about it and will stuff the click buffer full of clicks about it, which will have unintended consequences when control returns to the UI element.

Of all of them, I think I like Apple's automatic creation of worker threads. It removes the threading issue from the developer's mind. The developer is free to develop while the OS manages the creation and removal of threads.

I guess this approach is too 'hard' because it seems Apple has largely abandoned it, going with the standard one thread (process) per app, which has led to a less responsive UI. Before, when a given app was hard at work, its UI thread was still responsive, meaning you could click on things and so on. The 'work' was in a worker thread. Since this happens as a result of the OS' UI layer calling the app's action delegate in a separate thread created by the UI layer for this purpose. Since OS X uses Objective C, which does message passing by default, synchronization is something that can happen at the framework level, making things much easier on the developer.

However, there seems to be a tendency to ignore the idea of threading. Synchronization issues kind of suck. Developers have to maintain re-entrant discipline and need to code in such a way as to avoid deadlocks and data corruption. Discipline is often in short supply as development managers feel the need to push software out on short schedules, meaning they need to simplify their development, which is one reason threading is ignored. Threaded code has a different set of testing requirements, for instance.

However, if, as is done in OS X, the threading is a simple split between the UI layer and the app, managed by the OS, the majority of the issues can be tested for by the OS developer. This means Apple has to increase their testing, but it also means all Apple apps look lots more performant by default than comparable code on other systems.

Ok, Why Did I Pay $1500 For This?

I found a solution that has worked for a bit now for the Macbook headphone jack red led of death problem, where the internal speakers quit working after headphones are removed: take a q-tip and remove some of the cotton from the tip, trying to make sure there are not lots of wisps left around. Push the q-tip into the headphone jack. If it takes too much work, remove more cotton. Try to keep the cotton removal equal along the length of the q-tip because what you're trying to clean is waaaay back up in the jack. Once the q-tip is in there, twist it around, move it in and out and then remove it. If sound does not start up immediately, repeat the process. If sound still does not start, put a pair of headphones in the jack and remove them. If it still does not start, I guess you're not as lucky as I was. Btw, the q-tip came out really, really disgusting. Apparently that jack gets pretty dirty, and dirt was clogging the microswitch. Why it would work sometimes and not others and suddenly switch off all by itself remains a mystery, but, for now, it's working.

Why You Want a Dual or Better

The Macbook headphone problem seems to be solved most of the time by blowing in it. Why this is is beyond me. I'm still quite upset about it, but at least I can get my music playing now while I write.

That is, of course, not the point of this post, just an aside. I thought I'd write up the principle arguments for a dual socket system and then turn the next post over to a friend of mine who holds the opposing view.

First of all, if you do any database work using a process-based database such as Oracle or Postgres, the more hardware threads you have, the better, generally. Since, in most architectures, each database process maps to at least one thread or process in the middleware or front end, you will find things go faster if you have even more hardware threads. When, due to the constraints of the problem, you find that your system has hundreds of threads with tens of database connections, in a time-critical application, you will discover that the dual socket system with its lots higher hardware thread count will complete in a lot less time.

One argument that has been put forward is that a cluster is more efficient than a single large machine. It may be that it is more cost-effective, but it cannot be faster because the latency involved in communicating over even well-designed gigabit is much, much higher than communicating locally. You can architect around this, using lots more processes and so on, but at the end of the day, a single bigger machine will beat several smaller machines for database manipulation.

There are lots of work profiles that this is not true of, such as video processing, where, quixotically, a single socket machine easily eats up the bandwidth of any sufficiently large drive, meaning that more than one socket really isn't helpful. The problem with video actually becomes one of getting the video to the processor, not one of getting enough processor threads.

However, I and many like me find it lots more convenient to have one large box rather than many smaller boxes primarily because the maintenance cycle is so much lower. I don't have multiple machines to constantly shepherd.

It is true, barely, that multiple hot single socket machines are cheaper for the amount of processing power they have than one large machine, but there are mitigating factors even here. For starters, any enterprise geek will tell you that the disk performance matters, and once you're done outfitting those single machines with adequate disk, the price tilts in favor of a single large machine. This is due to the price of SSDs, which may decline enough in the future to reverse the position, but, for now, a single, fast SSD is enough for most profiles in the single big machine, but you will need one for each small machine to achieve the same level of performance.

Further, ram aggregation is a good thing. While there are consumer products that can take more than 8gb ram, they are frightfully expensive, both for the board and for the ram, which invariably uses 4gb modules, which are very expensive. A decent dual socket board will have a minimum of 8 dimm slots, for up to 32gb ram. 16gb ram at the moment is very cheap. Now, in a single big server, you will find that the majority of that ram goes to buffers, which are shared among your processes. In other words, lots of your data is common amongst the processes you're running, but with multiple machines, it all gets duplicated around.

Now, if you're doing 3D rendering or video processing and have already solved the throughput problem mentioned above (I recommend a massive NFS server with at least 2gb, preferably 8gb cache) then you don't really care because neither one of those really burns ram. However, if you are working with a database such as Postgres, you will find an 8gb system to be inadequate once you get the base system and the shared memory (I was running 3gb shared memory for Postgres alone!!!). You end up with as little as 3gb buffers and cache, which cause lots of disk access.

Switch to 16gb and you can run everything at once. You can run two 2gb Java instances with a 2gb Eclipse instance, 3gb shm for Postgres, about 1gb Postgres footprint, and a 1.2gb os footprint, for 9.2gb, leaving nearly 7gb buffers and cache, which is normally enough to avoid significant disk access. And, yes, you'd have to run at least two machines to achieve that same ram footprint using consumer hardware, meaning you either have to fiddle with 10g (don't tempt me; I already have one card) or accept lots higher database latency. Alternatively, you can get the whole thing into one machine by dropping some of the java footprints, but that significantly increases the cost of garbage collection, which slows down the java processes.

So, the reality is that, despite that the main reason I have such a big machine remains that dual socket machines are just more interesting to me, I really could not live on less broad shoulders. And yes, I am trying to save for a quad socket system in the future, which is why I have the 8000 series Opteron processors rather than the 2000 series, as it would only cost about three hundred to get two more 8358se procs, nine hundred for a quad socket board, and around $240 for 16gb more ram. My case is large enough, my psu is both large enough and equipped with the appropriate connectors. I do need to replace the stock fans (100mm case fans, four to a side) with Scythe Kaze2s, for around two to three times the airflow, as those 8358se procs run very hot.

I am also going to eventually add a second Radeon 3870HD because I am running into a problem with dual screens where if both screens are receiving significant amounts of data, they tend to stutter. It is possible the problem is actually in XFCE, which I must investigate first, but I do have to say the machine is pretty much bored out of its life, playing hulu in one screen and freeciv in the other. When the freeciv app starts moving stuff around in a hurry, the flash hulu player stutters, a problem that is worse full-screen. Since I only ever tax at most three cores, as evidenced by the fact that only three cores go to full speed with the on-demand governor, and since the hulu playing happens without ever causing a cpu to go above the floor freq (1.2ghz), I think I can reasonably assume it is not a cpu load problem. I think I can also reasonably assume it is not a bandwidth problem, as the video card is in an x16 PCI-e slot and the system has four DDR-2 667MHz memory busses, and is doing interleaving on top of that.

One more thing I'm fiddling with is the need to have open gl on this radeon card in linux. I just want the pretty open gl screensavers. Seriously.

Heat Problems, Again

Mash has been, well, running a tad hot, not really overheating. It's the same problem, where a null zone has developed over the chipset near the video card leading to elevated temperatures there. I pulled the cover off and found the culprit: a failed fan. Turns out it is a 100mm fan, which are pretty rare. I found a Scythe Kaze running around 42 cfm, which ought to be substantially better than the 15-25 cfm the fans in there are currently doing.

To fix it temporarily, I wedged a 120 mm Ultra Kaze in there, which produced substantially higher flow, despite not being sealed into the fan gang. I am so impressed with the Ultra Kaze fan. Many say they are too loud, but my machine is close to a vacuum cleaner at full speed anyway.

I did find a Delta fan, 92 mm, that can blow around 100 cfm, but it is also lots more expensive than the Scythe. I'd have to re-engineer the holder. I'm still considering it because 400 cfm would be nice.

Well, I Did Pay $1500 For It

I am speaking, of course, of my shiny aluminum unibody Macbook, the thorn in my side. The networking is all working, which is a relief, but the stupid red led of death is back. I have spent a lot of time trying to figure out what triggers it and how to fix it, even to the point of having an old headphone plug to stuff in there occasionally, but the one thing that seems to work most often is blowing in the hole. What is odd is that canned air does not work. Go figger. Every time it happens, I want to launch into a rant about badly-designed headphone jacks. Basically, they're subjected to every torque and abuse in the book, so they absolutely must be isolated from the mainboard and shock mounted. The plug itself has to be constructed of very high grade material. Here is not a place you want to save a few pennies, especially with netbooks nipping at your tail. Seriously, Apple, don't let me spend too much time wondering why I spent $1500 for this thing...

I guess I have to take it out to a 'genius' who will hem and haw and take it apart and look at it and tell me he can have a logic board in by monday or whatever, being as how it is still under warranty, but I hate dealing with that sort of thing. That is one major reason I've traditionally bought Apple hardware, the aura of being somehow a cut above, but the current Apple is in a relentless drive to produce stuff whose internals are ever less well-designed. There's a hundred dollars worth of machined aluminum casing, glass and so on, but the actual system inside sux.

Its networking is sub-par. Using the same disk, a Macbook Pro gets much higher throughput. This may also be due to the drive subsystem, which is also sub-par. To be fair, the Macbook Pro has a processor with adequate cache, but no computer should spend more than ten percent of its cpu handing nfs copying. Of course, lots of that is the hideously bloated internals in OS X, and I do use Linux so I have the bar set pretty high, but some of it is the net controller they use, which is a bargain-bin part. The ancient HP laptop I have has a Broadcom nic. It didn't cost as much as this thing new.

So, yeah, not a bad machine to write blogs on, but a disappointment in most other ways. I understand the new Macbook Pro 13.3 is supposed to be lots better, but, hey, I already paid $1500 for this.