Update: AMD and Microsoft have released patches to fix the TSC-drift problem. Read page 2 to find out where to get them.

The latest and newest in CPU technology is dual-core: this means having two CPUs on a single chip. Like real multi-processor (SMP), this greatly enhances processing power, among other benefits.
Unfortunately, there's a downside, called TSC-drift, causing serious trouble with certain applications and games.

• random crashes: random crashes, which get worse the longer the computer is running. An application with logging usually complains about differences in "times".
• sluggish performance: the performance of the application/game becomes very sluggish over time.
• Fast/slow hitches: things go too fast for a brief period, then too slow, then too fast again.

All the above symptoms have usually one thing in common: the longer the system is running, the worse it gets. This is in particular noticeable when benchmarking several times in a row. The first score will be quite "normal" but scores will decrease dramatically with subsequent benchmark sessions.

This little FAQ tries to explain the consequences of TSC-drift and other trouble with dual-core.

What is TSC-drift?

An most important factor with SMP systems is that processing between different CPUs occurs synchronously. If not, things would quickly turn very bad. This synchronisation is done by querying the TSC, present in each CPU (core), and making sure they stay as equal as possible. This synchronisation is a job the OS kernel must do (which is why an old DOS doesn't handle SMP very correctly).
The big problem now is the new venture of power savings and CPU throttling: changing the CPU frequency also reflects on the TSC. CPUs (including dual-core) however can change their frequency independently, which causes severe sync-loss between TSCs. Normally, the OS kernel knows about this and can anticipate on it.
Although the OS kernel usually handles this, an application or game may also handle timesync directly, so it can determine affinity settings on their own. And now you can probably guess what happens when the CPUs change frequency and TSC changes as well. An application that doesn't know about this problem, doesn't anticipate clock changes and things go out of sync very quickly, causing TSC-drift.
A more elaborate article can be found here: http://lkml.org/lkml/2005/11/4/173.

Does every application suffer from TSC-drift?

Not at all. There are many applications and games that run without a problem on dual-core systems. Even single-threaded ones may run perfectly.
There are however applications that directly use the TSC of a CPU, instead of using the appropiate system calls. They usually don't factor in TSC-drifts, and thus, could get confused real easy.

Does this problem exist on real SMP systems?

Theorically, this problem could also occur on real SMP systems, though most of the time, these environments are often with servers, and those applications are usually free from this problem.

Does this problem exist on P4 and Xeon with HyperThreading?

SMT, or HyperThreading CPUs, don't have this problem, simply because SMT CPUs is still a single chip (even though it appears as 2 separate CPUs). Therefore, the TSC-issue is non-existant on such a CPU.
Intel CPU's don't have this issue because they always have their TSC synchronized.

Is there a viable solution to this problem?

Yes, there are. Aside from installing the latest patches and drivers, you can try to set the affinity of a certain process to only a single core. The application will only run on one core, and thus won't suffer from the TSC-drift. Of course, this isn't really solving the problem.
Another, more viable solution is the installation of the necessary drivers and hotfixes. For that, read the next page.