i would argue that they have made the right decision for short and long term performance. the x86 decoder takes up no more than 10% of the entire cpu core. given the way things are going, that 10% will get smaller and smaller.
Most anaylsts, u can search the web i think for anything about AMD, is that there plans are very long term, they wanna keep it steady and ongoing.
ok, i've spoken with several people playing the game who have both athlon and intel machines. it seems that my experience is shared by others, and it is indeed the HT of the intel cpu which allows daoc to run smoothly running 2 clients on the same pc. while those i spoke to all said their a64's were faster doing single tasks, it's obvious when running multiple clients with this game, unfortunately that athlon falls short. i'm sure there are other instances where HT is an advantage, so it seems to be a rather overlooked feature, which is hardly ever discussed (at least in reviews comparing cpus).
there are some workarounds that came be done to make this manageable on an athlon64 (adjusting application priorites), but it simply doesn't work as well as an HT p4 chip (was also pointed to a rather "untechnical" thread discussing it here, and another one here). at any rate, at least i know it's not my system in particular. thanks to eveyone who jumped in with thoughtful opinons on this subject.
there are some workarounds that came be done to make this manageable on an athlon64 (adjusting application priorites), but it simply doesn't work as well as an HT p4 chip (was also pointed to a rather "untechnical" thread discussing it here, and another one here). at any rate, at least i know it's not my system in particular. thanks to eveyone who jumped in with thoughtful opinons on this subject.
- Aug 22, 2001
- 32,073
- 32,600
- 146
Duvie, had a great HT thread that was stickied here for sometime showing some areas where HT can shine. It's a shame so many automatically dismiss it as a marketing gimmick or ineffectual. When the app/proggie is optimized for MP/HT or more than one client can be run, like with DC projects, HT can be a powerful feature.
OK, i finally found an online review that helps explain/support what i'm trying to say here.
running word and web browsing while copying files is not the what i mean by "multitasking". i'm talking about several apps that all try go hog large amounts of cpu resources. finally ran across a reveiw that actually stresses a system with multiple tasks: this one compressing a 330MB AVI file to an 84MB WMV file while FS2004 was running its test.
while the a64 3400+ easily held the lead running FS2004 solo (60-90 fps vs 50-70fps), it also stood out in last place while running FS2004 and encoding the media file; the 3400+ averaged less than 4fps while the 3.2ghz averaged 17fps. that's a huge difference, and shows exactly the point i've been trying to make here. you can see the graph here.
"When WME9 was running, the Athlon 64 averaged less than 4 frames per second. We did see one large spike in frame rate, but the curve pretty much remained under 4 fps for the majority of the run. All three Pentium 4 processors performed more poorly when running Flight Sim 2004 solo, but managed to average around 17 frames per second while WME9 was chugging along in the background. The other interesting data point is that Prescott's average frame rate of 17.2 fps when multitasking was essentially the same as the 3.2GHz P4EE's 17.5 fps. Of course, the frame rate dipped on occasion, but the point here is that Hyper-Threading clearly has a major impact."
i'm not sure why results like these aren't given much consideration in reviews comparing the two architectues; hell, it's almost like it's taboo to talk about these things, but honeslty i'm not play fanboy here; this is a legitimate concern (for some, such as myself more than others who don't normally run multiple cpu intensive apps/games) raised after i purchased an athlon64, and i'm hardly talking out my ass...
running word and web browsing while copying files is not the what i mean by "multitasking". i'm talking about several apps that all try go hog large amounts of cpu resources. finally ran across a reveiw that actually stresses a system with multiple tasks: this one compressing a 330MB AVI file to an 84MB WMV file while FS2004 was running its test.
while the a64 3400+ easily held the lead running FS2004 solo (60-90 fps vs 50-70fps), it also stood out in last place while running FS2004 and encoding the media file; the 3400+ averaged less than 4fps while the 3.2ghz averaged 17fps. that's a huge difference, and shows exactly the point i've been trying to make here. you can see the graph here.
"When WME9 was running, the Athlon 64 averaged less than 4 frames per second. We did see one large spike in frame rate, but the curve pretty much remained under 4 fps for the majority of the run. All three Pentium 4 processors performed more poorly when running Flight Sim 2004 solo, but managed to average around 17 frames per second while WME9 was chugging along in the background. The other interesting data point is that Prescott's average frame rate of 17.2 fps when multitasking was essentially the same as the 3.2GHz P4EE's 17.5 fps. Of course, the frame rate dipped on occasion, but the point here is that Hyper-Threading clearly has a major impact."
i'm not sure why results like these aren't given much consideration in reviews comparing the two architectues; hell, it's almost like it's taboo to talk about these things, but honeslty i'm not play fanboy here; this is a legitimate concern (for some, such as myself more than others who don't normally run multiple cpu intensive apps/games) raised after i purchased an athlon64, and i'm hardly talking out my ass...
Originally posted by: LTC8K6
Yes, Duvie did a number of such tests showing great bennies from HT. Few people were interested, it seemed.
This is why some of us are patiently waiting for the dual cored Intel chips with HT.
well, ht isn't necessary in a dual core chip. i mean, basically ht just pretneds it's 2 cores when it's actually a single core; no need to do that if you're already dual core (unless you want to pretend you're quad core heh).
frankly i'm more interested in the dual core athlon architecture, as the a64 core obviously is much more efficient than the intel core, and i imagine a dual core setup would eliminate the one issue with the athlon i find lacking.
If you're referring to the 'benchmarking' done by Extremetech, it doesn't show what it seem to show. In many ways this is a fake or lying test. IIRC, the testers, originally when they made the first, and *developed* these "benchmarks", confessed that they had to set Windows to give priority to the background task, in order for the test to show what they wanted it to show.
(It also seems Extremetech have now stopped these "tests".)
I've tried to explain this to you several times in this thread, (but if you now detect a certain element of impatience, it might have more to do with your change of title for this thread):
- Like all CPUs, other than Intel's P4HT, Athlon64 only handles one thread. So Windows sheduler only sends it one thread. And if Windows sheduler is then told to give priority to WME9, it results in 4 Fps. What you see is not Athlon64's multitasking properties, but Windows', and a manipulated Windows at that.
And yes, the P4's manage 17 Fps, because Windows sends it a second thread, so 'turning off' FS2004 will not be as successful, as it is in the case of the A64.
This so called "test" only shows something that is already perfectly clear, from the CPU's technical specs: The HT-P4s have two "virtual" cpus, the A64 is just one as usual. - It shows nothing else!
It certainly doesn't show "multitasking properties". Good multitasking properties comes from a large and well working cache, and lots of RAM.
A true multitasking benchmark is for instance 'Veritest Business Winstone Multitasking'. This tests multitasking performance, when Windows is allowed to run threads as Microsoft intended.
Is it reasonable for anyone to use FS2004 at 17 Fps? While giving priority to encoding in the background?Of course not! The proper way to use any preemptive multitasking OS, is to give the foreground or interactive task priority. If you work that way, you will not notice effects from a background task running much, or at all. Similarily, two concurrent workloads running simultaneously at the same priority, will both run at half speed, and so on.
In order to screw this up, priorities need to be screwed up. That happens, so yes, having two CPUs, virtual or real, is sometimes advantageous. I've never denied that. But still, apart from that you can get higher collective performance from the setup, (just like on dual CPUs or dualcore CPUs) it's not a big deal, outside some special situations. (In fact, Intel's HT is primarily motivated by getting more work out of the execution unit. Not improving multitasking.)
And on a well working OS, you would have a very hard time seeing the difference between one or two threads released by the sheduler.
HT will only be advantageous when one undesired thread is hindering a desired thread from running. That can be avoided for normal multitasking uses. Besides, most other OSes don't seem to have the same problems at this, as Windows messagequeue driven program model.
The A64 does not have "poor multitasking", that's an absolute rubbish concept. If you experience "poor multitasking" it's either intentionally contrieved (as in extremetech's FS2004/WME9 benchmark) or an example of Windows' poor multitasking (that can probably be improved by manually tinkering 'basic process priority').
I've used P4s at daily professional work, for what seem to be ages. Lately P4C too. And yes, HT is nice but it still doesn't compare.
I'm totally in love with my A64 3400+. After sogging knee and thigh deep through swamps, for years with laggy Pentium 4s, that were management's favorites, but poorly suited for the technical work, A64 feels like a ride in a Bentley. It performs an incredible 91% (I've done my own application benchmarking) better than a 3.2 P4C. It's an even easier A64 choice, than for Flight Simulator 2004. And even while running computing in the background (at low priority) it's more snappy and comfortable to work with. (I'm not running "cool'n quiet", no point, but I don't think that will have any impact.)
As for your needs or "legitimate concern", why didn't you consider a dual CPU setup? (I/we certainly did.)
What are you complaining about? Did you somehow thought that when you bought the A64, it was a dual core CPU? I should think not. Did you not know, when you bought the A64, that Intel's hyperthreading feature meant that it acted as two virtual CPUs? If really not, what did you then imagine it was?
i see the point you're trying to make; i really do.
the facts still bear tho that in these circumstances the a64 underperforms. is it the fault of the architecture? i dunno.. is it the fault of windows xp? perhaps. i've stated that several times, as well as questioned whether it was reasonable to assume the a64 would perform better under these conditions using a 64-bit OS. regardless of where you want to place the blame (personally i could care less, i just wish i could change it, but at this point it seems i cannot), that a64 system still mulitasks poorly. if you have a solution to this i am more than open to hearing it, but blaming windows or whatever else still doesn't change the result.
while i have no reason in particular to doubt what you state regarding the article, it does describe exaclty the experience i have when comparing these platforms, and i am not "messing with priorities". is FS2004 playable at an avg of 17fps? no, but i'm not using that literally, rather simply as an example. if daoc ran in the background client at 17fps, that would be perfect, but on the athlon it does not. also, as i have stated there are other annoyances this situation causes, tho it could certainly be argued they aren't significant to some people.
the bottom line is that the "realworld" end result is still the same: when trying to run under these conditions using an athlon 64 based system, it simply does not perform up to the standards of a similar intel system. we all know the ht enabled intels pretend to be 2 cores, and that the a64 is only one pretending to be one, but that's part of the point, not an argument against it...
the facts still bear tho that in these circumstances the a64 underperforms. is it the fault of the architecture? i dunno.. is it the fault of windows xp? perhaps. i've stated that several times, as well as questioned whether it was reasonable to assume the a64 would perform better under these conditions using a 64-bit OS. regardless of where you want to place the blame (personally i could care less, i just wish i could change it, but at this point it seems i cannot), that a64 system still mulitasks poorly. if you have a solution to this i am more than open to hearing it, but blaming windows or whatever else still doesn't change the result.
while i have no reason in particular to doubt what you state regarding the article, it does describe exaclty the experience i have when comparing these platforms, and i am not "messing with priorities". is FS2004 playable at an avg of 17fps? no, but i'm not using that literally, rather simply as an example. if daoc ran in the background client at 17fps, that would be perfect, but on the athlon it does not. also, as i have stated there are other annoyances this situation causes, tho it could certainly be argued they aren't significant to some people.
the bottom line is that the "realworld" end result is still the same: when trying to run under these conditions using an athlon 64 based system, it simply does not perform up to the standards of a similar intel system. we all know the ht enabled intels pretend to be 2 cores, and that the a64 is only one pretending to be one, but that's part of the point, not an argument against it...
I think your problems might be due to the client being intended and programmed to run in only one instance on a single machine.
But before we go there, - I've experimented a bit, to replicate your problems. Trying to run two _interactive_ processes hogging full CPU capacity as equals. And what happens is that the process with the active window gets ~75% of CPU time and the other ~25%. I can well think things can be more convoluted than that, by threads receiving changes to their priority through entering some OS service. But is this your problem? That the client with inactive window runs at lower speed?
Well, that is how Microsoft and I think it should be in this case. But I did this: In this computer-properties-advanced-etc-somewhere-I'm-sure-you'll-find-it, I changed priority to background tasks. And behold, both the process with the active window and the "background" window now both runs at 50% CPU time, at all time.
So I tried it with 3 computing processes. And got 33% for each process. Would this be a solution for your problems? They do run less smoothly, more intermittent. And responsiveness is down a bit. However, each thread still only hesitates for a fraction of a second. And it's less noticeble with only two processes.
And it will run more smoothly and maybe more responsive (though I don't think the P4 is particularly responsive ever ) on a P4C with hyperthreading, so we have some agreement.
Please try it and report back.
But before we go there, - I've experimented a bit, to replicate your problems. Trying to run two _interactive_ processes hogging full CPU capacity as equals. And what happens is that the process with the active window gets ~75% of CPU time and the other ~25%. I can well think things can be more convoluted than that, by threads receiving changes to their priority through entering some OS service. But is this your problem? That the client with inactive window runs at lower speed?
Well, that is how Microsoft and I think it should be in this case. But I did this: In this computer-properties-advanced-etc-somewhere-I'm-sure-you'll-find-it, I changed priority to background tasks. And behold, both the process with the active window and the "background" window now both runs at 50% CPU time, at all time.
So I tried it with 3 computing processes. And got 33% for each process. Would this be a solution for your problems? They do run less smoothly, more intermittent. And responsiveness is down a bit. However, each thread still only hesitates for a fraction of a second. And it's less noticeble with only two processes.
And it will run more smoothly and maybe more responsive (though I don't think the P4 is particularly responsive ever
) on a P4C with hyperthreading, so we have some agreement.Please try it and report back.
They added the ability for people to easily use bots (one person playing and paying 2 accounts to be uber).
I don?t want to get into the how and why, I think Vee is doing a much better job of that then I ever could. So I thought I would address the questions asked in the new thread title ?athlon 64: why is it's poor multitasking downplayed/overlooked??
I don?t think HT is being overlooked at all. If anything it is being both downplayed and over hyped at the same time by different people dependant on their own experiences/or lack of it.
I personally have not used a HT enabled P4 enough to see much of a difference, but that doesn?t mean it does not exist. Also because of my computing needs and habits I doubt I would see the benefit that you or some others do. Because of the variety of ways computers are used some people will see HT as one of the greatest innovations to date while others will only see it as hype, its all in your point of view.
What I see in the way of a bottom line is that YOU have now discovered an instance where HT benefits YOUR needs and now you are questioning why others aren?t as impressed as you are.
Personally I see this as human nature, before you ran across this situation I doubt you would describe HT in the same manor that you would now. The fact that you changed the title of this thread is evidence of that.
I don?t think HT is being overlooked at all. If anything it is being both downplayed and over hyped at the same time by different people dependant on their own experiences/or lack of it.
I personally have not used a HT enabled P4 enough to see much of a difference, but that doesn?t mean it does not exist. Also because of my computing needs and habits I doubt I would see the benefit that you or some others do. Because of the variety of ways computers are used some people will see HT as one of the greatest innovations to date while others will only see it as hype, its all in your point of view.
What I see in the way of a bottom line is that YOU have now discovered an instance where HT benefits YOUR needs and now you are questioning why others aren?t as impressed as you are.
Personally I see this as human nature, before you ran across this situation I doubt you would describe HT in the same manor that you would now. The fact that you changed the title of this thread is evidence of that.
Vee is my hero. They took the time to explain what I would have simply hit people over the head until they understood.
in a sense you're correct, tho it's not really a matter of being impressed. i suppose it's more of taking something you've always had for granted, until later when you don't have it.. you realize how important it was (kids, keep this in mind when thinking about your parents!)...
at any rate i find it lacking, and while it's glaringly obvious in a particular instance, it's still there to a lesser degree in many more common tasks...
neither intel nor ht is the "end all be all", but what i did find surprising is that, after all the hype i was taken in by glowing reveiws of the athlon64, it's almost as if there was also this dirtly little secret i didn't find out until after my own experience... and because of that, digging deeper, this is this whole other issue....
it's really funny you would say that.. vee comes across as a thoughtful, well spoken individual.. and nothing he has posted remotely resembles anything you've posted in either content or method of delivery...
Vee
"we have added a new "sleep mode" to the client, to allow it to run while using very low CPU usage when in the background or minimized. Setting it to "Background" will not render when the window is not the active window on your desktop, and setting it to "Minimized" will cause it to not render when the game is minimized. You can adjust your settings in the Options Menu or ingame using the "/clientsleep" command."
at any rate, before dismissing what i've been trying to explain, did you bother the read the links in my previous posts where i found other daoc players discussing this same issue? i'm not alone here by any means.
well, the specific issue with the game is difficult to explain if you're not familiar with it, so forgive me if i do it poorly
imagine 2 instances of say, unreal tournament running on your pc, only the second copy of the client doesn't need to render nor accept input when running in the background; all it has to do is communicate with the server "without lag", so the character on the second client can be set to "stick" to the character on the primary, active client, which does have to accept input, render scenes, etc.
on my intel platform, i can do this without issue, and the char from the second, background client, will be displayed on the primary, foreground client, "stuck" to the primary character and following him everywhere.
on my amd platform, the second char essentially does not keep up with the server, essentially causing a "lag" resulting in 5-10 second delays, and the char becoming "unstuck" and not following.. the primary cleint also has a slight lag, and despite the fact it's not as smooth as on the intel platform, it would certainly be acceptable (and even understandable), if it weren't for the fact the background client is unable to communicate to the server and back to the primary client without a huge delay.
here's something else to consider.. both my 2ghz p4b and my athlon xp 3200+ are able to do this. while not as smoothly as the p4c, it's certainly acceptable, and understandable as they don't "pretend" to be a dual core processor. this is why originally i thought it was something specific to my system, however after researching this, other ppl with athlon64 are having the same issues. this is why i single out the a64; again, it could be a chipset, operating system, or what have you, but it's not specific to my system, yet from speaking with others it IS specific to the athlon64.
the reason i posted the extremetech article is that, while a different game, described the general issue i see on this a64 platform.
unfortunately, the majority of people who play these kinds of games are not exactly pc "enthusiasts" by any means. for exampe, out of 150+ players in our "alliance" chat channel, only a couple of them owned a64s; the rest were predominately intel cpus, with some athlon xps thrown into the mix...
anyway, hope that gives you a better idea of the gaming issue i speak of.
it would be an acceptable "workaround" were it not for the fact that for some reason, when messing with the priorities, it creates an instability in the clients. i will mess around this a bit more and see..
lol.. now come on.. that's a little harsh on the intel part, isn't it
while there are some things the amd part is definately a little better at, it's certainly not a "night and day" difference. in single tasks with games benchmarks, in some games i show as much as 10% advantage for amd, to little or no advantage. it's certainly not enough of a difference to notice without actually measuring via a benchmark.
yes, i will certainly investigate this further.
while that's certainly possible, it harly "uninteded". in fact, new modes have been added to help this functionality:
"we have added a new "sleep mode" to the client, to allow it to run while using very low CPU usage when in the background or minimized. Setting it to "Background" will not render when the window is not the active window on your desktop, and setting it to "Minimized" will cause it to not render when the game is minimized. You can adjust your settings in the Options Menu or ingame using the "/clientsleep" command."
at any rate, before dismissing what i've been trying to explain, did you bother the read the links in my previous posts where i found other daoc players discussing this same issue? i'm not alone here by any means.
well, the specific issue with the game is difficult to explain if you're not familiar with it, so forgive me if i do it poorly
imagine 2 instances of say, unreal tournament running on your pc, only the second copy of the client doesn't need to render nor accept input when running in the background; all it has to do is communicate with the server "without lag", so the character on the second client can be set to "stick" to the character on the primary, active client, which does have to accept input, render scenes, etc.
on my intel platform, i can do this without issue, and the char from the second, background client, will be displayed on the primary, foreground client, "stuck" to the primary character and following him everywhere.
on my amd platform, the second char essentially does not keep up with the server, essentially causing a "lag" resulting in 5-10 second delays, and the char becoming "unstuck" and not following.. the primary cleint also has a slight lag, and despite the fact it's not as smooth as on the intel platform, it would certainly be acceptable (and even understandable), if it weren't for the fact the background client is unable to communicate to the server and back to the primary client without a huge delay.
here's something else to consider.. both my 2ghz p4b and my athlon xp 3200+ are able to do this. while not as smoothly as the p4c, it's certainly acceptable, and understandable as they don't "pretend" to be a dual core processor. this is why originally i thought it was something specific to my system, however after researching this, other ppl with athlon64 are having the same issues. this is why i single out the a64; again, it could be a chipset, operating system, or what have you, but it's not specific to my system, yet from speaking with others it IS specific to the athlon64.
the reason i posted the extremetech article is that, while a different game, described the general issue i see on this a64 platform.
unfortunately, the majority of people who play these kinds of games are not exactly pc "enthusiasts" by any means. for exampe, out of 150+ players in our "alliance" chat channel, only a couple of them owned a64s; the rest were predominately intel cpus, with some athlon xps thrown into the mix...
anyway, hope that gives you a better idea of the gaming issue i speak of.
it would be an acceptable "workaround" were it not for the fact that for some reason, when messing with the priorities, it creates an instability in the clients. i will mess around this a bit more and see..
And it will run more smoothly and maybe more responsive (though I don't think the P4 is particularly responsive ever
lol.. now come on.. that's a little harsh on the intel part, isn't it
while there are some things the amd part is definately a little better at, it's certainly not a "night and day" difference. in single tasks with games benchmarks, in some games i show as much as 10% advantage for amd, to little or no advantage. it's certainly not enough of a difference to notice without actually measuring via a benchmark.
yes, i will certainly investigate this further.
I can vouch for this as well, i play this mmorpg and you cannot "dual box" (run 2 clients on one pc) at playable framerates on most setups that dont have a P4C/E/EE.
Here it starts to be really interesting :light:. You are basically confirming what I've been nagging about all along, that this should work with a single thread CPU as well, - but it doesn't with A64!?!
Sorry, I didn't get this earlier, but your HT comparison hid this for me.
Well, I haven't discovered this about my A64 yet. And if I do, I'll certainly be alarmed. I did have some funny network logon lag... but nevermind. This is really weird. I'm going to stick to my guns on that "poor multitasking properties" is a rubbish concept. It's simply this: The OS does this!
So what is all this about? Sofar I don't know. But the first thing I would do, would be to disable 'cool'n quiet', if you have that.
I simply can't imagine your problem would have anything to do with the hardware CPU, if it is - then it's some previously undiscovered hardware bug, so my next step would be to suspect other OS/software flaws or other hardware issues.
Another thought(just checking): In your taskmanager/processes, all your processes' basic priority should be "normal", except for some OS service. That is right, isn't it?
(I did ask this before, but I never saw an answer.)
(I did ask this before, but I never saw an answer.)
Vee
well, yea, it works - sort of. not nearly as well as the p4c/e, but it's serviceable. while there is certainly lag, if you play "carefully" the char will follow you, but the lag does cause them to "drop" once in awhile, so you have to pay attention. with the a64 you don't have to pay attention as the "lag" is so bad the char won't stick to him to begin with..
heh.. is that anything like my d/l rated dropping from 3mb/s to 900k when i start another cpu intensive task in the foreground and my ftp moves to the background? honeslty, i haven't made sense out of that one yet.
well, again you may have a point to an extent, but ultimately the descripiton is accuarate, as this happens on the a64 platform regardless of whether the OS or chipset is the cause. same OS, same hardware, intel cpu and mb and wala! issue gone.
it is disabled by the bios (actually it's not supported). due to my previous experiences with chipsets for amd platforms, i really wanted to avoig the via 800 chipset. on the socket a platforms, the nforce 2 was by far the best in terms of not only stability, but performance (via had issues with pci, agp ports, especially when overclocking), so i definately wanted a nforce3 250 board. couldn't get a lanparty UT, so i settled for a chaintech vnf250 which had gotten several very good reviews (incl an AT recommendation).
the shipping bios does not support CnQ, nor FIB, and the bios temp monitor is erroneous. i've tried the latest bios which fixes these issues, but for some reason there are stability issues (random reboot) which do not show up on the original bios, so i've stayed with that.
again, originally this was what i thought might be the culprit, but ruled that out as i've talked to ppl with other boards/chipsets who suffer the same issues i do - again singling out the a64.
again, a possbility, however i'm not sure what path to take to identify this, nor am i convined it something other than the cpu as again, others have described this same issue.
correct
well, yea, it works - sort of. not nearly as well as the p4c/e, but it's serviceable. while there is certainly lag, if you play "carefully" the char will follow you, but the lag does cause them to "drop" once in awhile, so you have to pay attention. with the a64 you don't have to pay attention as the "lag" is so bad the char won't stick to him to begin with..
heh.. is that anything like my d/l rated dropping from 3mb/s to 900k when i start another cpu intensive task in the foreground and my ftp moves to the background? honeslty, i haven't made sense out of that one yet.
well, again you may have a point to an extent, but ultimately the descripiton is accuarate, as this happens on the a64 platform regardless of whether the OS or chipset is the cause. same OS, same hardware, intel cpu and mb and wala! issue gone.
it is disabled by the bios (actually it's not supported). due to my previous experiences with chipsets for amd platforms, i really wanted to avoig the via 800 chipset. on the socket a platforms, the nforce 2 was by far the best in terms of not only stability, but performance (via had issues with pci, agp ports, especially when overclocking), so i definately wanted a nforce3 250 board. couldn't get a lanparty UT, so i settled for a chaintech vnf250 which had gotten several very good reviews (incl an AT recommendation).
the shipping bios does not support CnQ, nor FIB, and the bios temp monitor is erroneous. i've tried the latest bios which fixes these issues, but for some reason there are stability issues (random reboot) which do not show up on the original bios, so i've stayed with that.
again, originally this was what i thought might be the culprit, but ruled that out as i've talked to ppl with other boards/chipsets who suffer the same issues i do - again singling out the a64.
again, a possbility, however i'm not sure what path to take to identify this, nor am i convined it something other than the cpu as again, others have described this same issue.
correct
Okay, consider this. Windows XP had to be patched to support HT, correct? What if HT enabled XP installs are handing high-use thread scheduling over to either the processor's thread scheduler, or to a new OS thread scheduler, and in non-HT enabled XP installs it is maintaining the standard OS thread scheduler? In that instance, what we could be seeing here is a difference between the newer thread scheduler and the older one implemented in XP. It makes no sense given equal thread schedulers that it would allocate the CPU time that differently. Unfortunately to test this theory (that with the original thread scheduler, non-HT patched) someone would have to load WinXP with no SP, install said game, and then give it a shot.
Originally posted by: CaiNaM
it's really funny you would say that.. vee comes across as a thoughtful, well spoken individual.. and nothing he has posted remotely resembles anything you've posted in either content or method of delivery...
Believe what you will, but that is damn near verbatim what I have told you and oldfart, and in fact everyone I've been in this debate with in the past six months.
Originally posted by: Lithan
Originally posted by: CaiNaM
it's really funny you would say that.. vee comes across as a thoughtful, well spoken individual.. and nothing he has posted remotely resembles anything you've posted in either content or method of delivery...
Believe what you will, but that is damn near verbatim what I have told you and oldfart, and in fact everyone I've been in this debate with in the past six months.
lol.. dude.. give it up. you're not even close. you never mentioned any of that, your pat answer was, "bs, i run this this and this perfectsly. ht has no benefits. blah blah...", or "you don't even know what a paragraph is, blah blah..."
saying you two think alike is nothing but an insult to him.
actually winxp does not need to be patched. it simply thinks the single chip is dual core, and treats it as an smp (the explanation is oversimpliefied, but should be accurate enough for this discussion). i suppose it's possible that during install it adds smp support, but there's no seperate "patch" or service pack required.
that doesn't necessarily mean your theory is wrong however, as it could quite possibly be something in the way xp handles the thread priorities. not sure how that can be checked tho...
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 23K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter