athlon 64: why is it's poor multitasking ignored/downplayed?

[CaiNaM]

my God! i must say i'm simply.. amazed. this has to be a record, you should be proud. i've never, EVER in my life seen so many words written to say.. well, nothing.

this remind me of the aflac (insurance company) commercial which features baseball legend yogi berra talking to his barber and another customer about the importance of having insurance.

"What insurance is that Yogi?" asks the guy (enter the aflac duck doing his best to get noticed). the yogi-isms flow as yogi talks about the insurance and explains its benefits:

"The one ya' really need to have if you don't have it. That's why you need it."
"Well, if you get hurt and miss work, it won't hurt to miss work."
"And they give ya' cash, which is just as good as money."

at which point the duck exits the shop, shaking his head profusely as hey does a "bbbbllllllluuuuhhhhh".

after reading your post, i find myself feeling just like the duck...

your friend with 2 ht pc's is delusional as well it seems, lol...

 

[glugglug]

What you are seeing is that since DAoC likes to give itself high priority internally and not give up the CPU much, each instance is getting BIG timeslices, and the other instance is paused waiting for the CPU back. (With hyperthreading, they both have the CPU simultaneously, so there is no switching back and forth). If you set both DAoC processes to low priority in the task manager, Windows will switch between the 2 processes more frequently and the game will be smoother.

It's been a year and a half since I was playing DAoC, so maybe it's changed since then, but I used to play 2 characters at once on a 1GHz Athlon (a tailor and an armorcrafter trading items between them to make stuff), and if I wanted it to run smooth, both instances had to be low priority. "Normal" priority for this and many other games is "hog the CPU so all other processes get starved". It grabs the CPU for like a second at a time on normal priority, which makes the network communication lag on the other instance and makes things choppy in general. I wrote a real-time log parser for it as well, and that process (which used barely any CPU) would get starved as well if there was an instance of the game running above low priority. I ended up making a service which reads the log file into a buffer and listens on a TCP port, and running that real-time priority so it would wake up with the game hogging CPU, and reading the data over the network to my old K6 and doing the parsing on that, which works out better because I could have the log parser going and giving stats while the game is in full-screen mode.

 

[Viditor]

gluglug - Great feedback!

Cainam, please let us know how this works for you...!
Somehow gluglug's solution "feels" right, but I have far too little experience to really have an opinion.

 

[CaiNaM]

glugglug:

yes, what you state makes some sense, and as a matter of fact it was one of the solutions another daoc player suggested on vnboards. this wouldn't explain why i don't need to do this for the athlonxp or the p4b, but still worth a try.

unfortunately, it's not doing it for me.

setting game.dll for low priority on both clients essentially made both clients non-functional due to excessive "lag", as a matter of fact, the background client went link dead. at normal priority the forefront game was a bit laggy, and the background game too laggy to stick. at "lower than normal", it acted much the same as normal.

switching between these a few time trying different combinations, and one of the clients became unstable and unresponsive.

i'll try this again when the DF LanParty arrives, just to make sure it isn't somehow related to the current mainboard.

Viditor:

yea, unfortunately it's not working out atm.. but who knows.. perhaps with the other mb.... if nothing else that will eliminate one thing from consideration.

 

[Acanthus]

Changing the thread priority in daoc causes instability.

 

[clarkey01]

AVI encoding, IRC, BT, KLite and websurfing was fine with my AXP2000+, yes there was some lag, but certainly not unbearable.



its not just that tho is it - its all about how you use a computer. a lot of old school users are into the habit of running one big program at a time, and concentrating on that - thats what i do... i dont expect computers to be able to encode compress etc all at once, if im doing one thing like that i might be surfing the net but thats it..

i think i didnt notice HT because of the way i use computers. hence, i didnt notice it not being there either.

maybe its good for productivity for some people. but all im ever going to do when stuff like that is running is surf the net - luckily i dont have to achieve hundreds of different tasks an hour with my job (webpage dev, scripting, photoshop, email, word, winzip etc). and when its all done i play games on it, not during, as it distracts me and flicking between tasks doesnt suit my approach.

