Posts Tagged ‘RAM’

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.

Preparing your own autoyast with custom Suse CD

Friday, August 17th, 2007

Suse, for some reason, has to be over-complicated. I don’t really know why, but the time required to perform simple tasks under Suse is longer than on any other Linux distro, and can be compared only to other legacy Unix systems I am familiar with.

When it comes to a more complicated tasks, it gets evern worse.

I have created an autoinst.xml today. It, generally speaking, installs a SLES10.1 system from scratch. Luckily, I was able to test it in a networked environment, so I helped the environment just a bit by not throwing tons of CDs.

Attached is my autoinst.xml. Notice that the root user has the password 123456, and that this file is based on a rather default selection.

Interesting, though, is my usage of the <ask> directives, which allow me to ask for manual IP address, Netmask, gateway, etc during the 2nd phase of the installation. sles10.1-autoinst.xml

This is only a small part. Assuming you want to ship this autoinst.xml with your Suse CDs, as a stand-alone distribution, you need to do the following:

1. Mount as loop the first CD:

mount -o loop /home/ezaton/ISO/SLES10-SP1-CD1.iso /mnt/temp

2. For quick response, if you have the required RAM, you could try to create a ramdisk. It will sure work fast:

mkdir /mnt/ram

mount -t ramfs -o size=700M none /mnt/ram

3. Copy the data from the CD to the ramdisk:

