For real-time/background scanning. It was actually brought up by a friend, I generally haven't noticed issues. He wants a new AV program to run real-time scanning, but wants to be able to set a limit to the amount of CPU it can use. An out of control real-time scanner can be really annoying. I suppose you could set priorities...but I would think a program should be able to have that kind of setting also...so I was curious.
In that case I know of no such feature as such. I see quite a few messages in which people allude to background scanning slowing their systems to a crawl. In all really capable operating systems the user (well, the admin user, anyway) can assign lower priorities to processes that they believe are taking too much CPU time. However, I don't really think that system crawl induced by background AV scanning arises only from the scanner hungrily grabbing processor time. The key to this observation is that, in the instances I've seen this type of system slowdown, the system was slow to relinquish the processor to other user-initiated processes. That's what really bugs us as users. There's no reason for me to be annoyed if a process that I want to run, whether it be indexing or AV scanner or defragmentation or file transfer, takes nearly 100% of the CPU's time when I'm not trying to use the user interfaces and initiate or use other processes in an interactive manner. It's great that operating systems can be that smart. But they can be thwarted by a faulty AV scanner (or other concurrent process) that doesn't drop the reigns immediately when the user interface is touched. Most AV scanners interact with various system drivers and services in an extremely involved fashion. If a network interface card and your AV scanner, for instance, go toe-to-toe with each other at the driver or services level you are likely to see reduced network traffic throughput, but you are also very likely to see a system that won't respond readily to the GUI while the scanner is running. After all, if the scanner running under SYSTEM is examining a library at the moment the library needs to be called by a system driver or service you've got two (at least) system level processes grabbing for the library. Somebody is going to have to wait. If you try to use the mouse or keyboard at that moment you are probably going to experience a delay in response.
I doubt that setting use caps from within the program (which might not work terribly well in this type of OS anyway) would help prevent this sort of situation from arising. It doesn't really matter as much how hard the scanner is working as it matters where and when it is working -- and, perhaps, what type of work it is doing. (It appears that heuristics scanning requires scanners to linger quite a while longer at each task, and it may increase the likelihood of seeing an inter-process incompatibility behavior.) Furthermore, if any of the drivers or services with which the scanner interacts (or the scanner's pseudo-drivers and services themselves) have compatibility issues with the operating system, alone or in conjunction with each other, you have the makings of a real brouhaha amongst system processes that can make it hard to get any response at all from the user interface. Again, setting thread priority or capping the process' access to the CPU would have little or no effect upon this sort of interaction. When processes that run at kernel level present the system with conflicting needs, those issues have to be resolved before other more mundane tasks can be undertaken. The stability of the system depends upon it.
I have a 500 MHz PIII running concurrent AV scanning with extremely aggressive heuristics features turned on and a software firewall that not only examines every process going in and out of the system but which also examines all cases where one process calls another on the system. That computer is as responsive to the user interface with that stuff running on it as it is without that stuff running on it, and it always initiates new processes at the user's request with alacrity. If I put that same AV / firewall combination on my 2.4 GHz P4 and let the system sit idle for a few minutes I might as well go for coffee the next time I try to use the mouse or keyboard. It's a driver issue. Until I get it figured out I have to resort to using different AV and firewall software for protecting that system. (The two computers, BTW, have the same OS and the same software loaded, just different hardware.)
I do understand why some people throw up their hands and ask why AV scanners are necessary. They can be a real pain in the butt. I have found that NAV has a real proclivity for this sort of issue, and that would explain why some people love it and some people detest it. It works supremely well on some systems and despicably awful on others. Same software, different hardware and software setting.
Now, if you have a dual or multi-processor system, then I suppose you can make use of processor affinity to help get a handle on issues like this. I've never had to bother to do that for an AV scanner on an MP box, though.
- prosaic