https://bugzilla.novell.com/show_bug.cgi?id=579932
https://bugzilla.novell.com/show_bug.cgi?id=579932#c148
--- Comment #148 from Borislav Petkov
Well, that's kind of a trick question. A PREEMPT kernel can handle that depending on hardware/firmware and how tight your jitter tolerance is. My old Q6600 box running a PREEMPT/250 Hz kernel can easily meet a 1KHz periodic demand even under hefty load iff I don't expect too much worst case wise.
Hehe, I think this is exactly the problem: reportedly, current kernel leads to "degraded music playback and gaming quality". And yep, it must very well be hardware/firmware-dependent because audio runs just fine on my box here, even under heavy load (I don't play games :-)).
On an isolated core as below, I can expect a whole lot more..
Hmm, I was wondering whether NO_HZ_FULL would help even on an SMI-plagued hw? That would be an interesting thing to try.
marge:~ # cgexec -g cpuset:rtcpus jitter -c 3 -p 99 -t 30 -f 1000 -d 10 -t 25 CPU3 priority: 99 timer freq: 1000 Hz (1000000 ns) tolerance: 25 usecs, stats interval: 10 secs
jitter: 3.82 min: 2.81 max: 6.63 mean: 3.00 stddev: 0.13 jitter: 4.47 min: 2.82 max: 7.29 mean: 3.00 stddev: 0.13 jitter: 2.96 min: 2.81 max: 5.77 mean: 3.00 stddev: 0.12 jitter: 5.06 min: 2.81 max: 7.87 mean: 3.00 stddev: 0.14 jitter: 3.13 min: 2.82 max: 5.95 mean: 3.00 stddev: 0.13 jitter: 28.05 min: 2.84 max: 30.88 mean: 13.91 stddev: 5.28 27 > 25 us hits min: 26.12 max: 30.88 mean: 27.49 stddev: 1.22
jitter: 32.72 min: 3.78 max: 36.51 mean: 16.40 stddev: 0.96 25 > 25 us hits min: 26.56 max: 36.51 mean: 27.55 stddev: 1.97
jitter: 32.61 min: 3.84 max: 36.45 mean: 16.41 stddev: 1.02 31 > 25 us hits min: 26.12 max: 36.45 mean: 27.54 stddev: 2.34
jitter: 22.54 min: 5.12 max: 27.66 mean: 16.41 stddev: 0.71 18 > 25 us hits min: 26.42 max: 27.66 mean: 26.89 stddev: 0.31
..but above, you can plainly see where I killed the cpuhog that was keeping CPU3 away from cstates. The firmware on this box is ok (no SMI),
How am I to read this? As in "jitter grows when the core is allowed to go in deeper C-states?"
but the core2 CPU itself isn't particularly wonderful.
Why? I don't think the CPU itself has any fault in this - it is the glue around it which makes it misbehave, like C-states and such. If you keep it powered on throughout with idle=poll, for example, C-states influence should be gone. I even heard RT-folk do that in certain cases. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.