T400: DPC Latency Spikes

[Colonel O'Neill]

I've seen a few, but not many, articles discussing the DPC latency issue and Intel wireless cards.

It seems that every few seconds or so, the DPC latency will spike, and interrupt audio playback in the form of either a skip or a momentary glitch. Many of the past threads (a significant part in the Dell forums) point to the Intel wireless drivers as the culprit. However, upgrading drivers from either Lenovo or Intel doesn't seem to fix this issue. It is particularly bad when I use RMClock to lock the processor to SuperLFM or a lower speed step. However, that is not to say that the problem is completely resolved when left at the highest clock; it is simply less affected.

Has anyone encountered this on their T400 or am I alone in this?

[Harryc]

Since you're talking about Intel wireless drivers and audio, I have to assume you are playing streaming audio over the Internet. I do this all day on my T400 and it is flawless. It has the 5100 card.

[Colonel O'Neill]

Unfortunately, no. I'm playing local files through Winamp (and it is player-independent).

I have the 5300, and DPClat shows a red spike every ten seconds. Locking in the processor at max reduces this spike to the yellow zone, but just barely.

[Harryc]

I'll try a few .mp3's tomorrow. Is this the tool you're using?
http://www.thesycon.de/deu/latency_check.shtml

[Colonel O'Neill]

Yep, that's the tool.

The issue's been there for quite a while, but it's either something about my hearing or Windows that has changed that makes this phenomenon more noticeable than it was before.

Undoing my undervolting through RMClock doesn't do anything; I still have to lock it in at 9x.

EDIT: The issue is much less noticeable with MP3s than it is with FLAC. Especially when the MP3s are 320kbps and the FLACs are ~4000kbps Surround.

It might have to do with the CPU not being able to keep up with the decoding at lowest clock, although the DPC spikes are still a bit of a nuisance; it's rather annoying to have to run the CPU at highest clock just to avoid skips every 10 seconds.

[Harryc]

Where do I get a FLAC file to test?

[Colonel O'Neill]

There's one here:

http://www.linnrecords.com/linn-downloa ... files.aspx
"FLAC Studio Master Surround 5.1 excerpt test (21.5 MB)"
It's only thirty seconds long, though, clocking in at 5383kbps.

This is the output of DPClat at SuperLFM (~800MHz) clock:
http://img132.imageshack.us/img132/2527/superlfm.png

This is the output of DPClat at 9.0x (~2.53GHz) clock:
http://img30.imageshack.us/img30/8171/80518722.png

Rather large difference, although I'd think a C2D running at 800MHz can still decode that high of a bitrate.

[Harryc]

Ok, no skipping on that file on my T400 running at 1600Mhz . CPU utilization never goes above 15%. Do I need to run RMClock to help you out? Also, for my own curiosity, help me understand why you'd want to lock your CPU's Freq. to a low value when it is a disadvantage over speedstep? If you had speedstep working while this FLAC file played it would run your CPU at full speed for you.

[Colonel O'Neill]

Usually I let RMClock do it's automatic stepping thing. But because the processor evidently CAN handle decoding such files on lower clocks, RMClock steps it down when I'm playing it, and when conditions are right, it'll be on a lower clock mode when the spike occurs.

I think what I'm going to do is to prevent RMClock from stepping the speed down that much.

Considering SuperLFM, 6.0x, and 7.0x, all run at the same voltage after undervolting, I'll make 7.0x the minimum allowable clock to prevent the processor from dropping to such a low state.

I guess it's not a true solution, but I hope it won't chew through battery too much quicker.