39 réponses à ce sujet

[lawpel19]

 I do not know if others having trouble with memory leaks or not. and it only for this game I have any issue with leaks. When I first start playing. loading defreant areas is very fast. But about an hour or so later it can take up to 5 min to load a new area.  Is this a problem with the game? I do not think it my computer since i have no memory leak with any other program or game on my pc.

[Faricho]

I don't have any long load times, but my game crashes after two hours of gameplay

but I have read that there are others with your same problem

Modifié par Faricho, 13 décembre 2009 - 09:44 .

[Rubbish Hero]

Many people are having this problem.

Nothing is being done, we are doomed.

[JironGhrad]

There's no memory leak. I've said it around 100 times now. A true leak would affect every user regardless of system specs. There's a known issue with certain AMD Phenom processors that can be fixed with a program (there's instructions in the Troubleshooting FAQ). Further, I've just uncovered what seems to be a problem with the CPU L2 cache buffering: I've been talking to several people with specs similar to mine... I have no issues, they have slow downs... the noteworthy difference is a smaller L2 cache, which would fill up and then overflow causing slow-downs as it's being cleared and reused. Which makes a lot of sense since in some cases it's resolved by using processor affinity to reduce which cores are being used (the reason it might not work for some and will work for others would depend on how the L2 cache is handled on the individual processor... some use a shared L2 cache and others have dedicated caches per CPU).

[lawpel19]

well it something and i do not have an amd. but if it not a memory leack then what is it.

I have an intel core 2 quad core 2.33.

8gm of rams

64 bit operationg system. windows 7 home

nvidia geforce 9500 gs

and yes i know i need to upgrade my graphics card.



not a top of the line system but can play most game including assasins creed on high graphis or better

[JironGhrad]

Have you tried any of the fixes in the link in my signature? The CPU affinity fix works for most Intel quads (some require you to only use CPU 3 though)

And to answer "What is it?"... it appears to be related to the CPU's ability to buffer/unbuffer data and resources.  Since that's primarly linked through the L2 cache, it may be that the game is either trying to make use of too much at once or there are background programs/processes running on many machines that are flooding the buffer too fast while the game is running.  The result is that it takes time for the processor to work through all the stuff it's being told to do (by the game and whatever else is running) and it doesn't prioritize the game (especially if there are services that are causing it).

Modifié par JironGhrad, 13 décembre 2009 - 10:45 .

[Arpl]

JironGhrad: No. CPU cache doesn't work that way at all. Please take your time to read the technical documents both from Intel and AMD on the subject before talking about it, misdirected guessing doesn't help anyone.



Having said that, I don't know for sure what's causing the slowdowns. If I were to make an educated guess on what's happening I'd wager that BioWare is using some odd resource caching mechanism whose concurrent performance worsens as the cache grows, which would explain why setting the CPU affinity to as few cores as possible and therefore limiting the actual physical threads helps combat the problem(Less collisions), and also why i7 and especially Phenom owners are hit the hardest by all this.

[Rasanaa]

Ummm, sorry Arpl, but this I7 920 user has never experienced slow downs or crashes with the game. Recently applied the 1.02 patch as well and I'm still not having issues. Might have to look at something else as the reason.



Specs: Intel I7 920 clocked to 3.2ghz

