3 Jun
2003
3 Jun
'03
11:26 a.m.
How does the P4 machine compare against itself with hyperthreading turned off?
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.
Taybin
-------Original Message-------
From: Fernando Pablo Lopez-Lezcano <nando(a)ccrma.Stanford.EDU>
Sent: 06/02/03 09:05 PM
To: linux-audio-dev(a)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
3 Jun
3 Jun
3:31 p.m.
New subject: [linux-audio-dev] latency and P4 hyperthreading?
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(a)ccrma.Stanford.EDU>
Sent: 06/02/03 09:05 PM
To: linux-audio-dev(a)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 
7:22 p.m.
New subject: [linux-audio-dev] latency and P4 hyperthreading?
On Tue, Jun 03, 2003 at 10:19:15 -0700, Fernando Pablo Lopez-Lezcano wrote:
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.
I think its a better win if the kernel understands HT, I have a smp ht
machine and big parallel therads sometime get stuck on different threads of
the same cpu, instead of different cpus. If I had no HT in those cases it
would be faster.
- Steve
4 Jun
4 Jun
12:09 a.m.
New subject: [linux-audio-dev] latency and P4 hyperthreading?
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.
I think its a better win if the kernel understands HT, I have a smp ht
machine and big parallel therads sometime get stuck on different threads of
the same cpu, instead of different cpus. If I had no HT in those cases it
would be faster.
Ha! So I was not imagining things. I had some weird problems when trying
to run jack (but I was distracted with the latency issues so I did not
pay much attention - one problem at a time) so most probably that is the
reason.
I guess we'll have to wait till the kernel catches up...
-- Fernando
6:53 a.m.
New subject: [linux-audio-dev] latency and P4 hyperthreading?
On Tue, Jun 03, 2003 at 06:58:03 -0700, Fernando Pablo Lopez-Lezcano wrote:
I thought it did, obviously it does not (completely).
Some do, some dont. I'm not sure where the cutoff comes or if its a patch.
I dont knwo what (linux) thread affinity is like, it could be that if oyu
restart jack it will get its threads stuck to real cpus. If your on a UP
system it doesn't matter ofcourse, its only a problem where you have an
SMP system and all the virtual CPUs are not equal.
- Steve
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.
I think its a better win if the kernel understands HT, I have a smp
ht
machine and big parallel therads sometime get stuck on different threads of
the same cpu, instead of different cpus. If I had no HT in those cases it
would be faster.
Ha! So I was not imagining things. I had some weird problems when trying
to run jack (but I was distracted with the latency issues so I did not
pay much attention - one problem at a time) so most probably that is the
reason.
7936
days inactive
7937
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
Fernando Pablo Lopez-Lezcano -
Steve Harris -
Taybin Rutkin