so yea, its a good feature but unless you notice a lot, who cares? if i wanted it id have it.

its just a method of reducing the amount of pipeline flushes as far as im concerned, improving multitasking doesnt help me, and the increase in performance doesnt affect the apps i run. so im not underrating it, but its useless for *me* with my habits and apps. - That applys to me.


HT is Intels only saving grace @ the moment.

 

[clarkey01]

Personally, I don't think any of the patens on SMT/HyperThreading are worth spitmmaybe i am a bit harsh, but for ME there not worth it.

All it does is optimize use of a resource..

This was done back in the old days of PDP11/45 and later. The FPU had a separate set of registers... To optimize performance all that was necessary was to multiplex floating/integer operations such that
the address calculations (done by the integer part) were completed simultaneously as the floating operation was completed.

Sure, this was done manually (or by the compiler), but the result is identical.

A more optimum use of the processors hardware.

This was also explored in the MIT data flow system designs.



On AMD & Hyperthreading....

Hammer does have such a scheme to avoid branch prediction stalls. After a prediction error, it carries either of the branches and then finds the correct result.

Due to the complexitity of the Penitum 4 die, I just imagine Intel will use to fetch a Hyperthreaded pipeline with branches, for pre-calculations. Talking specifically of the Hammer, instead of using something like Hyperthreading seems that it maximizes speed for branch calculations (the Hammer, like the Athlon, was fully-featured with massive execution resources).

Talking of branch prediction errors the average prediction hit for the P4 is claimed as being a value in-between 95% and 100%, thus the 3% misses I assume.

In reality, there are some cases that or neutralize the branch prediction accuracy every time, or just diminishes its returns time-to-time. A cpu like the Pentium 4 suffers heavily from a neutered hit accuracy, and thus certain types of programs might run at an absolute slugmode when compared to more conservative cpus (Athlon, Pentium 3, G4, SPARC etc.), yield very poor results on the Pentium 4, which have been laid by such heavy penalties.

Looks like Intel has convinced some review sites (such as THG and Anandtech) to do not showcase or explain cases of extremely low Pentium 4 performance, so it's hard to find these sets of situations. Whomever owns both a P4 and an Athlon/P3 should benchmark both the systems running usual applications, so my statement will become easier to figure out

So what is unique about Intel or potential AMD implementations that make them an "new or extention to the art" that qualifies for a patent (other than the PTOs traditional incompetence).

 

[Vee]

Originally posted by: CaiNaM
glugglug:

yes, what you state makes some sense, and as a matter of fact it was one of the solutions another daoc player suggested on vnboards. this wouldn't explain why i don't need to do this for the athlonxp or the p4b, but still worth a try.

unfortunately, it's not doing it for me.

setting game.dll for low priority on both clients essentially made both clients non-functional due to excessive "lag", as a matter of fact, the background client went link dead. at normal priority the forefront game was a bit laggy, and the background game too laggy to stick. at "lower than normal", it acted much the same as normal.

switching between these a few time trying different combinations, and one of the clients became unstable and unresponsive.

i'll try this again when the DF LanParty arrives, just to make sure it isn't somehow related to the current mainboard.

Viditor:

yea, unfortunately it's not working out atm.. but who knows.. perhaps with the other mb.... if nothing else that will eliminate one thing from consideration.

Ok, I've done some experiments with multiple instances of an old heavy computing app, that allows you to see the progress in realtime.
I also think Glugglug has hit the nail and come up with the source for the problem. It's quite visable how long quanta WindowsXP are providing. Windows98 is something completely different. So we now have a possible explanation for why it worked with Axp and P4B, but not A64. If you (CaiNam) were running W98 in that case? (I ran it on a HT-disabled P4 too. No contest, so I don't think anything is wrong with A64 performance under multitasking, but the timeslices seem as long for the P4 too, even if not much is done in them.)

There doesn't seem to be any other way to get shorter quanta, than to lower base pri. Unless Kylef, (who maybe knows something about Windows sheduler) can help us here?