6gb ddr3 overclocked to something high (I forgot and don't want to check my BIOS by restarting the machine, hehe)

Intel DX58S0 motherboard

WD 250gb velociraptor sata (10k rpm)

ATI 4870 X2 2gb of ddr5 (core 750mhz, memory clocked to 900mhz)

Thermtake 850watt PS



For all the guessing about what it might be, it could have something to do with the graphic card chipsets or even motherboard chipsets. I've never experienced issues with Dragon Age on the I7 though.

[JironGhrad]

The CPU is cache is where it stores the list of RAM calls... it checks the cache in the order of the received instructions (unless there are specific instructions from the OS otherwise, it typically does them as received though this can be modified by setting thread priority and some other things). So it's not misdirected guessing; by "using too much" I mean that it's misreading a cache hit and creating a new entry (which would be consistent with poor processor thread handling) and why in some cases disabling services or programs could reduce the slowing.



Please excuse my attempt at explaining it in a language understandable by the average user as ignorance. If you'd really like to go into greater depth about my theory (in the precise and exact language of caching) I'd be pleased to take it up with you via PM.

[Arpl]

Rasanaa wrote...

Ummm, sorry Arpl, but this I7 920 user has never experienced slow downs or crashes with the game. Recently applied the 1.02 patch as well and I'm still not having issues. Might have to look at something else as the reason.

Specs: Intel I7 920 clocked to 3.2ghz
6gb ddr3 overclocked to something high (I forgot and don't want to check my BIOS by restarting the machine, hehe)
Intel DX58S0 motherboard
WD 250gb velociraptor sata (10k rpm)
ATI 4870 X2 2gb of ddr5 (core 750mhz, memory clocked to 900mhz)
Thermtake 850watt PS

For all the guessing about what it might be, it could have something to do with the graphic card chipsets or even motherboard chipsets. I've never experienced issues with Dragon Age on the I7 though.

Like I said, it was merely a guess, and i7 owners don't suffer from this problem nearly as much as Phenom owners.

All I know for certain is that it has little or nothing to do with the CPU cache. Degradations of this magnitude and over such long periods of time simply cannot be attributed to cache misses alone. The only thing that can explain a problem like this is that someone's been a sloppy coder, and since a lot of people with different hardware configurations are experiencing the same thing, it's unlikely that this is a driver issue, so I'm pointing my finger at BioWare.

Patch it. o_o!

JironGhrad wrote...

The CPU is cache is where it stores the list of RAM calls... it checks the cache in the order of the received instructions (unless there are specific instructions from the OS otherwise, it typically does them as received though this can be modified by setting thread priority and some other things). So it's not misdirected guessing; by "using too much" I mean that it's misreading a cache hit and creating a new entry (which would be consistent with poor processor thread handling) and why in some cases disabling services or programs could reduce the slowing.

Please excuse my attempt at explaining it in a language understandable by the average user as ignorance. If you'd really like to go into greater depth about my theory (in the precise and exact language of caching) I'd be pleased to take it up with you via PM.

Like I said before, read the docs. Your explanation, no matter how much I try to twist it, is incorrect and misleading, and judging from your jargon so far I highly doubt you could explain it in greater detail through PM.

Modifié par Arpl, 14 décembre 2009 - 03:28 .

[shawnglory]

my i7 975 @ 3.33 do get these leaks as well and it still does when i crank it up to 3.8 ghz.

Although i have to admit that I've only been able to survive up to 3-4 hours twice to actually witness this happening. Other wise I'll get an error on the memory could not be read withing the first minute to the twentieth minute. I'd rather have these degradations and slow downs compared to total game crash to be honest >.< besides restarting your comp every 2 hours or so never hurts anyone.

[JironGhrad]

Arpl wrote...

Rasanaa wrote...

Ummm, sorry Arpl, but this I7 920 user has never experienced slow downs or crashes with the game. Recently applied the 1.02 patch as well and I'm still not having issues. Might have to look at something else as the reason.

Specs: Intel I7 920 clocked to 3.2ghz
6gb ddr3 overclocked to something high (I forgot and don't want to check my BIOS by restarting the machine, hehe)
Intel DX58S0 motherboard
WD 250gb velociraptor sata (10k rpm)
ATI 4870 X2 2gb of ddr5 (core 750mhz, memory clocked to 900mhz)
Thermtake 850watt PS

For all the guessing about what it might be, it could have something to do with the graphic card chipsets or even motherboard chipsets. I've never experienced issues with Dragon Age on the I7 though.

Like I said, it was merely a guess, and i7 owners don't suffer from this problem nearly as much as Phenom owners.

All I know for certain is that it has little or nothing to do with the CPU cache. Degradations of this magnitude and over such long periods of time simply cannot be attributed to cache misses alone. The only thing that can explain a problem like this is that someone's been a sloppy coder, and since a lot of people with different hardware configurations are experiencing the same thing, it's unlikely that this is a driver issue, so I'm pointing my finger at BioWare.

Patch it. o_o!

JironGhrad wrote...

The CPU is cache is where it stores the list of RAM calls... it checks the cache in the order of the received instructions (unless there are specific instructions from the OS otherwise, it typically does them as received though this can be modified by setting thread priority and some other things). So it's not misdirected guessing; by "using too much" I mean that it's misreading a cache hit and creating a new entry (which would be consistent with poor processor thread handling) and why in some cases disabling services or programs could reduce the slowing.

Please excuse my attempt at explaining it in a language understandable by the average user as ignorance. If you'd really like to go into greater depth about my theory (in the precise and exact language of caching) I'd be pleased to take it up with you via PM.

Like I said before, read the docs. Your explanation, no matter how much I try to twist it, is incorrect and misleading, and judging from your jargon so far I highly doubt you could explain it in greater detail through PM.

I've read the technical documents that you keep referring to, but as I said before, talking over people does nothing beneficial and simply alienates you from the people you're attempting to help who don't understand what you're talking about.

The problem with your explaination is that there are quite a few people who have no problems whatsoever.  Likewise, you're arguement that i7s aren't subject to it are also completely false.  I've got a number of confirmed i7 920 processors who've failed and been corrected by setting CPU affinity. Further, I've been working with several people who are experiencing the slow-down on units that are nearly identical to mine.  The main difference? CPU cache. 1mb vs 2mb. Say what you like about how you perceive my understanding of the technical documents from AMD and Intel and how CPU caching works; when you have eliminated the impossible, whatever remains, however improbable, must be the truth.

Further, if someone swaps a processor and that fixes the problem (it's been reported on multiple threads here with no other changes) that tends to put a kink in the chipset theory. And your statistics on i7 failures came from where? Maybe there are simply fewer users with i7 processors since there are only 2 model i7s for less than $500 on Newegg.  With some of the Phenom processors I've worked with here, the only difference between lagging and not is hardware revision.  A single number reported by CPU-Z. Perhaps if you spent more time helping and less time criticizing everyone who's got problems would be playing, since clearly you know so much more than I.

Modifié par JironGhrad, 14 décembre 2009 - 06:08 .

[JironGhrad]

And as a side note, this is what I was getting at with my theory on the L2 Cache. They tested it for sufficient cache only; I believe that it's somehow creating an insufficient cache scenario which would result in slowdowns and possibly crashing.

Modifié par JironGhrad, 14 décembre 2009 - 06:22 .

[Arpl]

JironGhrad wrote...

I've read the technical documents that you keep referring to, but as I said before, talking over people does nothing beneficial and simply alienates you from the people you're attempting to help who don't understand what you're talking about.

No, you obviously have not, and if you did you clearly didn't understand them, and while I cannot fault you for not understanding exactly what happens to the cache during a context switch, I feel obliged to point out that you're posting very misleading(!) information and that's that. 

As for the rest of your post, please note that I never stated that i7's do not suffer from this problem at all, only that they don't seem to have as much issues than Phenoms(both stepping B2 which suffers from the TLB bug, and B3 which doesn't). Also, you need to understand that coorelation is not causation; while the problem might be exacerbated by not having enough cache (Although I highly doubt it, I've got 6MB L2 and L3 here and I'm still having this issue), you cannot blame it entirely on cache alone. It's most likely just some very bad piece of code whose problems are inflated by various hardware factors.

And as a side note, this is what I was getting at with my theory on the L2 Cache.

If that was the cause of it, the problem would not manifest itself in this manner. If it was just plain cache misses and nothing else it would manifest itself as bad load times all over the board, not as exponentially increasing load times, and in either case it's some dev at BioWare's fault for writing bad code and it needs to be patched.

Don't blame the hardware.

[JironGhrad]

Arpl wrote...

JironGhrad wrote...

I've read the technical documents that you keep referring to, but as I said before, talking over people does nothing beneficial and simply alienates you from the people you're attempting to help who don't understand what you're talking about.

No, you obviously have not, and if you did you clearly didn't understand them, and while I cannot fault you for not understanding exactly what happens to the cache during a context switch, I feel obliged to point out that you're posting very misleading(!) information and that's that. 

As for the rest of your post, please note that I never stated that i7's do not suffer from this problem at all, only that they don't seem to have as much issues than Phenoms(both stepping B2 which suffers from the TLB bug, and B3 which doesn't). Also, you need to understand that coorelation is not causation; while the problem might be exacerbated by not having enough cache (Although I highly doubt it, I've got 6MB L2 and L3 here and I'm still having this issue), you cannot blame it entirely on cache alone. It's most likely just some very bad piece of code whose problems are inflated by various hardware factors.

And as a side note, this is what I was getting at with my theory on the L2 Cache.

If that was the cause of it, the problem would not manifest itself in this manner. If it was just plain cache misses and nothing else it would manifest itself as bad load times all over the board, not as exponentially increasing load times, and in either case it's some dev at BioWare's fault for writing bad code and it needs to be patched.

Don't blame the hardware.

Once again you feel compelled to point out that you think I'm wrong, but you've yet to bother explaining it any better or provided any useful explaination.  And, while I'm certainly willing to admit to being a fallable human being, you've failed to enlighten us and provided no direct evidence of my wrongness. I could run through a Doctor's office and write "misleading" on every chart for every patient and that still would just make me an idiot unless I could provide sufficient proof.

Claiming I shouldn't blame the hardware is nice and all, but still fails to explain why it works fine for the majority of users.  Likewise, it fails to explain why swapping the processor fixed the problem; where swapping graphics cards and motherboards hasn't yet resolved this problem for people.

Perhaps you might have some credibility to your statements once you've been here and helped solve some problems.
As to my final thought, http://en.wikipedia.org/wiki/CPU_cache has the same information found in the technical documents from Intel and AMD with sufficient references.  For those who want to check the accuracy of my statements themselves, I encourage you to do so; though it's fairly dry and somewhat technical.

[CDay09]

Taken from my other topic:



"Dragon Age took up my CPU Usage all the way to about 90%. Im playing it on my not-so-top-of-the-line computer because Im too lazy to transfer it to my good computer =p. The problem was that my GPU was getting to a temperature of around 125 degrees Celsius, a dangerous temperature for any computer part. That took me about 3 hours to figure out. It seems most NVidia cards will try to cool down the GPU around 120C, and that slow down along with the heat is what was causing the major lag.



Believe it or not, the major fix that I found was elevating the rear end of my tower up about 3", allowing a better airflow I do believe. Also, I found that by turning my brightness down on my moniter from 100% to 30% helped out too. I'm not sure if they technically helped at all, but the results showed my GPU dropping to a temperature around 80C just from those. Still, the game will run the GPU hot around 105C now, but thats still a lot better than a dangerous 125-130. Also, minimizing dragon age for a minute or two lowers the temperature, and taking a break from playing will reduce the temperature obviously despite how hard it is to stop playing =p."



This is what was causing the lag for me. Game runs fine when the temperature is cooled. So if anyone would like to take a look into this further, it would be much appreciated. As Jiron has been saying, it's not a memory leak.

[JironGhrad]

Interesting point CDay. Were you experiencing the increasing load times as well, and were those corrected by reducing the overall temps?

[CDay09]

I've never had a significant problem with the load times. I've been patient with them by experiencing Oblivion and Mass Effect load times =p. To answer the question, yes, it seems to have affected them, although very little. A reduction of about 10-30 seconds per load it seems.



And sorry for talking a little medieval, I've been playing way too much lately =p

[Arpl]

JironGhrad wrote...

Once again you feel compelled to point out that you think I'm wrong, but you've yet to bother explaining it any better or provided any useful explaination.  And, while I'm certainly willing to admit to being a fallable human being, you've failed to enlighten us and provided no direct evidence of my wrongness. I could run through a Doctor's office and write "misleading" on every chart for every patient and that still would just make me an idiot unless I could provide sufficient proof.

Because it's too obvious.

The entire cache is written back to memory and invalidated upon a context switch, and as such, another application cannot "flood" or otherwise ruin the cache for another application (Well, more than the switch does, anyway). Moreover, the cache is also written back and invalidated upon entering kernel mode, which happens on every system call, making your argument completely moot.

Claiming I shouldn't blame the hardware is nice and all, but still fails to explain why it works fine for the majority of users.  Likewise, it fails to explain why swapping the processor fixed the problem; where swapping graphics cards and motherboards hasn't yet resolved this problem for people.

It's a software problem made worse by hardware factors. If it was just hardware then it would not be isolated to DAO.

Modifié par Arpl, 14 décembre 2009 - 07:16 .

[JironGhrad]

Arpl wrote...

JironGhrad wrote...

Once again you feel compelled to point out that you think I'm wrong, but you've yet to bother explaining it any better or provided any useful explaination.  And, while I'm certainly willing to admit to being a fallable human being, you've failed to enlighten us and provided no direct evidence of my wrongness. I could run through a Doctor's office and write "misleading" on every chart for every patient and that still would just make me an idiot unless I could provide sufficient proof.

Because it's too obvious.

The entire cache is written back to memory and invalidated upon a context switch, and as such, another application cannot "flood" or otherwise ruin the cache for another application (Well, more than the switch does, anyway). Moreover, the cache is also written back and invalidated upon entering kernel mode, which happens on every system call, making your argument completely moot.

Claiming I shouldn't blame the hardware is nice and all, but still fails to explain why it works fine for the majority of users.  Likewise, it fails to explain why swapping the processor fixed the problem; where swapping graphics cards and motherboards hasn't yet resolved this problem for people.

It's a software problem made worse by hardware factors. If it was just hardware then it would not be isolated to DAO.

Now you're the one who's posting misleading information.  I also never said the cache was solely to blame, but I do believe it to be the processor that's the root cause.  You have shown that you don't understand how multicore CPUs work as they contain logic to allow several hardware contexts to exist simultaneously, eliminating the need to store and restore the CPU context to memory on context switch. Furthermore, as the it's processor and not the OS that determines thread-handling (unless you specificially adjust it with something like CPU affinity) it never is completely set aside while running.  By that same token, most versions of Windows are configured to run the program that's currently in the fore at the optimum level.  Because of that design, the OS automatically allocates the highest priviledge level to the running program (and it can conflict with other programs as shown by the auto-minimizing AVG 9.0 scenario) so it will, under normal circumstances, never need to make a system call. 

No system call, no context switch... no write-back; and with the higher volume caches these days it's not normally necessary to need to do that.

[Deathstalker2324]

Nvidia Geforce GTX 280

Intel Core2 Duo CPU E8500 @3.16ghz

3Gb Ram

Windows Vista

Very good quality Alienware computer And i am having the same loading problems as many others are. The game loads quickly and consistently for the first 30-minutes to 1 hour of play then slows to a grinding halt and takes 2-5 minutes to load.



I see the argument going on in this thread and unfortunately i dont have enough technical know how to get involved but i thought throwing one more ailing computers specs into the mix couldn't hurt.

[whtnyte-raernst]

You know guys, you have a lot of peoples eyes glazing over here.

I understand what your saying, but then, I have a degree in computer forensics. 99% of the people on here don't care if it's a memory leak (I know, it's not a memory leak is one programs virtual sandbox corrupting another programs memory space) or buffer overruns, or bad variable handling and not releasing, all they care is the game bogs down! And right now, the best solution is: If you've been playing for 6 hours and it's slow loading, shut the game down and restart!

[CDay09]

I want to know if my solution is the one that works (for the time being). I'd like someone else to download SpeedFan or something that keeps track of his/her GPU Temperature, and then run Dragon Age with a low temperature. Continue playing until lag occurs, and then check the temperature. I've provided some quick fixes in my earlier post and I'm really interested if the GPU heat is what's causing the problem.



Though, it may just be a personal problem, but like I said, I'm intrigued. Would anyone else please test the problem pertaining to heat?

[Arpl]

JironGhrad wrote...

Arpl wrote...

JironGhrad wrote...

Once again you feel compelled to point out that you think I'm wrong, but you've yet to bother explaining it any better or provided any useful explaination.  And, while I'm certainly willing to admit to being a fallable human being, you've failed to enlighten us and provided no direct evidence of my wrongness. I could run through a Doctor's office and write "misleading" on every chart for every patient and that still would just make me an idiot unless I could provide sufficient proof.

Because it's too obvious.

The entire cache is written back to memory and invalidated upon a context switch, and as such, another application cannot "flood" or otherwise ruin the cache for another application (Well, more than the switch does, anyway). Moreover, the cache is also written back and invalidated upon entering kernel mode, which happens on every system call, making your argument completely moot.

Claiming I shouldn't blame the hardware is nice and all, but still fails to explain why it works fine for the majority of users.  Likewise, it fails to explain why swapping the processor fixed the problem; where swapping graphics cards and motherboards hasn't yet resolved this problem for people.

It's a software problem made worse by hardware factors. If it was just hardware then it would not be isolated to DAO.

Now you're the one who's posting misleading information.  I also never said the cache was solely to blame, but I do believe it to be the processor that's the root cause.  You have shown that you don't understand how multicore CPUs work as they contain logic to allow several hardware contexts to exist simultaneously, eliminating the need to store and restore the CPU context to memory on context switch.

And you have shown you've never written a kernel as a hobby project.

The CPU cache is not part of the context itself and needs to be written back to memory upon a switch, otherwise, any changes not written back to memory would be lost. Moreover, if the cache isn't invalidated upon switching to kernel mode or another process, then any reads in the new state would become invalid and cause really odd behavior.

Furthermore, as the it's processor and not the OS that determines thread-handling (unless you specificially adjust it with something like CPU affinity) it never is completely set aside while running...

No, it's the OS that handles threads, the processor just does what it's told (By the OS). If you had read the technical docs you would've known that.

By that same token, most versions of Windows are configured to run the program that's currently in the fore at the optimum level.  Because of that design, the OS automatically allocates the highest priviledge level to the running program (and it can conflict with other programs as shown by the auto-minimizing AVG 9.0 scenario) so it will, under normal circumstances, never need to make a system call.

No system call, no context switch... no write-back; and with the higher volume caches these days it's not normally necessary to need to do that.

*headdesk*

http://en.wikipedia....iki/System_call

You know guys, you have a lot of peoples eyes glazing over here.

I understand what your saying, but then, I have a degree in computer forensics. 99% of the people on here don't care if it's a memory leak (I know, it's not a memory leak is one programs virtual sandbox corrupting another programs memory space) or buffer overruns, or bad variable handling and not releasing, all they care is the game bogs down! And right now, the best solution is: If you've been playing for 6 hours and it's slow loading, shut the game down and restart!

You're right, maybe I should just give up and wait for BioWare to patch it, trying to convince anyone that it's not entirely a hardware problem is a pointless endeavor, as evidenced by this thread.

Meh.

Modifié par Arpl, 14 décembre 2009 - 08:28 .

[JWT2k6]

This looks like a good thread to keep up with.

*grabs some popcorn*