Version 2.7: The Fine Print
As I mentioned in the updates to my previous blog post, after encountering some issues with NOD32 version 3.0, and on the advice of experienced NOD32 system admins, I downgraded to version 2.7.
What I didn’t realize is that by doing so, I would be giving up the ability to exclude files and folders from my scheduled and on-demand virus scans. Why is that a problem? Some years ago, I wrote and sold a set of Microsoft Word macros. NOD32 calls these a “possible unknown macro virus.” Fair enough, but I know what they are so I want to exclude them from scanning. In NOD32 version 3.0, I can exclude them from both real-time and on-demand scans. In NOD32 version 2.7, I can only exclude them from the real-time scanner. With 2.7, if I want the virus alerts to stop, I have to submit the macros to ESET for evaluation. I’m not too keen on sending my intellectual property to a software vendor for review.
The main reason given by other system admins for using NOD32 version 2.7 is that it performs much better than version 3.0. After seeing version 2.7 using 50% of the CPU during an in-depth server scan, I started wondering about this. I wondered more when I noticed that my desktop occasionally seemed to “stall out” for a few seconds running 2.7–an issue that I had not had with 3.0.
The final impetus for doing a real comparison was the sluggishness of the desktop when building a UBCD4WIN ISO file. I decided this might be a good test, since it involves copying a large number of files from both a CD and from disk.
One thing that 2.7 and 3.0 have in common is that by default, they both scan all files, regardless of extension. This turns out to make a big difference in performance. For example, during the UBCD4WIN build process, there is a step that appends data to a 450KB file called txtsetup.sif. From observing the process in FileMon, I see that this process accesses the file thousands of time, apparently working with file offsets to copy one line at a time. When NOD32 (either version) is set to its default to scan all extensions, it takes six minutes to append to this file. However, if I uncheck the “all extensions” box in the NOD32 setup dialog and allow it to scan only its pre-defined list of extensions, UBCD4WIN blows by this append step in about five seconds.
My comparison between the versions was not terribly rigorous. I just ran the UBCD4WIN build process multiple times, noting the start and stop times. Since I didn’t note seconds, there’s at least a ±1 minute margin of error. I ran the tests on an old Dell Dimension 2400 (Pentium 4 2.66GHz) with 1GB of RAM. I compared NOD32 2.70.39 to 3.0.642, both with current virus signatures.
The times to build the UBCD4WIN ISO file were as follows:
No antivirus software installed: 9 minutes.
NOD32 version 2.7, real-time scanning disabled: 9 minutes.
NOD32 version 2.7, scanning only specific extensions: 14 minutes.
NOD32 version 2.7, scanning all extensions: 20 minutes.
NOD32 version 3.0, real-time scanning disabled: 10 minutes.
NOD32 version 3.0, scanning only specific extensions: 14 minutes.
NOD32 version 3.0, scanning all extensions: 24 minutes.
With both versions, watching Performance Monitor, I saw the antivirus process frequently exceeding 90% CPU usage, especially during the six-minute scan of txtsetup.sif.
Perhaps the most obvious conclusion is that, regardless of NOD32 version, it’s hard to justify accepting the default to scan all extensions, since it adds 40% or more to file access times. When set to only scan extensions that ESET identifies as vulnerable to viruses, there is no significant performance difference between the versions.
If performance is about the same, what other factors might influence one’s choice between 2.7 and 3.0?
- Both versions have quirks that make it difficult or impossible to deploy some configuration settings using ESET’s .xml configuration files.
- Version 3.0 has the important ability to exclude files and folders from on-demand and scheduled scans. It may be possible to work around this in 2.7 using Task Scheduler and NOD32’s command-line scanner.
- In Version 3.0, the correlation between the client and the configuration editor (used for mass deployments) is less clear than in 2.7.
As the newer product, version 3.0 may still have issues that make 2.7 the safer bet for the short term. However, it’s encouraging that version 3.0’s real-time performance is on par with 2.7, at least with the specific-extensions list. I’d be interested to hear if others get similar results.