Posts Tagged ‘IBM’

x86 Scale Up

Thursday, September 11th, 2008

I have been introduced to a very cool software/hardware combination yesterday. It has been, without exaggerating, one of the coolest things I have seen in a while.

As you may know, x86 has an issue with scaling up. It’s that x86 architectures and price don’t justify scaling up to tenths and hundreds of CPUs. The multi-core technology introduced in the last few years made a four-way server seem trivial today, where in the past it was a high-performance server for large (and expensive) data centers. It is very common today to purchase an eight-way server at a price of a mere commodity server – all thanks to the multi-core technology.

However, when compared to the large Unix data centers, where 64 and 128 cpus are rather common (I will emphasis – the large Unix data centers), although nowadays, per-core, x86 is somewhat more powerful, for a large load set, it could not rival any many-way server. The common solution with x86 was to “scale out” – add more cheap servers and manage the workload in a more distributed way. Yes, you might pay with communication overhead, however, this can be made cheaper still.

With a distributed load sharing came the illnesses of communication latencies. Myrinet, 10Gb/s Ethernet and Infiniband were a common, yet expensive (as it was a niche market) solutions, and still – for distribution of high loads, they were well worth it. Still – a large scaled-up server based on x86 was nowhere to find.

No more. With ScaleMP’s concatenation you can “bundle” a set of servers using Infiniband link into a single huge-multi-way, huge-ram server at a very low cost, relatively.

Think about how you can purchase your current server, for example, your eight-core server (two quad-core cpus), and in time, scale it up into more powerful server (add another two quad-core cpus), or add more RAM, or more network interfaces, or whatever.

This is not as fast as the IBM x3950 board-link (excuse me for not knowing the exact name), so it is not ideal for databases or systems which tend to create a lot of cache-misses, however for large (actually – very large) SMP systems, it could be great. It can allow any company which feels that the current server might not be enough the safety and assurance that they can actually scale up, using the same server, into adding more cpus and more RAM to the server at any time.

I is supported, as far as I know, only for Linux at the time being. It diminishes some of the distance between the large Unix machines and the modern Linux, for a fracture of the price.

I liked it.

Bluetooth Mouse on my Ubuntu Laptop – an easy feat

Thursday, June 19th, 2008

I was surprised at how easy it was.

You need to do the following:

1. Find your mouse’s address using ‘hcitool scan

2. Verify that you can pair the two devices using ‘sudo hidd –connect XX:XX:XX:XX:XX:XX

3. Edit /etc/default/bluetooth, uncomment the additional line with the HIDD_OPTIONS and set it to be

“–connect XX:XX:XX:XX:XX:XX –server”

4. Restart the service ‘bluetooth’

This works immediately after using the hardware button to enable/disable BT on my IBM Thinkpad. If I turn the mouse off, I need to press on the hardware button to disable/re-enable the bluetooth.

Oracle ASM and EMC PowerPath

Wednesday, May 28th, 2008

Setting up an Oracle ASM disks is rather simple, and the procedure can be easily obtained from here, for example. This is nice and pretty, and works well for most environments.

EMC PowerPath creates meta devices which utilize the underlying paths, as mod_scsi sees them in Linux, without hiding them (unlike IBM’s RDAC, for example). This results in the ability to view and access each LUN either through the PowerPath meta device (/dev/emcpower*) or through the underlying SCSI disk device (/dev/sd*). You can obtain the existing paths of a single meta devices through running the command

powermt display dev=emcpowera

where ’emcpowera’ is an example. It can be any of your power meta devices. You will see the underlying SCSI devices.

During startup, Oracle ASM (startup script: /etc/init.d/oracleasm) scans all block devices for ASM headers. On a system with many LUNs, this can take a while (half an hour, and sometimes much more). Not only that, but since ASM scans the available block devices in a semi-random order, the chances are very high that the /dev/sd* will be used instead of the /dev/emcpower* block device. This results in degraded performance, where active-active configuration has been set for PowerPath (because it will not be used), and moreover – a failure of that specific link will result in failure to access the specific LUN through that path, with disregard to any other existing paths to the LUN.

To "set things right", you need to edit /etc/sysconfig/oracleasm, and exclude all ‘sd’ devices from ASM scan.

To verify that you’re actually using the right block device:

/etc/init.d/oracleasm listdisks

Select any one of the DG disks, and then

/etc/init.d/oracleasm querydisk DATA1
Disk ‚ÄúDATA1″ is a valid ASM disk on device [120, 6]

The numbers are the major and minor of the block device. You can easily find the device through this command:

ls -la /dev/ | grep MAJOR | grep MINOR

In our example, the MAJOR will be 120, and the MINOR will be 6. The result would look like a single block device.

If you’re using EMC PowerPath, your block device major would be 120 and around that number. If you’re (mistakenly) using one of the underlying paths, your major would be 8 and nearby numbers. If you’re using Linux LVM, your major would be around the number 253. The expected result, when using EMC PowerPath is always with major of 120 – always using the /dev/emcpower* devices.

This also decreases the boot time rather dramatically.

i810 dual-pipe issues with power management

Friday, May 9th, 2008

I have had a problem with my IBM X41 – ever since I have started using Ubuntu 7.10 (after a nice upgrade from 7.04), whenever the lid was closed, and reopened – the display would have flickered for a short while (while the lid is up) and then blank completely.

My (ugly) workaround was to force the computer to sleep whenever it happened. It seemed to be a workaround good enough for most cases. On some cases, the laptop would do just the same as it was placed in its docking station.

I have found an Ubuntu bug here, which seems to expose this problem too. It exposed few additional problems as well. The error message I got (through SSH, of course) when viewing the logs it said that the video card detected pipe A to be the active pipe, that it stopped using pipe B (which appeared to be the internal one) and that it decided to disable clone mode. Wow. I just lost my internal LCD. Connecting an external display, I get the whole picture working just fine, however, I cannot use the laptop like that.

After a major struggle with various i810 options, I have looked and found an option to disable Power Management. I have done so, according to the note here, and it solved all my problems in this area – for now.

The first biological portable computer

Tuesday, June 19th, 2007

This is not exactly a technical post, but I had to bring it online.

I am proud to be one of the first persons, if not actually the first one to own a biological portable computer (BPC). You will find no other such thing, I think. I have searched Google, after all.

Although the docking station, or Biologic Electronic Interface (BEI) looks quite similar to the IBM X40’s docking station

The docking station, or Biological Electronic Interface (BEI)

You can see the difference. Unfortunately, in this picture you cannot clearly see the micro conductors which are used in the BEI plug, which is, actually, the method of connecting a simple and regular USB mouse to the BPC.

The BPC has the ability to self support. It is self propelled, and will walk(!!!) back to the BEI whenever the need arises. It has the computational power of hundreds of normal PCs, and although it runs its own unique OS, it has a simple interface which accepts commands. In the picture below, you can see the BPC in its docking station, charging.

The BPC inside its docking

As said, accepts commands, but only seldom performs them. It’s a prototype, and yet has a way to go. It has to fit the docking better (this prototype BEI has been developed as a case study), and should go through more modifications until it can be sold commercially. Yet, very impressive.