PDA

View Full Version : CPU1 lazy while CPU2 rips



Cugel
03-14-2008, 12:13 PM
Hi,

I have noticed the following on the latest version of DbPoweramp Reference (R12.4): While one track is ripping and CPU1 is encoding another track to LAME, CPU1 basically grinds to a halt it manages to encode a few percent at most. On the other hand, if CPU2 is doing the encoding (to Lame) it happily encodes at good speed while another track is ripping. What's up with that?

It is a little annoying, because what happens is that the ripping stops periodically because the lazy CPU1 only starts doing its job when CPU2 also is encoding.

In a review at CNet (http://reviews.cnet.com/processors/intel-pentium-d-940/4864-3086_7-31675018.html?messageSiteID=7&cval=2531802&messageID=2531802&ctype=msgId), they have observed something along the same lines:


Funny thing I observed though: when ripping CD's with dBPowerAmp 12 (which uses both CPU cores separately, to rip two songs at the same time), I've noticed a discrepancy between the speed of CPU1 and that of CPU2, with the former being outrun by the latter...
Strange, indeed.

Same problem?

[Edit: Posted to the wrong Forum. Sorry! Can't find a way to move the post over to the right forum]

LtData
03-14-2008, 06:17 PM
Moved to the CD ripper section of the forum :)
Now, what CPU and version of Windows are you using?

Cugel
03-15-2008, 10:25 AM
Now, what CPU and version of Windows are you using?

Windows XP Professional Version 2002 Service Pack 2 on a Fujitsu Siemens Esprimo with "Intel(R) Pentium(R) 4 CPU 3.20GhZ 2.78 GHz, 1,50 GB RAM. PAE (Physical Address Extension)".

LtData
03-15-2008, 11:09 AM
Your "two" CPU cores is just a P4 with Hyperthreading, which uses a virtual core, which would probably explain why one CPU is fast and the other bogs down.

ComeUpon
03-15-2008, 11:12 PM
I'd like to point out that I've noticed the same thing when ripping CDs.

I'm running XP SP2 just like Cugel, but my CPU is an AMD X2 3800+, not a P4.

I always kind of assumed it was normal--it just never really bothered me.

LtData
03-15-2008, 11:47 PM
Then it sems like the problem is not directly related to the fact that the OP is using a hyperthreaded CPU after all. This seems like something Spoon would have to look at.

Spoon
03-16-2008, 03:33 AM
Sometimes the % counter for CPU can stop, but the encoding is still going on in the background, the reason it stops is the CD Ripper ripping thread has a higher priority than the encoding. It is like the encoders which seem to stop at 100% and wait, they are not waiting as encoding has finished, just the display (GUI) has not picked it up.

pls1
03-16-2008, 12:09 PM
If you want to visually monitor your CPU performance, I recommend Process Explorer from Sysinternals (now Purchased by Microsoft). It's a free tool that is similiar to task manager but with better granularity.

http://www.sysinternals.com

Phil

bhoar
03-16-2008, 04:19 PM
I concur with Phil. Much more useful than the task manager of most in-program monitoring.

-brendan

Cugel
03-17-2008, 11:00 AM
Sometimes the % counter for CPU can stop, but the encoding is still going on in the background, the reason it stops is the CD Ripper ripping thread has a higher priority than the encoding. It is like the encoders which seem to stop at 100% and wait, they are not waiting as encoding has finished, just the display (GUI) has not picked it up.

I have noticed GUI lag before but when the GUI lag stops, the percent figure jumps rapidly up to a higher number.

In this case it does not. It just sits there at for example 15% until the other processor finishes ripping and then it gets going at 16%. What's more it is always CPU1 that waits for CPU2. Never the other way around which sort of speaks against GUI lag.

And when CPU1 is ripping CPU2 always encodes away at good speed.

ComeUpon, do you have GUI lag or a lazy CPU?