A perhaps good idea, I've mentioned before, is also to make all tasks of the same base priority recieve equal length quanta. That's the radio button ("background tasks"). That will stop your background task from dying. You should get fairly smooth 50/50 then, if only your clients can run at low.

But as far as I know sofar, that's it. And the culprit seem to be WindowsXP's sheduler, not Athlon64. The disturbing thing is that, sofar, there is no solution in sight, other than hyperthreading and P4C/E.

 

[glugglug]

From This article on sysinternals I think setting HKLM\SYSTEM\CurrentControlSet\Control\PriorityControl\Win32PrioritySeparation to 0x24 (36 decimal) might help.

You probably need to reboot for the change to take effect.

 

[kylef]

Originally posted by: glugglug
What you are seeing is that since DAoC likes to give itself high priority internally and not give up the CPU much, each instance is getting BIG timeslices, and the other instance is paused waiting for the CPU back.

This is not correct. Timeslice lengths ("quanta") are independent of thread (or process) priority. The only factors which influence quantum size are:
[*] the foreground app gets its threads' quanta "stretched" by a factor of 1, 2, or 3 (depending on HKLM\System\CurrentControlSet\Control\PriorityControl\Win32PrioritySeparation, 0=1x, 1=2x, 2=3x)
[*] the default quantum size for ALL threads can be set to "short" (default on workstations) or "long" (default on servers) in Control Panel -> System -> Performance Options

Two threads running at identical priority will receive identical shares of the CPU.

If you set both DAoC processes to low priority in the task manager, Windows will switch between the 2 processes more frequently and the game will be smoother.

Interesting. Well, even if the game is spawning compute-bound threads internally that are in class "above-normal" (pri 9), "highest" (pri 10), or "time-critical" (pri 15), Windows still switches between threads at the same priority fairly.

However, you COULD imagine a starvation-type scenario where one of the normal-priority threads blocks on a higher-priority thread. This would effectively starve the other game's process from running until the compute-bound thread was complete. In other words, the two threads are indeed running at the same priority, but only ONE of them is ever put in the "run state" very often. Basically, this means that whichever game is running first should be the one that starves the other one from running. Is that the observed behavior?

If this is the case, then from the scheduler's point of view, this is correct behavior. It really reflects poor programming choices by the game developer. Thread starvation is ABSOLUTELY something controlled by the programmer. Every OS scheduler will schedule whatever it is told to do. If a programmer tells it to schedule a compute-bound thread at higher than normal priority, the consequences are pretty well understood.

It's been a year and a half since I was playing DAoC, so maybe it's changed since then, but I used to play 2 characters at once on a 1GHz Athlon (a tailor and an armorcrafter trading items between them to make stuff), and if I wanted it to run smooth, both instances had to be low priority.

So you're saying that this behavior was the same on pre-A64 cpus? Because that would certainly seem to contradict what others have been insinuating earlier in this thread...

Can anyone else confirm that this behavior is reproducible on pre-A64 Athlons too?

 

[Vee]

Originally posted by: kylef
Timeslice lengths ("quanta") are independent of thread (or process) priority. The only factors which influence quantum size are:
[*] the foreground app gets its threads' quanta "stretched" by a factor of 1, 2, or 3 (depending on HKLM\System\CurrentControlSet\Control\PriorityControl\Win32PrioritySeparation, 0=1x, 1=2x, 2=3x)

Hum, .

[*] the default quantum size for ALL threads can be set to "short" (default on workstations) or "long" (default on servers) in Control Panel -> System -> Performance Options

(Why does this seem like NT to me?)
No, not on my XPpro it doesn't. What I can do is turn off/on that foreground quanta stretch.

Two threads running at identical priority will receive identical shares of the CPU.

Only if I switch the radiobutton from "application" to "backgound tasks". Otherwise the foreground/active window app will get that 'stretch'.

If you set both DAoC processes to low priority in the task manager, Windows will switch between the 2 processes more frequently and the game will be smoother.

Interesting. Well, even if the game is spawning compute-bound threads internally that are in class "above-normal" (pri 9), "highest" (pri 10), or "time-critical" (pri 15), Windows still switches between threads at the same priority fairly.

