CUViper

I have a request for the new forum - can we get a time-zone setting to adjust the post times to my own local time? Thanks!

The apple connector is referred to as ADC... that should help you in your search for converters. Last time I looked though, the converters were really expensive - it would probably be better to pay a little premium to get a really nice PC LCD display with native DVI.

Yep - get your network admin to give you administrative rights on your computer. If they won't do that, then you're out of luck. Think about it - if there was some easy way to bypass this, then NO ONE would be using Windows for secure environments.

I had this problem - I talked to Microsoft support, and they sent me a new mouse, free of charge! The Intellimouse Explorer has a lifetime warranty, so take advantage of it!

Quote: Thanks "Copper Viper" (That is what your 'CU' is for in your nick/handle here, right?)! Actually, I chose the CU because I attend the University of Colorado. Copper would be Cu, though it's just a matter of capitalization. Quote: P.S.=> If you set Windows XP to the old-style Domain type (can this be done, rather than ActiveDirectory forests/trees) will it work then? I am assuming, of course, that XP HOME does & CAN bind into one of those no problem... the AD type! Thanks for answers... apk Nope, actually, XP Home cannot join a domain ever. To join any kind of domain it has to be XP Pro. Quote: Um thats definetly a lie, I've got Win2000 server working with Windows XP and that is on a domain, and i got win2000 pro on another computer though That's fine if it's XP Pro... What I said is that XP Home can't join a domain. Quote: I had always thought that as well. It suprised me that in a recent XP Pro installation the workgroup was defaulted to "WORKGROUP." I'm not sure why this was the case. Weird, I wonder if the service pack or something changed it. Well, I guess you just need to double-check when doing a new install, rather than relying on the defaults.

I'll let someone who knows more tell you about the various versions, but I want to quickly clarify the domain thing. Being a domain controller means that it can be the central authority of a Windows domain. Nowadays, Windows domains are typically associated with an internet domain as well, but the reverse is not necessary. You can host as many internet domains and subdomains as you want without ever dealing with domain controllers, active directory, etc.

Quote: It's possible... if you are an Electrical Engineer, this is quite the possible! To answer this (implied) question, since I don't think I've ever said - I received my BS in Electrical & Computer Engineering last spring, and I am currently working towards my MS in Electrical Engineering, with an emphasis on Computer Architecture. So yes, we have very different backgrounds, but I hope we can continue "teaching" each other...

Have you tried any of the community modules for NWN? NWVault has a lot of great modules. One of my favorites is the Shadowlords/Dreamcatcher campaign by Adam Miller: http://nwvault.ign.com/Files/modules/data/Adam%20Miller2.shtml A great one for paladins is Rick Burton's Twilight/Midnight/Dawn trilogy: http://nwvault.ign.com/Files/modules/data/Rick%20Burton2.shtml Well, Dawn isn't out yet, but I'm greatly looking forward to it...

Quote: For the record, I am currently encoding a 352,480 mpeg2 file with an smp capable program. Both CPU's at 70% and realtime. I suspect in this case that your processors are too fast! :x Meaning really that you are probably processing faster the hard drive can supply data. An app running in realtime, or even in normal priority, should fill up the cpu if it has work to do. So if the cpu's are not being kept 100% busy, then it means they are waiting for work, which could mean they are stalled on reads/writes from the hard drive. It could be something else holding back the performance too, but that is the most obvious suspect. I would be curious to know what your encoding times are, in realtime vs. normal priorities. I suspect that realtime is not helping you, by why hypothesize when we can experiment?

Quote: Quote: At least clutch and I see eye-to-eye... I have to be blunt about this, here goes: For two guys with only one eye each worth of know-how in this field, I can see that, you in academia, Clutch as user/network admin. & novice coder! Without 2 eyes so to speak, or experience on THIS end of it hands on coding this kind of ap? It's like only having 1 eye... no depth perception, not able to see the depths of the big picture. This was meant as a simple jest - I did not mean to indicate who knows more than who, etc. I would be willing to wager that with my "one eye" worth of know-how, I know more about the underlying hardware than you, AlecStaar. And I don't think there's any question that you know more about Win32 programming than I do. I think this is really a matter of perspective - You are looking at the cpu from above, with software / programming experience, and I am looking at it from below, from a hardware design perspective. The "big picture" depends on what you are interested in. Quote: AGAIN: Only the main body thread gets "REALTIME".... second or more threads if scheduled by the OS only (not the app itself telling them what priority to run at) will run @ normal priority on another CPU, unless the app itself tells them to run @ HIGH or REALTIME for example. The OS scheduler will take care of that... second threads run @ NORMAL PRIORITY (unless they are told not to) on the subsequent processors. This I was not aware of - it seems counter-intuitive to me, but this point I will yield to you due to my own inexperience. In this case, it wouldn't seem very useful to run most programs at higher priorities, because I think the general practice on multithreaded apps is to do the cpu-intensive work in a child thread. But that's a matter of programming practice, which may be different elsewhere. Quote: Quote: Running in realtime, or any higher priority, does not magically create more processing power for you to use. I never stated it did... Quote: 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. Yes, I know that... do you REALLY think I don't? These statements were not really directed at you. A lot of people with less experience seem to get the idea that running at higher priorities will tap into some magical well of unused processing power. I just wanted to "debunk the myth". So I am glad we agree... This thread is starting to degrade into a lot of defensive statements, on both sides, so I think maybe we all need to just step back and take a deep breath...

Cool - though it is loading extremely slow for me. Do you know if there are any mirrors for this site?

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".

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.

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.

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...