Mr_Furball :
Pinhedd :
Mr_Furball :
Pinhedd :
Mr_Furball :
Pinhedd :
GPUTemp.exe may be the culprit. Peripheral monitoring software often conflicts with the device driver's own internal monitors, or it may attempt to measure something in a fashion that causes performance problems. This is very common with third party GPU software, even popular ones such as MSI Afterburner. AMD knows what they're doing with their own hardware better than anyone, so I'd rely on the CCC monitor and nothing else. There's really no need to monitor GPU temps at all anyway, those things can take an awful lot of heat; just set it and forget it.
Raptr may also cause problems as I've heard that it mucks around with application settings and driver settings. I don't use it myself, so I can't speak to it authoritatively.
Windows Media Player (any modern media player actually, including browser based ones) can take advantage of hardware accelerated video decoding (DXVA). This can have a noticeable performance impact if used at the same time as a game, even if the decoding is slight. I can imagine that it might cause a performance hit simply by being open in the background. Close them all down just to be sure.
Lastly, Avast is probably not the culprit, but try playing with it disabled. Who knows.
I don't understand about the subject but everything you said is actually true, I just downloaded Avast to scan for antivirus and about Raptr, I also had a feeling that after I downloaded it I started having some perfomance issues. But I'll try to delete them and then come back to you.
Okay. Fingers crossed
Haha, so man here it goes, that annoying lag above 30 fps is back BUT battlefield, skyrim, medal of honor and other games (i couldnt even launch Moh) came back to normal, its incredible how some programs can mess up your computer, but they still have that continuous annoying lag above than 30, especially State of Decay since its already bad optimized. But yeah you are awesome Pin thanks, I just need to find the source of this lag. You don't think the fact that I'm downloading games on origin has something to do, do you? It's just that sometimes show that it's using 10% of my CPU but some other times goes up to 25%
Downloading stuff involves a fair number of interrupts and DMA transfers. This does occupy the CPU and system bus a bit; not a whole lot but it can add up, how much so depends on the particular hardware involved. Aggregate performance will definitely be better when you're not downloading stuff than when you are, but I doubt that it would be substantially better.
CPU usage is not a very useful metric for analysing performance issues. It can be downright misleading at times. The reasons for this are incredibly technical and require a thorough explanation to understand. If you'd like to know I'd be happy to explain it though.
In any case, the source of the lag is likely that the reference HD 6850 isn't terrific by today's standards.
My laptop has a 2GiB HD 6970M which is a slightly downclocked HD 6850 with more memory. It makes for a pretty decent litmus test in this case given that the two cards are architecturally identical. I don't play demanding games on my laptop at all, but I recall 30-40 FPS on BF3 using high settings being normal when I tried it out.
Of course I would like to hear your explanation, but the problem of this lag is that I can run battlefield on ultra, and it doesnt matter in which quality I set, it will be still "lagged", I actually have a video recorded with fraps in a online match on High, and the reason is the resolution I believe that helps me a lot so that's why it freaks me out so much . But what you said about play while not downloading WILL improve performance but substantially, I totally agree and about the CPU misleading you, too. I keep wondering why you're not one of the top experts
It's a fact that you have more knowledge in most areas than the second best guy.
I prefer to chime in on the hard to answer technical questions. There are many other users on this site that are more active than I am, so in terms of pure "best answers" I fall behind a bit.
In any case, I'm a little bit drunk at the moment so this may make less sense than it normally would (if that's even possible).
Measurements of CPU time differ from operating system to operating system, but they're all conceptually similar. CPU time is the measurement of the fraction of time over a fixed time window that the CPU(s) spend executing processes other than the System Idle Process.
Windows NT and its descendants normalize this value to 1 and each logical processor contributes an evenly divided fraction. If there are two logical processors in the system, each corresponding to a separate CPU core, with one busy 100% of the time and the other idle 100% of the time the CPU usage in the task manager would be 50%. If both logical processors are busy 100% of the time, the CPU usage would be 100%. If both logical processors are idle close to 100% of the time, the CPU usage would be close to 0%.
Unix operating systems and Unix-Like operating systems do not normalize the usage. Each logical processor has its own usage between 0.00 and 1.00, and all of the logical processors are summed together to obtain the total system usage. A dual-core system like the one above running an NT variant would have a load between 0.00 and 2.00 rather than 0% and 100%. They are mathematically and conceptually identical, one is just normalized while the other is not.
Intel's use of SMT (Intel's proprietary implementation is called Hyperthreading) throws a proverbial wrench into this measurement. A CPU that features SMT exposes two or more logical processors per core. Given that SMT is very dynamic, it is possible to schedule threads such that the CPU's execution resources may be completely monopolized by one logical processor while the other remains idle. From the execution perspective, the CPU's instruction issuing capabilities are nearly 100% utilized, but from the perspective of the operating system facing logical processor it may only be 50% utilized. Applications that aim to meet real-time constraints such as inter-frame latency often tweak their own scheduling policy to avoid scheduling demanding threads on logical processors that both belong to the same core. You may have read that games don't use hyperthreading; this is not technically true, but it appears to be true by looking at the effects. When looking at CPU usage from the logical processor scheduling perspective, this can give the illusion that a CPU is heavily under-utilized when it is in fact highly utilized when looking at it from an instruction scheduling perspective. This phenomena is unique to microprocessors that employ SMT, of which currently only Intel's i3 and i7 series microprocessors do. It is however not the only thing that makes it a misleading metric.
Most general purpose operating systems use a pre-emptive quantized multi-level priority queue scheduling policy. That's a bit of a mouthful, so lets digest it a bit to figure out what it means.
The scheduling policy is the procedure that the operating system uses to determine which thread to schedule on which logical processor.
A quantized scheduler divides the CPU time for each logical processor into finite length chunks. When the scheduler runs, it picks an appropriate thread to run on the logical processor, and then starts a timer. If the thread doesn't relinquish the CPU before the timer expires, the operating system kicks it out and replaces it with a new one.
A multi-level scheduler establishes multiple priority levels for threads. If a high priority thread is ready to run, it will be given CPU time before any threads of lower priority. If a low priority thread is running, this means that no thread of higher priority is ready to run.
A priority queue scheduler allows for multiple threads to have the same priority level. Threads of equal priority are organized in a queue. When a thread either relinquishes the CPU due to a long-latency event (waiting for a signal, or an IO event) or has its time slice expire, the operating system schedules the next ready thread of the same priority. If the time slice expired, and the thread still has work to do, it goes to the back of the line. If no thread of the same priority is ready to run, the scheduler moves down the next queue until it hits the lowest priority queue which holds only the System Idle Process.
A preemptive scheduler allows any high-priority thread that becomes ready for any reason to immediately replace any lower priority thread without that thread's time slice expiring or it voluntarily relinquishing the CPU.
High priority threads are typically short lived and time sensitive. A good example would be a thread that handles keyboard/mouse input for a game. It waits for a hardware even to occur (such as a keypress), seizes control of the CPU when it does, performs a short lived task, and then waits until another event occurs.
Low priority threads are typically computationally or IO intensive, and are not time sensitive. A good example would be a background process that builds a cache or validates some downloaded data.
When it comes to calculating CPU time, all threads belonging to a process are treated equally. If the Origin thread that handles the downloading is appropriately configured to run in low priority, it will be pre-empted by any and all normal and high priority threads that exist in the system and are ready to run. Only when they are not ready to run (blocked/waiting) will lower priority tasks be run. It may consume up to 25% of the CPU time, but this is not evidence that the consumed time comes at the expense of a higher priority thread in another process, such as one belonging to Battlefield 3. It may be that BF3 has no work for the CPU to do at that time, so the operating system just schedules something else until BF3 is ready to go.
A good experiment would be to run and observe the effects of Prime95. Prime95 is a fairly famous stress test for most PCs. It has one main GUI thread which runs in normal priority, and one worker thread per logical processor that runs in low priority. The CPU usage will appear to be a constant 100% on all logical processors, but if the system has sufficient memory the operating system should remain responsive and perform well on any application that uses threads of higher priority. You could browse the web, listen to music, and play games while Prime95 is running in the background. Prime95 will simply have to wait a bit longer to complete some operations, but it's not time sensitive at all so that's acceptable to the user whereas skips in music are not.
The reason why I asked you to include the "Base Priority" column in your task manager screenshot is to see if there were any processes running in high-priority when they shouldn't be. If a process doesn't explicitly configure the priority of threads that it creates, they will inherit the priority of the first thread in the process (or the thread that created it). If a computationally intensive process runs one or more threads in high priority, it will prevent all other threads of lower priority from accessing the CPU, which can render the system less responsive than it would be if the computationally intensive process were run at low priority. You may notice that DWM.exe runs in high priority, this ensures that the desktop window manager can always preempt applications that utilize the desktop as well as their own event and IO threads that run as "above normal", but that it will never starve out or compete with service threads that it relies upon (these run in an even higher priority level, "realtime").
Okay, that's enough for now
EDIT: wording
Facebook
Twitter
Instagram