However, you COULD imagine a starvation-type scenario where one of the normal-priority threads blocks on a higher-priority thread. This would effectively starve the other game's process from running until the compute-bound thread was complete. In other words, the two threads are indeed running at the same priority, but only ONE of them is ever put in the "run state" very often. Basically, this means that whichever game is running first should be the one that starves the other one from running. Is that the observed behavior?

If this is the case, then from the scheduler's point of view, this is correct behavior. It really reflects poor programming choices by the game developer. Thread starvation is ABSOLUTELY something controlled by the programmer. Every OS scheduler will schedule whatever it is told to do. If a programmer tells it to schedule a compute-bound thread at higher than normal priority, the consequences are pretty well understood.

I agree, but I don't think this is the case.

It's been a year and a half since I was playing DAoC, so maybe it's changed since then, but I used to play 2 characters at once on a 1GHz Athlon (a tailor and an armorcrafter trading items between them to make stuff), and if I wanted it to run smooth, both instances had to be low priority.

So you're saying that this behavior was the same on pre-A64 cpus? Because that would certainly seem to contradict what others have been insinuating earlier in this thread...

Can anyone else confirm that this behavior is reproducible on pre-A64 Athlons too?

Yes, A-64, A-XP and on P4s too. I've tried this yesterday on all. Never mind what people have been insinuating, could have been a different Windows version. (I tried it on Windows98 too, which uses much shorter quanta, and thus seems to run smoother.)

It's the same. And/but it was observed on other CPU hog apps than this game client. Setting Base priority in taskmanager to "low" will result in shorter quanta, and both/all three/four etc. processes will run seemingly smoother since they run in shorter and more frequent quanta. Exactly as Glugglug suggests. Remember this is WindowsXP. Behavior is different on Win98 and may be different on NT too. I didn't check NT. I have access to NT a few days more, before we replace it, so I could test, I suppose.

 

[CaiNaM]

Originally posted by: VeeYes, A-64, A-XP and on P4s too. I've tried this yesterday on all. Never mind what people have been insinuating, could have been a different Windows version. (I tried it on Windows98 too, which uses much shorter quanta, and thus seems to run smoother.)

It's the same. And/but it was observed on other CPU hog apps than this game client. Setting Base priority in taskmanager to "low" will result in shorter quanta, and both/all three/four etc. processes will run seemingly smoother since they run in shorter and more frequent quanta. Exactly as Glugglug suggests. Remember this is WindowsXP. Behavior is different on Win98 and may be different on NT too. I didn't check NT. I have access to NT a few days more, before we replace it, so I could test, I suppose.

