Archive for the ‘General Hardware’ Category

Getting rid of some junk…

Monday, November 21st, 2011

It wasn’t junk once…

This stuff used to be useful, but it has been laying around for a long while now, doing nothing but collect some dust. I have ‘donated’ some stuff to someone who actually wanted it, but neither him nor me can find a use, nowadays, to a monochrome display card with an ISA 8bit connector, or about 20 56k ISA and PCI modems, or all kind of other old, and once useful junk. So I have let go, and the picture you see is of most of the stuff I have taken to the electronics recycle facility nearby. That was a hack of a work.

Remaining: Some desktops (maybe I will throw away some more, donno yet), Sun Ultra 80 (Since you can never get a SPARC platform when you need it), an IBM FastT200 (one day I will do something with it. Donate it to a better cause than to the junk yard), and, well, that’s all actually.

BTW – not in the picture – two IBM servers and two Dell servers, and many hard drives, which were given to the helpful man who assisted me with carrying this all to the recycle center.

 

 

 

 

 

 

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.