xp2200 cpu at 100% when converting why?

[vifa84]

Hello,
My system
XP2200
Albatron KT600 Motherboard
1 gig 400mhz ram
2x80gig hd 8mb buffer
fx5600 video card
liquid cooling

My problem is that the cpu runs at 100% whenever I'm trying to convert from say a 2hr movie in avi to dvd compliant mpeg2.

The software i've tried is Tmpgenc, Main concept, canopus procoder an others.

I've read on this forum of people use systems with xp2xxx or p4 2.x processors taking only 15minutes and running at only 50 to 80%

I've tried overclocking from 1800mhz 266 to 2000mhz 400 but still the cpu runs at 100%.

Could it be the chipset drivers? I've read that if the chipset drivers aren't install correctly or just not installed that the cpu have to work harder because it can't access the memory properly. I have downloaded via drivers from viaarena, the 4in1 version and installed them but when it installs, right before it says to reboot a window pops up that says "should not see me"

Is there a way to check and see if the I/O controller drivers are installed properly? I guess these would be Northbridge drivers?

I will go out and buy a xp3200 if it's going to cut my conversions times for a normal movie from 2hrs to 15 minutes but I just want to make sure that it's not a driver problem first.

Any help would be greatly appreciated
vifa

[Gazorgan]

15 minutes? You mis-read. Converting a 2 hour AVI to MPEG2 DVD standard will take at least 2 hours for 2-pass VBR encode. Factors such as filtering and re-sizing radically affect that time. It will generally always take longer than the movie (can't quite do it in real time, except for CBR encodes).

I think 15 minutes is to rip a DVD5 to Harddrive. Or Burn a DVD at 4x, but 100% most definately not convert a DivX to MPEG2.

[TBoneit]

Encoding is always going to run at 100% CPU Usage. Simply put because it is a CPU intensive task.

A faster CPU ony shortens the time required to encode.

Why is it worrying you?

Youcan shorten the time required by:

a. Use a motherboard that supports Dual Channel DDR
b. make sure memory is fast enough to match CPU bus speed.
c. fastest CPU you can afford
d. Pentium 4 with hyperthreading and WinXP and a encoder that uses it will be faster too.

If you overclock, watch CPU temps, thats when it generates the most heat.

Good Luck

[MpegEncoder]

You should be worried if your CPU is NOT running at 100% during encoding. It should be using all the CPU to encode.

[vuphan]

Using Tmpgenc, you can set the encode to use less CPU by setting it running at lower priority. But this will prolong the encoding. I usually have them run at high priority (100%) and let it run overnight. An average about 11hrs if you set it to encode at maximum quality.

My system: Intel 2.8GB HT, 1GB memory.

[MpegEncoder]

Using Tmpgenc, you can set the encode to use less CPU by setting it running at lower priority. But this will prolong the encoding. I usually have them run at high priority (100%) and let it run overnight. An average about 11hrs if you set it to encode at maximum quality.

My system: Intel 2.8GB HT, 1GB memory.

Lowering the priority does NOT mean that it won't use 100% of the CPU time. It simply means that if other HIGHER priority processes need the CPU, the get it.

Priority has to do with WHO gets the CPU time.

[lordsmurf]

Using Tmpgenc, you can set the encode to use less CPU by setting it running at lower priority. But this will prolong the encoding. I usually have them run at high priority (100%) and let it run overnight. An average about 11hrs if you set it to encode at maximum quality.

My system: Intel 2.8GB HT, 1GB memory.

Lowering the priority does NOT mean that it won't use 100% of the CPU time. It simply means that if other HIGHER priority processes need the CPU, the get it.

Priority has to do with WHO gets the CPU time.

True, but not true. The OS oftens keep a little in reserve. Moving it to high will insure it gets it all. Moving it to low lets the OS keep the unused reserve.

[MpegEncoder]

Using Tmpgenc, you can set the encode to use less CPU by setting it running at lower priority. But this will prolong the encoding. I usually have them run at high priority (100%) and let it run overnight. An average about 11hrs if you set it to encode at maximum quality.

My system: Intel 2.8GB HT, 1GB memory.

Lowering the priority does NOT mean that it won't use 100% of the CPU time. It simply means that if other HIGHER priority processes need the CPU, the get it.

Priority has to do with WHO gets the CPU time.

True, but not true. The OS oftens keep a little in reserve. Moving it to high will insure it gets it all. Moving it to low lets the OS keep the unused reserve.

I don't know about the MS internals, but I am a software engineer who understands multitasking systems. Why would the OS want to have "unused" CPU time? That does not make any sense. If the "important" parts of the OS want CPU time, they'll get it. That's what priority is all about. Of course there are issues like latency, etc. But the bottom line is: If you are using a program that is CPU intensive, it should be keeping the CPU very busy (maybe not 100%, maybe only 99%)

[lordsmurf]

You're asking the wrong person for "why" ... I never ask why ... I just report the results ... ask old Billy G. for why his OS sucks when it comes to 100% optimal performance/productivity. I see this on WinME and WinXP especially.

[vifa84]

Ok, I must have misunderstood.

Just out of curiosity.
The 4in1 drivers for VIA chipsets, one is agp, one is IDE and the other is INF. The agp via driver lets the Northbridge control communication betwee the cpu and the video card. The IDE allows the Northbridge control communication between the CPU and the IDE bus (does this include the ram i/o?) is this correct? And i'm not sure what the inf one does.

If I go to IDE controller it shows primary ide, secondary ide and VIA busmaster. Is this correct

Sorry if I got off the forum topic
vifa

[MpegEncoder]

You're asking the wrong person for "why" ... I never ask why ... I just report the results ... ask old Billy G. for why his OS sucks when it comes to 100% optimal performance/productivity. I see this on WinME and WinXP especially.

That right, I forgot we were talking about MS Windows. Who knows what kind of tasking scheme is going on there?

It's all cool

[MpegEncoder]

Ok, I must have misunderstood.

Just out of curiosity.
The 4in1 drivers for VIA chipsets, one is agp, one is IDE and the other is INF. The agp via driver lets the Northbridge control communication betwee the cpu and the video card. The IDE allows the Northbridge control communication between the CPU and the IDE bus (does this include the ram i/o?) is this correct? And i'm not sure what the inf one does.

If I go to IDE controller it shows primary ide, secondary ide and VIA busmaster. Is this correct

Sorry if I got off the forum topic
vifa

You might want to go to www.via.com.tw and look around. The Northbridge handles CPU, memory and AGP.

The IDE is part of the Southbridge.

[eas]

I don't know about the MS internals, but I am a software engineer who understands multitasking systems. Why would the OS want to have "unused" CPU time? That does not make any sense. If the "important" parts of the OS want CPU time, they'll get it. That's what priority is all about. Of course there are issues like latency, etc. But the bottom line is: If you are using a program that is CPU intensive, it should be keeping the CPU very busy (maybe not 100%, maybe only 99%)

There are plenty of normal and even high priority tasks running on an XP system. With TMPG running at normal proirity they are going to get more cycles than they would with it running at high priority, even if they don't do much of of anything with their timeslice but check their event queues.

Besides that, context shifts take time/resources.

I'd assume these two factors account for some of the difference between running TMPGenc on an otherwise idle system at normal vs high priority.

[MpegEncoder]

There are plenty of normal and even high priority tasks running on an XP system. With TMPG running at normal proirity they are going to get more cycles than they would with it running at high priority, even if they don't do much of of anything with their timeslice but check their event queues.

Besides that, context shifts take time/resources.

I'd assume these two factors account for some of the difference between running TMPGenc on an otherwise idle system at normal vs high priority.

Well, as has been said many time in these forums, if you want to get the fastest encode time you should disable as many system services and other programs as you can. That way they won't be taking time away from the encoder. Context switches are a small factor and making the coder a high priority won't change that.

Try this sometime: Open task manager, Encode a file, look in task manager and compare the CPU time used by the coder to actual time that the encode took. See if there are any other processes that have large chunks of CPU time. That will tell you if you have a problem to fix.