strange.. both a barton 2600 (oc'd to 3200+) and p4b 2ghz will run both clients as long as they have >768 k memory (each client takes about 300-350k) do not exhibit this. doesn't run near as smoothly as the p4c, but it's manageable. the p4b is certainly the worst performing, but the the background app functions enough so it does not go "linkdead" from the server), which the a64 background client does if you don't keep task switching. it's like it doesn't receive enough cpu resources to maintain contact with the server.. so you have daoc now (and 2 accounts)?


kylef:

you seem quite knowledgable on this stuff, i appreciate your participation

have another question tho. earlier on in this thread i mentioned that when running an ftp in the background, the d/l rates drop from 3-4mb/s to about 900k whenever a cpu hog (such as running a game) is launched. when the foreground application is closed, it goes back up to 3-4mb/s. any ideas on what would cause this, and if it's related to the other issues we're discussing herer?

 

[Acanthus]

A single cleint on DAOC can use as much as 700MB in certain situations.

I think the people bitching about performance on dual clients simply have 512MB or 768MB of memory, not 1GB+.

Edit: P4C and P4Es do run better in this particular case, but theres a lot of irrelevant data being thrown around about performance that is simply because of the case i mentioned above.

 

[CaiNaM]

Originally posted by: Acanthus
A single cleint on DAOC can use as much as 700MB in certain situations.

I think the people bitching about performance on dual clients simply have 512MB or 768MB of memory, not 1GB+.

they don't come up often that i've seen.. i've never seen it above 360mb, tho i don't drag the char in the background client into rvr situations either

the a64, p4c, and barton all have 1GB ram. the p4b currently has 768mb. while the p4c runs the smoothest by far, the p4b and barton are "serviceable".. the a64 just can't do it, whatever the reason is....

 

[glugglug]

CaiNaM

I assume you mean 300-350MB per client, not K.... Apparently the game has gotten more bloated than when I last played, it used to need around 150MB physical RAM free per client (virtual space allocated was larger IIRC but still less than 300-350MB).

Edit: nm about the how much RAM you have, I just read you have 1GB above.

Yes, the slowdown in your FTP client would be for the same reason. The client is not getting a timeslice so that it can check if there is anything in the buffer for its TCP socket frequently enough, so it ends up blocking the transfer while the buffer is full.

BTW, are you using XP Home or XP Pro. All the "server" MS OSes (which I think Pro might fall in that category) have larger default quanta size.

Vee & Kylef
While NT, 2K, and XP have their differences, most things about them are the same. Kind of like 95, 98, and ME all have the same attributes. If anything the problem should be worse in Win2K than it is in XP because the ticks that the quanta are multiples of is 10ms in XP and 15.125ms in 2K. According to that sysinternals article I linked, the options in the System control panel which Klyef refers to were only there in Win2K beta - however the registry key they modify is still there, and I'm guessing that the OS probably still reads that registry key to figure out the scheduler settings. The flag for giving more CPU to the foreground application or not is in the SAME registry value (its a bitmapped field), and so changing settings in the control panel may overwrite the value manually put there (including other fields in the bitmap). The value of 36 I suggested (0x24), has the flags set for "short" quanta and variable length, with a 0 in the foreground boost part of the field so that even foreground processes will get the shortest of the 3 quanta sizes. Variable length is chosen because if you choose fixed-length quanta, which is the default on "server" windows OSes, then both foreground and background processes get long quanta values (the same as foreground with maximum boost on variable quanta size). The 0 in the foreground boost bits makes it not really variable.

Assuming the quanta table values are the same as what sysinternals has listed for Win2K in WinXP, and assuming I am reading it right, changing the HKLM\SYSTEM\CurrentControlSet\Control\PriorityControl\Win32PrioritySeparation registry key from the default value of 2 (0x02) to 36 (0x24) should change both the foreground and background quanta size to 6 ticks (60ms), from a default of 18 ticks (180ms) for foreground in a home-user OS or 36 ticks (360ms) for both foreground and background in a server OS (XP Pro?) (more in Win2K from bigger ticks). Also, the observed behavior with the normal settings and most CPU-bound apps is that the switching between threads is way slower than 360ms. Are individual threads given multiple quanta in a row based on priority (which would be effectively the same as increasing the quanta size)?

I made this change on my home machine, and it is multitasking quite smoothly, with a video being re-compressed at normal priority, and a large directory being RARed (not backgrounded) as a test.
Firefox is totally responsive with this going on, with no noticable delay scrolling around or clicking/right clicking links, opening new tabs, etc.

 

[kylef]

Originally posted by: Vee

[*] the default quantum size for ALL threads can be set to "short" (default on workstations) or "long" (default on servers) in Control Panel -> System -> Performance Options

(Why does this seem like NT to me?)
No, not on my XPpro it doesn't. What I can do is turn off/on that foreground quanta stretch.

Yes, it does. When you pick "Background services" TWO things happen:
[*] Quantum stretching is turned off (all quanta are equal no matter what is in the foreground)
[*] Long quanta are turned on (12 ticks up from 2 ticks, same as Server)

In order to control the two independently, you have to edit the registry key HKLM\System\CurrentControlSet\Control\PriorityControl\Win32PrioritySeparation. You might be able to google for what values you should use, but otherwise I can tell how to generate the right value if you want (it will take a few minutes to describe).

Only if I switch the radiobutton from "application" to "backgound tasks". Otherwise the foreground/active window app will get that 'stretch'.

Correct, I should have said "Otherwise, two threads running at identical priority...". Sorry for the confusion.

It's the same. And/but it was observed on other CPU hog apps than this game client. Setting Base priority in taskmanager to "low" will result in shorter quanta, and both/all three/four etc. processes will run seemingly smoother since they run in shorter and more frequent quanta.

Like I said, setting a process's priority in Task Manager does absolutely nothing to the size of its threads' quanta. All it does is increase the base priority of the threads, which means they will be scheduled before any lower-priority thread is scheduled. Nothing more.

Remember this is WindowsXP. Behavior is different on Win98 and may be different on NT too. I didn't check NT.

I am talking about the Windows NT-based scheduler. This includes NT 4.0, Windows 2000, and Windows XP. XP's kernel is NT 5.1, if you didn't notice.

I know very little about the Win9x kernel; therefore I don't comment on it.

 

[CaiNaM]

Originally posted by: glugglug
CaiNaM

I assume you mean 300-350MB per client, not K.... Apparently the game has gotten more bloated than when I last played, it used to need around 150MB physical RAM free per client (virtual space allocated was larger IIRC but still less than 300-350MB).

Edit: nm about the how much RAM you have, I just read you have 1GB above.

heh.. yes, i meant MB

Yes, the slowdown in your FTP client would be for the same reason. The client is not getting a timeslice so that it can check if there is anything in the buffer for its TCP socket frequently enough, so it ends up blocking the transfer while the buffer is full.

BTW, are you using XP Home or XP Pro. All the "server" MS OSes (which I think Pro might fall in that category) have larger default quanta size.

xp pro sp2

 

[Vee]

Originally posted by: kylef

Originally posted by: Vee
It's the same. And/but it was observed on other CPU hog apps than this game client. Setting Base priority in taskmanager to "low" will result in shorter quanta, and both/all three/four etc. processes will run seemingly smoother since they run in shorter and more frequent quanta.

Like I said, setting a process's priority in Task Manager does absolutely nothing to the size of its threads' quanta. All it does is increase the base priority of the threads, which means they will be scheduled before any lower-priority thread is scheduled. Nothing more.

Ok. I did notice dropping base priority to just "lower than normal" did nothing. Which did make me question whether "base priority" really have anything to do with quanta length. But facts remains, the process threads runs for much shorter duration.
So why do we get the shorter quanta (seemingly) at "low" then?
Would that drop the threads priority so low, that something else starts to interupt the thread, then the other thread starts next. Could that be it?

BTW. Thanks a lot for contributing.

:wine:
I'm fine with WinXP's behavior. But I'm sure knowing how to manipulate quanta length will be very valuable. I did make an attempt to find such information on Microsoft, but failed to find it for some reason.

 

[Acanthus]

Originally posted by: CaiNaM

Originally posted by: Acanthus
A single cleint on DAOC can use as much as 700MB in certain situations.

I think the people bitching about performance on dual clients simply have 512MB or 768MB of memory, not 1GB+.

they don't come up often that i've seen.. i've never seen it above 360mb, tho i don't drag the char in the background client into rvr situations either

the a64, p4c, and barton all have 1GB ram. the p4b currently has 768mb. while the p4c runs the smoothest by far, the p4b and barton are "serviceable".. the a64 just can't do it, whatever the reason is....

Ive seen over 1GB on relic raids before, but again thats a very isolated and rare situation.

Over 700MB (per client) would be TOA zones on ML or Artifact raids that have a lot of chars on screen.

 

[Vee]

Originally posted by: CaiNaM
strange.. both a barton 2600 (oc'd to 3200+) and p4b 2ghz will run both clients as long as they have >768 k memory (each client takes about 300-350k) do not exhibit this. doesn't run near as smoothly as the p4c, but it's manageable. the p4b is certainly the worst performing, but the the background app functions enough so it does not go "linkdead" from the server), which the a64 background client does if you don't keep task switching. it's like it doesn't receive enough cpu resources to maintain contact with the server.. so you have daoc now (and 2 accounts)?

No. As I described earlier, I have been running a computing app that lets me clearly see the progress in realtime. It's a numerical app that traces properties in a numerical body. That trace is graphically visable in realtime.
I used this to check multitasking performance and observe running behavior (quanta length). It's my own app BTW, so I can have as many licences as I want to.

This would mean you have some problem with the link, that is (for now) endemic to your A64, for some reason. (Another hypothesis: Maybe the performance of the A64 affects some timing issue. I remember there were some snags like that, back in the days you used W95 to run old apps on new processors.)
Anyway, I think the first thing is to make sure you are not running with 'foreground quanta stretch' as we have been discussing here. I am assuming you're not, just making sure.
My unhelpful (sorry) and selfevident suggestion: Then try longer and shorter quanta.

 

[kajames]

Vee, your writeup on the "Athlon 64..." was very enlighthening and very educating...thank you! :thumbsup::wine: Hope to read more from your intelligent tech write-ups! :beer:

 

[slatr]

Quote

ahhh.. a fellow daoc player.. greets

curious, have you tried this on an athlon64 or another non-HT enabled cpu, and if so, how would you compare?

/Quote

Hello CaiNam, I have run DAOC on an Athlon Xp and a P42.0b in the past. I still run one client some on the P4 2.0b. I can run two clients and craft or other near static, low CPU intensive tasks on those machines. I could never reliably move around and not go "link dead" or lose auto follow.

That it the thing, a P4 with Hyperthreading behaves as if it actually has 2 Cpus in many instances. The others do not.

I keep looking at A64s for a fall upgrade and then I remember I need HT. I like my 2.4C but I am very apprehensive about upgrading to a hot running Prescott. I'll have to do more research and see.

 

[CaiNaM]

Originally posted by: slatr

ahhh.. a fellow daoc player.. greets

curious, have you tried this on an athlon64 or another non-HT enabled cpu, and if so, how would you compare?

Hello CaiNam, I have run DAOC on an Athlon Xp and a P42.0b in the past. I still run one client some on the P4 2.0b. I can run two clients and craft or other near static, low CPU intensive tasks on those machines. I could never reliably move around and not go "link dead" or lose auto follow.

That it the thing, a P4 with Hyperthreading behaves as if it actually has 2 Cpus in many instances. The others do not.

I keep looking at A64s for a fall upgrade and then I remember I need HT. I like my 2.4C but I am very apprehensive about upgrading to a hot running Prescott. I'll have to do more research and see.

hi slatr

curious.. how much ram did you have in those machines? i can run 2 instances on both the athlon xp and p4b, tho admittedly not very well. with 1gb in each pc, they don't go linkdead, but do suffer enuff lag that they lose autostick once in awhile, but for the most part only when there were lots of chars on the screen, such as any keep/relic battles or large pve encounters.

the delay is so prominent (3-4 seconds lag) on the a64 that the bot loses stick everytime after about 4-500 clicks.. i can move for like 5 seconds, stop and wait for the bot to catch up, then move again; lather, rinse, repeat (assuming the client doesn't go linkdead). obviously not a workable situation. =/

ht certainly helps on the p4c, as it's noticeably smoother with no lag whatsoever, but i would expect it (athlon64) to at least work as well as it does on the athlonxp, if not better, but it doesn't - that's what really has me scratching my head...

 

[Viditor]

i would expect it (athlon64) to at least work as well as it does on the athlonxp, if not better, but it doesn't - that's what really has me scratching my head...

G'day Cainam...this may be completely left field, but I noticed you were working on SP2. Have you tried disabling DEP (this affects the A64 differently than the AXP because of the NX-bit)?

 

[slatr]

curious.. how much ram did you have in those machines?

768 in those, but now this was before TOA. I have to run 1 gig in my newest machine to run TOA clients.

ht certainly helps on the p4c, as it's noticeably smoother with no lag whatsoever, but i would expect it (athlon64) to at least work as well as it does on the athlonxp, if not better, but it doesn't - that's what really has me scratching my head.

This doesn't seem to me that it could be the processor either. Anything interesting being reported in your event log?