Ubuntu 7.10 on an old PC

November 20, 2007

My little boy kept asking for Ubuntu on his PC, and I finally installed 7.10 Gutsy Gibbon last weekend. I ran into some problems I hadn’t seen installing it on two newer PC’s, so I thought I’d pass along some tips to others who may be making old systems brand new.

The first problem was that the GUI installer would not run on the small memory (256MB) system, so I had to use the alternate text installer. (Actually, as I found later, that may not have really been the problem.) The MD5 signature of the alternate installer ISO file I downloaded matched, and I burned a CD. That CD worked fine up through the point where it repartitioned the disk, blowing away the old working operating systems. But then the installation failed, on a CD read error.

I burned many more CD’s of the older 7.04 Feisty Fawn as well as of 7.10, and all failed. First lesson learned too late: go ahead and spend the extra time letting the installer do the "verify CD" operation before you blow away your old OS. Finally I burned a brand new CD-RW (700MB – small ones won’t hold it) at 4X speed, instead of the default "fastest possible speed" I had used earlier. It may have been the name brand (Maxell) CD-RW. Or it may have been writing at a slow speed (that was fast back in 1999 when the target PC was built). Anyway, that did the trick, and I had no more CD read errors. Maybe the original GUI installer would have worked if it had been burned on a high quality CD at low speed.

Once 700MB of software was installed, it immediately set about downloading updates to replace a great deal of what I had just installed. Sheesh, the OS is only a few weeks old and already everything is outdated. Why do they even bother with the CD image instead of just shipping a net bootloader?

The net update stalled – the screen seemingly frozen. After an hour of uncertain waiting, I broke out of it, killed a runaway process, and looked to see whether enough of the system was stable to allow it to recover. The problem was scrollkeeper. For some reason it causes no trouble on two newer PC’s, but here it prevents software updates from completing.

http://ubuntuforums.org/showthread.php?t=50796

http://ubuntuforums.org/showthread.php?t=596182 

The draconian fix suggested in a forum, to make all scrollkeeper
executables non-executable, took care of the problem and the new system
now works fine. Cool games and all.


Bach por flamenco

November 15, 2007

Today’s music is Bach por flamenco by Miriam Méndez, a pianist and composer from Seville who studied with Riccardo Chailly. In SPEC we have fair use rules regarding competitive performance claims. If you say your system is the fastest, you must say the fastest what. For example I couldn’t just claim that UltraSPARC T2 is fastest on a high performance computing benchmark without mentioning that is in comparison to other single chip systems and telling where the data came from, thus allowing the reader to easily see that there are faster multi-chip systems. Often the subsets make sense in terms of real customer needs. But sometimes the descriptions of the class of results being compared becomes rather strained as marketers from many companies try to find some delineation that will allow them to claim the #1 spot.

With that in mind, let me state unequivocally that Méndez’ is the best flamenco interpretation of the Bach preludes and fugues that I have ever heard! And if you can’t imagine such a thing, all the more reason to take a listen. It’s quite nice to listen to – one of those unusual combinations that seems natural once you hear it.

 


How fast is fast enough?

November 14, 2007

Occasionally I’m asked to comment on a cooltst analysis of workload suitability for UltraSPARC T1 and T2 systems, and I can’t draw a conclusion because I don’t know the customer’s intentions. An example: I saw one process using 11.6% of a CPU. If a single thread were consuming that much CPU I’d hesitate to recommend the workload for T1 or T2 processors because I might expect the workload to keep only 9 threads busy (100% / 11.6%). Since a T1 processor has 32 hardware threads and a T2 processor has 64, most of the throughput potential of the system could be wasted.

However, the process that was using 11.6% had 546 threads. If the CPU is spread at all evenly across those threads, then there is ample parallelism to make full use of a T1 or T2 processor. You need to dig down into the LWP details of the cooltst report to see what’s going on. In a future relase of cooltst, that part of the report will get a little easier to read.

But what if a single thread were using 11.6%? Would that automatically disqualify the workload? Not necessarily. In this case the workload was running on a 4 processor 1.06 GHz UltraSPARC-IIIi system. If the customer was meeting his quality of service requirements using only one ninth of one of those relatively slow processors, then a T1 or T2 processor ought to be able to meet or exceed those requirements, regardless of how much excess capacity of the system went unused.

So what is the customer’s intention? Does he want dramatically improved response time over his current system, or to maintain current service levels? Will the workload remain the same, or grow? Will it grow by adding more work to a single thread of computation, or will there be more users doing the same thing? Will he be consolidating the workloads of several current systems onto virtual machines on a single Sun SPARC Enterprise T5220? Despite the workload measurements shown by cooltst, there could be ample parallelism to exploit the throughput potential of UltraSPARC T1 and T2.


Will that run on an UltraSPARC T2?

November 11, 2007

Will a workload run well on a Sun SPARC Enterprise T5120, T5220, and Sun Blade T6320? The question has become easier to answer for the UltraSPARC T2 than it was for the UltraSPARC T1, which has limited floating point capability to match the majority of commercial workloads. However that means that for an UltraSPARC T1 you must be careful to ensure that your workload does not contain excessive floating point instructions.

By contrast the UltraSPARC T2 has enough floating point power to set the world record for single chip (Search form: enter "1 chip" in the "# CPU" field) SPECompM2001, the industry standard high performance computing benchmark for Open MP. Still with the T2 you need to determine whether your workload has sufficient parallelism to make effective use of the T2’s 8 cores and 64 hardware threads. Back when we used to worry about using 64 CPU’s in a Sun Enterprise 10000, the high performance computing community developed technologies like Open MP and MPI for portable expression of parallelism.

What’s different today is those 64 virtual CPU’s fitting into 1 RU of space, so we’re looking at a much wider range of applications. Of course if you’re consolidating multiple workloads onto a T2 based system using LDOMs or other virtualization method, then you already have those workloads running in parallel.

But what of the case where you want to mostly run a single application? If it’s written in Java then it’s likely to be multi-threaded, either because the language makes it natural to write the application that way, or because the utility classes called by the application are themselves multi-threaded. But a Java application might still be dominated by one or a few threads, and another application might be very well threaded.

The CoolThreads Selection Tool (cooltst) looks at the workload running on a system, and advises you about its suitability for T1 systems. As it happens, you can also use it to get an idea about the suitability of a workload for T2 systems – with some caveats. First, if you run cooltst on a T2 system it will complain that it doesn’t know what processor it’s running on; cooltst predates the T2 processor. But then you probably won’t want to gauge the suitability of a workload already running on T2, to be migrated to a T2. Second, ignore anything it warns you about floating point content being too high for a T1; that isn’t a problem for T2.

You can also just look at the workload yourself using standard Solaris (prstat) or Linux (top) commands, to see how the CPU consumption is spread across application threads. In upcoming blog entries I’ll talk more about this simple do-it-yourself analysis.

Disclosure Statement:

SPEC and SPEComp are registered trademarks of Standard Performance Evaluation Corporation. Results are current as of 11/11/2007. Complete results may be found at the url referenced above or at http://www.spec.org/omp/results/ompm2001.html