[linux-audio-dev] latency and P4 hyperthreading?

Fernando Pablo Lopez-Lezcano nando at ccrma.Stanford.EDU
Tue Jun 3 13:32:00 UTC 2003

> How does the P4 machine compare against itself with hyperthreading turned
> off?

The latency is fine (when booting into a up kernel). I did not run
generic benchmarks for testing speed. There is a gain but it is not that
much (from benchmarks I've seen on the web). 

> I'm not surprised that hyperthreading is slower than a true dual CPU setup.
> Two CPUs sharing their cache?  That's got to increase cache misses.

The problem is not speed but latency glitches. It certainly should be
slower than a "real" dual cpu system but it could be slightly faster
than the same uniprocessor machine with ht turned off. Of course if you
have latency problems it is not very useful. 

-- Fernando

> -------Original Message-------
> From: Fernando Pablo Lopez-Lezcano <nando at ccrma.Stanford.EDU>
> Sent: 06/02/03 09:05 PM
> To: linux-audio-dev at music.columbia.edu
> Subject: [linux-audio-dev] latency and P4 hyperthreading?
> > Hi all, has anyone tested latency on a P4 machine with Hyperthreading
> support? (HT simulates two processors on one processor using - I guess -
> the spare time available in the cpu when it is waiting for, for example,
> memory accesses). 
> Anyway, on a:
> P4 2.4G 800MHz fsb, 875P chipset, 1G ram, Seagate Barracuda V 60G drive:
> Booting into an smp kernel with HT enabled in the bios (kernel based on
> 2.4.21-rc6 with the usual low latency, preemptive and full acpi kernel
> patches) I see both processors, but the latency in the disk tests (using
> latencytest 0.42) has spikes that go up to 10/15 msecs, specially in the
> read/write test. 
> If I boot into a up kernel, or if I boot with acpi=off I see only one
> processor and the latency for the disk tests is fine. 
> Same kernel, same alsa on a dual Athlon MP 1800+ machine does not show
> any abnormal latency behavior so this seems to be confined to HT
> machines... :-(
> I guess "made up" processors are not as good as real ones :-)
> -- Fernando

More information about the Linux-audio-dev mailing list