Last week we were given a hand me down desktop, a Dell Optiplex GX520 with integrated Intel 82945G/GZ video on the motherboard. When we added the NVidia GeForce4 MX 4000 low profile video card, Windows XP for whatever reason was unable to use both video cards. I proposed Kubuntu 9.04 Linux as an alternative. As it was only myself that I had to convince to make the attempt, I was hard pressed to say no

The Intel 82945G/GZ video card will be the primary card and must be attached to “Screen 0″ in the ServerLayout section.

The NVidia video card has two connectors:

1. A standard VGA port driven by a GeForce4 MX 4000 GPU < - Primary nvidia port
2. A super-video port driven by a Quadro NVS 110M

After the base install of the operating system, XWindows was only able to see the Intel video card. After much tinkering with the /etc/xorg.conf file, I was able to get all three LCD monitors to work with Xinerama. There are a number of gotchas that you might run into:

• If the integrated Intel video card is set to Auto in the BIOS, the card will be completely disabled. You need to disable Auto
• You need to know which Nvidia Device entry drives the VGA connector. It must be initialized prior to the S-Video port.
• Disable NVidia’s TwinView and metamodes option lines in the Screen Section.
• Use sudo lspci to identify the pci bus ids. You will need to put them in the Device Sections.
• The integrated Intel video card must use the vesa video driver as the intel video driver will stacktrace when used with xinerama.

From: Jeff Tallman <tallmanATsybaseZeDOTcom>
To: sybase-l@lists.isug.com
Subject: [sybase-l] – RE: Multicore processors and ASE

As always a lot depends on the application profile.   Something to consider for any multicore processor are factors:

1. The number of FPU units per chip (FPU = Floating Point Unit)
   
2. The number and capacity (in IOPS) of IO processors per chip
3. The type of chip multi-threading

With respect to #1, most DBMS (at least the commercial ones) use statistics for query optimization – so while the actual query processing doesn’t use a lot of FPU instructions (assuming a minimum of float datatypes, etc.).  Each query requires a pretty good smack of the FPU time to do the floating point math on the stats.  The impact of this could be lessened by doing statement caching or fully prepared statements…or other means at reducing the optimizer load.

The second problem is one of capacity vs. bandwidth.   All network and disk IO obviously need to use the IO processor.   With 4 dual core chips, usually, you have 4 IO processors.

With a single chip with 8 cores, it is likely that you will have only a single IO processor.   The single IO processor has 8 cores all making requests.  The number of IO operations per second it can handle becomes a real key factor in the box’s scalability.

The chip multi-threading is an interesting issue as there are ~3 different flavors today:

1. Intel’s Hyperthreading (no longer implemented on XEON and I don’t think implemented at all anymore)
2. Sun’s Chip Multi-Threading (CMT)
3. IBM’s SMT

Some instructions require multiple cycles to complete due to they are waiting on a fetch from main memory or whatever.   The thread/process of execution typically blocks in these cases, resulting in a fairly idle core.   By making use of this idle time, CMT or SMT can increase the throughput overall — ignoring HT as it was fairly ineffective at this – and appears to have been dropped by Intel lately.

The question that comes up is how do you manage the threading?  Do you do a form of timeslicing (i.e. when you suspend on process that is blocked on a call, do you let the one that replaced it run for a certain length of time or until it blocks before returning back to the original) or do you do an interrupt based/preemptive mechanism in which when the blocked call returns, that you suspend the other thread?   Both have advantages and disadvantages, and do allow more engines than cores.

However, it may also mean tuning ASE to be more reactive, such as reducing the ‘runnable process search count’.  You also need to be careful that engines running on CMT’s don’t get woken back up on another core (especially if the L2 cache is split between the cores) as well as other considerations.

A rule of thumb to think about is that if you have a multi-core CPU that supports chip threading, if you have a lengthy list of SPIDs in a ‘runnable’ state, enabling extra engines on the threads will likely help.   If you don’t – i.e. you are IO bound – that it probably won’t help.

Currently, Sun uses a timeslicing mechanism that is more along the lines of ASE’s SPID management – and as a consequence, it shows scalability when the various tasks do a lot of blocking calls such as fetches from main memory.  It does have the detrimental effect of only providing a percentage of cpu time to the ASE engine (i.e. 25% when 4 threads per core).   The more parallelism is used within your application, such as higher numbers of concurrent users in ASE, the more it can be distributed across the engines.

You have to be careful as net engine affinity and short query’s (i.e. DML).  They can have a negative impact, which may be controllable using engine groups.   Overall, a cpu-intensive/cpu bound application can benefit from the Sun CMT implementation.  An IO bound application does not.