dual xeon ht, i can capture/encode from my pinnacle card at dv quality AND play cod... sure my frames drop to 70 sometimes but what the heck.

I am using a GeForce4 Ti 128MB 4X AGP. I am using 53.03 Ref. Drivers.

gforce4 ti4200 128 4x
 
ummm drivers are prolly 2 versions ago i think.
i dont notice a big increase from one to another but if they are fubar then it's a big deal so i only change them every couple months

Any application that will use %100 CPU power - HT is useless - why? Becuase HT allows the system to use CPU power not in use - but when you are using %100 cpu power - there is not cpu power left to allocate to anything else.

Quote:I am using a GeForce4 Ti 128MB 4X AGP. I am using 53.03 Ref. Drivers.

go back to 43.* drivers - the 53.* have more optimizations in them .i.e - missing shadows / entire scenese in games etc.

Quote:I have noted that with H/T enabled, IF I run SETI 3.x character mode as a REALTIME CPU priority priveleged application?

I occasionally get "jams"/hangups...

Blah, blah, blah...


Running anything in "Realtime" mode is a poor idea, as all the cpu cycles (effectively) get handed to the application, and thus you get hops and skips when the OS or other apps need attention. If the app cannot field all these resources properly (and most don't, for various reasons) the OS can collapse around it.

HT is more of a cheat at multi-processing. Rather than being a true SMP box, this CPU can spit requests as needed and run the independently(ish). I would imagine that a lot of apps out there cannot fully take advantage of it yet, but expect patches to update them. HT is a great way to go if you can, you just might have to wait to get all the support you want/need.

Don't forget "Captuing DV" is not really capturing at all, jus transferring data. Moving DV data to the pc has NOTHING on actual analog video capture.
 
HT will be of no benefit to DV "capture" as very little CPU is needed. Editing the DV stream however will benefit from it.

I AM capturing analog, NOT DV, YET. I didn't have any problems on my AMD XP 2500+ machine with the same capture card, video card, sound card, memory AND drivers. Just seems that the Intel setup I have isn't happy with capturing video in HT mode...

Quote:Just seems that the Intel setup I have isn't happy with capturing video in HT mode...

...or rather, your software isn't happy with H/T. I would say it's the latter.

Yeah true. What's wierd is that it worked for 2 weeks with no problems, then yesterday it started up. I have not installed ANYTHING new before the problems came on...

Quote:Any application that will use %100 CPU power - HT is useless - why? Becuase HT allows the system to use CPU power not in use - but when you are using %100 cpu power - there is not cpu power left to allocate to anything else.
Not really - 100% cpu usage according to task manager just means that there are processes running on the cpu on every cycle. That doesn't guarantee that the program is making use of all the resources during those cycles.

Processors very often have more ALU's and FPU's than a single program can utilize all of the time. In any given cycle, the program may be using, for example, only one of the ALU's and one of the FPU's. Then there are other functional units on the cpu left unused. So the point of hyperthreading is to let multiple programs run on the cpu in a single cycle. On a P4 it can run two threads at once; theoretically, a hyperthreading-type cpu could be made to handle any number of threads together. This, hopefully, results in more "full" cpu utilization, using all of the functional units, in order to increase the overall system throughput.

Hope that makes sense...

Quote:Hope that makes sense...

Yeah I think it does to me. Basically it means that if the app and/or OS is not optimized for H/T then it's not running as effeciently on this type of CPU. Also you can possibly run into anomylous behavior like this Video Capture app/hardware.

You can kind of use the same analogy with 64-bit CPU's, if the OS is not re-written to take advantage of the extra CPU features then it's not running at full speed so to speak. I guess in a way this maybe like the old P1 MMX days before games and other apps took advantage of the extra features of the CPU

Sort of, jmmijo, yes. Really, any multithreaded app should see a performance improvement when running on a hyperthreaded cpu. Apps that are only compiled for single-threaded use may still see some improvement though, as the operating system is still multithreading. So, any background tasks can run on the same cycles as your main program.
 
Forgive me if I go too far in explaining this - this is the kind of stuff I am researching in grad school, so I really like talking about it. If you (or anyone else) are interested in learning more about this, I would recommend you check out these multithreading slides. That's from a class I just took last semester... you can also check out the course webpage here. Those slides will probably be pretty confusing if you've never studied computer architecture, but let me make some quick highlights for this discussion. Slide 6 shows an example pipeline for a superscalar cpu, like a non-HT P4, and slide 14 shows another pipeline with simultaneous multithreading, which is what Intel calls hyperthreading. The columns represents different cycles during execution, and the rows represent the different functional units. The colors on the second one indicate different programs executing at the same time.
 
If you want to know more just ask - like I said, I love talking about this stuff...

Getting back to the original topic, I would have to suspect your drivers for the capture card. Yes, I know you said it worked fine on your AMD machine, but... From a software point of view, HT is really no different from true multiprocessors. And it is very common for poorly-written drivers to have issues on multiprocessor machines. So, you may want to see if the manufacturer knows of any problems with multiprocessing with their capture cards. You could also look into getting a capture card that is known to work on multiprocessor machines, like the one Jerry Atrik mentioned.

When running in realtime mode with multiple CPUs, I doubt you are tying up all the resources of all of them, therefore you are leaving some available for the OS. Again, running anything in Realtime mode is a poor idea. Run it with a higher priority? Sure, but not Realtime.

Again, I stated that takes "most" of the resources, and not all of them. Duh. You also state that it is dependent on the application, which I stated earlier as well. Is there a *real* need to add all that text to simply reiterate what someone else already stated, or are you too busy typing and clicking "quote" to actually go through it? Nevermind, you will probably post "War and Peace" and I wouldn't care.

I too have thought the "realtime bad never use" situation from what I have read. i however have a true Dual cpu rig. I encode alot of Divx and DVD (mpeg2)
 
Guess Ill set my encoders to realtime and see how much extra speed I get.
 
Currently one encoder I use only eats about 70% of both my cpu's, i wish it would use more. Hopefully realtime will help in this case.
 
The other encoder I use uses both cpu's 100%, but it takes longer (inefficient encoding) and it stays at 100% both chips when set to low priority, although my machine is very responsive even when it's at 100% both. ind of like the way prime95 makes my cpus go to 100%, yet the machine remains totally responsive.
 
Wwhat causes this behavior? (great responsiveness even at 100% use) ?

Quote:The other encoder I use uses both cpu's 100%, but it takes longer (inefficient encoding) and it stays at 100% both chips when set to low priority, although my machine is very responsive even when it's at 100% both. ind of like the way prime95 makes my cpus go to 100%, yet the machine remains totally responsive.

Wwhat causes this behavior? (great responsiveness even at 100% use) ?
I have to disagree with AlecStaar's assertion on this one. Also, this brings up an excellent point AGAINST realtime mode. The reason that your machine runs so nicely even when prime95 is running, is because prime95 does all of its processing at a very LOW priority. In fact, I'll quote their FAQ directly:

Quote:Will the program interfere with my normal work?
Highly unlikely. The program runs at the lowest possible priority. This means it runs only when you are not using your computer for other purposes.
The point of the priority system is to indicate to the OS which tasks are most important. The way prime95 is set up, it like saying to the OS "Go ahead and do all the little things you need to do, and I'll do my work when you aren't busy." Conversely, if it were running in realtime, that is essentially saying "Give me the cpu - when I have a spare moment I will let you (the OS) do your thing." And for a program like prime95, which ALWAYS has stuff for the cpu, running in realtime priority would bring the rest of your system to its knees.

Now, I think this is a separate issue, but I will agree with AlecStaar that the multithreading your apps has a positive effect on the performance of the single application. Well-written programs will often have a gui thread and one or more work threads. The gui thread does the simple stuff, like accepting mouse input from the user and drawing the controls on the screen. The work threads does whatever cpu-intensive work needs to be done. However, if the work threads are placed at too high a priority, then the gui thread will suffer less cpu time than it needs to appear smooth.

CUViper has it, it is a poor idea, PERIOD. If you want to contribute to the instability of the OS, fine. Other applications that work in the same concept, but with available RAM, would be the Exchange server series. In Exchange 2000, it would gobble up all the free RAM it could and "release" RAM to the OS when it "needed" it. However, its definition of need seemed to differ from everyone else's and typically wouldn't release a damn thing (much to the chagrin of Small Business Server admins that had to run IIS and SQL server on the same box as Exchange). Running something in Realtime means you are granting the application the ability to supercede other apps and the OS for scheduling (and attempting to provide time constraints on the scheduling, which NT was never really meant to do). So, if you were to do this on a dual CPU box, you could conceivably tie up both CPUs and crash the OS (assuming the app could balance all CPUs). Now, the only way to guarantee that this wouldn't happen is to set the affinity of the process to one CPU, and let it spin its threads over there at Realtime. But, doesn't this defeat the purpose of using an SMP box with a multithreaded app (insert nod here)? Don't waste your time doing this unless it's for testing. Using High priority is good enough and will give your app a nice boost most of the time while not sucking away life from your system.

At least clutch and I see eye-to-eye...
 
I will grant you, AlecStaar, running a program like prime95 in realtime will not tie up both cpu's of a dual-processor machine, nor will it completely block the OS. Why? Because the work thread of prime95 is a single thread, and a single thread can not run on more than one processor at a time.
 
But, any other app could be doing its work in more than one thread. If you start a multithreaded application in realtime, one that does its cpu-intensive processing in more than one thread, then those threads will consume all of the cpu time, even on a multiprocessor or hyperthreading machine. (Unless, as clutch pointed out, you tie the process affinity to one CPU.) The only time the OS will get to do anything is when the program has a stall in execution, like a disk access or something.
 
Running in realtime, or any higher priority, does not magically create more processing power for you to use. All it does is redefine the processor scheduling for the operating system. Any increases you see in your particular program by running in this manner WILL cause a decrease in performance somewhere else.
 
AlecStaar, you keep saying in your arguments how good your apps are, how efficient and user-friendly etc. etc... I am not arguing your programming skills, nor do I think it is relevant to this conversation. An efficient algorithm is always a better solution than new hardware. The issues of realtime priority, hyperthreading, and multiprocessing are really only relevant to apps that ARE "cpu hogs".