Archive for the ‘General Hardware’ Category

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.

RHEL4 can see only 8 cores out of 16 cores server

Wednesday, May 21st, 2008

I have encountered it on several cases. RedHat Linux ES, by default, uses smp kernel which is limited to eight cores, or two sockets. You find out that your multi-socket hardware, with its 16 (or more…) cores show you only the first eight, both by the simple method of running ‘top‘ and then pressing on ‘1‘, or by running ‘cat /proc/cpuinfo‘.

A simple solution to the problem is to change grub so it loads the largesmp kernel at boot time, and reboot. You will get all your cores.

This is not required, for some reason, on AS server.

The file skypeforpocketpc.cab is not a valid windows ce setup file

Friday, February 1st, 2008

I have an iPaq running Windows Mobile 2003 SE. The above error was something I’ve seen when I tried installing SkyPE for PocketPC on it.

It appears that SkyPE have decided to sign cab files, according to some new (and pretty unexplained) concept of MS, disregarding any existing non-WinXP or non-ActiveSync4.2 users (and I am a member of these two groups).

The solution was found in SkyPE official forum, in an unofficial post (as most of them seem to be) right here.

The code supplied actually works, and I will consider using variations of it on any future signed cab file I might encounter. I hope it will help… 🙂

New version of Cacti, and using spine

Monday, January 21st, 2008

A while ago, a newer version of Cacti became available through Dag’s RPM repository. An upgrade went without any special events, and was nothing to write home about.

A failure in one of my customer’s Cacti system lead me to test the system using “spine” – the “cactid” new generation.

I felt as if it acts faster and better, but had no measurable results (as the broken Cacti system did not work at all). I have decided to propagate the change to a local system I have, which is running Cacti locally. This is a virtual machine, dedicated only to this task.

Almost a day later I can see the results. Not only the measurements are continuous, but the load on the system dropped, and the load on the VM server dropped in accordance. Check the graphs below!

MySQL CPU load reduces at around midnight
as well as the amount of MySQL locks
and innoDB I/O
A small increase in the amount of table locks
A graph which didn’t function starts working
System load average reduces dramatically
Also comparing to a longer period of time
And the virtual host (the carrier), which runs several other guests in addition to this one, without any other change, shows a great improvement in CPU consumption

These measures talk for themselves. From now on (unless it’s realy vital), spine is my perfered engine.

Sony PSP – Connecting Keyboard – Get more out of your PSP

Monday, October 1st, 2007

I wanted to purchase a keyboard for my PSP for a long while. Only several days ago I actually did it. I was surprised at how simple it is to connect and use it.

Mind that it:

1. Requires OE firmware (I use 3.03-OE)

2. All is a beta/alpha software, and misbehaves accordingly, on occasions.

Since I was confused myself, I will clear some of the fog that surrounds the keyboard drivers – There are currently two major keyboard software plugins. One of them is “driver” (plugin) based, which gets added to the flash, which is called pikey (pi like the number). The 2nd one is implemented inside specific homebrew software, and uses the PSP IR Library. The pikey will allow using the keyboard at all times, and the interface is the same as the normal input interface, but very fast. The PSP IR Lib will work only within Homebrew apps which include the library, and will not work outside of it. It will supply, however, a more native keyboard-like interface, and respond faster and better when working.

Both systems are not compatible. I discovered it the hard way, but no harm was done (had to take the battery out several times).

I was able to download pikey from N00bz! website, including instructions. I was able to download IR keyboard capable software (aka, IR KB Lib) from ZX-81’s website. From there I have downloaded an SSH client (PSPSSH V 1.09), etc.

Using the installer, install the pikey, and set it to apply to both game mode and VSH. Reboot the PSP to the recovery console (Start it with right trigger pressed) and you will be able to activate both plugins in the “plugins” menu.

Check that you can use your keyboard with the test utility (also supplied with pikey), and reboot again to the recovery console, where you should disable the “game mode” plugin.

You are now able to use the keyboard inside the XMB (the interface) and in the browser. You will be able to use the IR Lib interface in PSPSSH, and other similar software.

Good luck.

The output of the command “top” using PSPSSH on a remote server. Nice…