cp -R /mnt/temp/* /mnt/ram/

4. Add your autoinst.xml to the new cd root:

cp autoinst.xml /mnt/ram/

5. Edit the required isolinux.cfg parameters. On Suse10 it resides in the new <CD-ROOT>/boot/i386/loader/isolinux.cfg. In our case, CD-ROOT is /mnt/ram

Add the following text to the "linux" append line:

autoyast=default install=cdrom

6. Generate a new ISO:

cd /mnt/ram

mkisofs -o /tmp/new-SLES10.1-CD1.iso -b boot/i386/loader/isolinux.bin -r -T -J -pad -no-emul-boot -boot-load-size 4 -c boot.cat -boot-info-table /mnt/ram

7. When done, burn your new CD, and boot from it.

8. If everything is ok, umount /mnt/ram and /mnt/temp, and you’re done.

Note – It is very important to use Rock Ridge and Jouliet extensions with the new CD, or else files will be in 8.3 format, and will not allow installation of SLES.

Hello Edgy, goodbye Feisty!

Tuesday, July 3rd, 2007

I had a rough experience upgrading Edgy to Feisy.

Hardware listing, for generations to come: Motherboard Abit IB9, including on-board IDE controller IT8211 with firmware 1.3.1.67 and no BIOS upgrade in the near future.

Nvidia 7700 with 256MB RAM on PCIe

Problems:

1. With IDE controller enabled in BIOS system hangs during startup. This is correct for the livecd as well.

2. XGL requires the flag “–use-copy” or it will show only the “white cube of death”. Performance is far from being optimal.

3. I was unable to use Xorg AIGLX, but only the generic NVIDIA interface.

4. With NVIDIA movement is slow and jittery. System is not stable, beryl tends to consume around 100% CPU, and the black-windows problem (which usually has to do with lack of video memory) is quite common.

I have downgraded to Edgy yesterday. Besides a (bug?) weird behavior with my existing software raid (the installer hung while trying to reconfigure the md device with a black box flashing fast in the left lower corner of the screen. I was able to use console but not to continue the install) which required me to backup everything and create the raid from console before the installer got to it, installation went as expected. The interesting thing is that I can say that my hardware works better, and I don’t think it has to do only with the kernel version.

I followed my past post about the post configuration required for Edgy, and it saved me some searches. However, there are several updated which I will show here:

1. Skype has a new version – 1.4 beta, which, for now, seems not to be affected by the “open sound device” hanging. This seems great. I have installed it from the dynamic package, which had dependencies. To satisfy dependencies, I used a tool I can recommend called getlibs. It installed Feisy packages on my system but it was quite OK.

2. Mplayer requires using the multiverse repository. While I thought I have opened it, it appears I was required to state it in addition manually… Added the following line to my /etc/apt/sources.list:
deb http://us.archive.ubuntu.com/ubuntu/ edgy multiverse

3. Beryl packages for Edgy become quire rare nowadays. I had to dig some to find it. I have used the repository:
deb http://ubuntu.beryl-project.org edgy main
following beryl’s guide which was posted by me before, but this repository works one minute, and doesn’t on the next. When it does, though, it has what you need. I’m using the same NVidia driver as before, with XGL alright, and it’s working fast and stable. Can’t complain.

4. I have created a package for Pidgin for Edgy, version 2.0.2. This was the original reason I have upgraded to Feisty… It can be downloaded from here. Notice – this is a crude package, just for my purpose. You can use it, and you can use the “getlibs” util from above to satisfy the binary’s requirements, as I didn’t add them in. pidgin_2.0.2-1_amd64.deb

I’m a happy camper.

My menuscript for a happy Ubuntu 64 bit installation

Monday, March 19th, 2007

I have been extremely busy for the last few weeks and couldn’t find time to update my blog, so apologies are in place. I am sorry, and I will add later this week several tips and tricks about BASH scripting, which might save time and effort for those of you who use if for more complicated tasks.

But alas – This post is about the things need to be done after new installation of Ubuntu Dapper (6.10) x86_64 has just been done, including, of course, links.

First – This is PentiumD 2.8GHz, Duo, on Abit IB9 Mobo (which I wasn’t too impressed with), 2x 320GB Sata2 HDDs, 2GB RAM and NVidia 7100 Dual-Head (I didn’t want ATI due to their limitations with max accelerated resolution, and the limitations it imposed on my Dual-head setup).

Initial installation as follows:

Edgy Server x86_64, created software mirror (raid1) for /boot, 2x 2GB swap spaces (one on each HDD), and LVM2 VG on mirror on the rest of the disk. Created LV for “/” (10GB XFS) and LV for “/home” (30GB Reiserfs).

During installation the Mobo didn’t recognize my IDE CD, and as the quickest remedy I have used USB-to-IDE adapter with additional CDROM which worked just fine.

Post installation I had to fix /etc/fstab to point to the correct (and now working) IDE CDROM.

To install full Ubuntu desktop, I have used “sudo aptitude ubuntu-desktop”. Sound worked out of the box.

Requirements:

– Skype

– Hebrew TTF Fonts

– mplayer

– Beryl (+XGL because of NVidia)

– Flash in Firefox

Skype:

Skype website has allowed me to download the statically compiled Skype package. It didn’t work, of course, since it was 32bit only. I have installed the following additional packages:

ia32-libs ia32-libs-gtk lib32asound2 lib32objc1 linux32 lib32ncurses5 ia32-libs-sdl

Extracted the archived Skype package, moved its contents to /usr/lib/skype and created symlink from /usr/lib/skype/skype to /usr/bin/skype

Hebrew TTF Fonts:

It was a bit more tricky. I had to get these fonts from some Windwos machine. I got them from one of my licensed desktops, and copied them (only .TTF and .ttf) to /usr/share/fonts/truetype/ttf-windows – a directory created for this purpose. I have then created a symlink for every ttf file in this directory to /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType , which gets included in the default xorg.conf. After restarting X, it worked like a charm.

mplayer:

I have installed mplayer using the restricted and multiverse repositories. I was surprised when I was able to play movies out of the box. Maybe my common codecs are just enough… I will look into it later.

XGL:

I have installed the latest NVidia driver for amd64 from NVidia’s site, and configured Dual-Head setup per my already-existing-too-messy xorg.conf file. xorg.conf.nvidia

Followed the Beryl Wiki for Ubuntu, by the letter. Mind you – I was aiming at XGL with Gnome.

I was so delighted when it turned out to work with my Dual-Head at a total resolution of 2560×1024

Flash in Firefox:

That was to trickier one. I managed to find this guide in Ubuntu forums which was more than enough for me. I did not notice on the first attempt, however, that there are two RPM packages required, and thus failed the procedure. When I have noted it, I was able to complete the task flawlessly.

So, now I have a completely working system, per my needs and requirements. I’m very happy, and I hope I gave good pointers to others who want to use their new 64bit system in a normal manner, even when some vendors do not supply 64bit compatible binary software.

Remember the power of the open source – If it is required to work under 64bit environment it wil be ported to one, while commercial software companies tend to fall behind with new, and sometimes not too popular, propriety systems.

Tyan Thunder K8QE and Linux RHEL 4 Update 3

Sunday, August 13th, 2006

This board is a tricky board. 4GB RAM and above behave in a weird manner in Linux. It appears that PCI 32bit mapping doesn’t work correctly under Linux.

To allow Linux to work on this hardware without failure (such as kernel crush during startup), you must follow these three simple guidelines:

1. Spread the memory equally near all CPUs. For example, if you have 4GB RAM for the four CPU version (8 cores, in my case), spread the memory 1GB near each CPU.

2. Make sure you set the type of OS to Linux in the BIOS. PCI mapping won’t work otherwise.

3. Do not put PCI 32bit cards in the PCI-X slots. It will render the onboard network cards unusable.