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.
Performance Comparison
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.
About Extensions
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.
The Numbers
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.
Conclusions
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.
Nod32 is a great product according to the current rankings. Its # 3 I believe. When I used it years ago it didnt like my TurboTax files at all. I just bypassed em in the scans.
Ive sold a few on my site and only one person didnt like it out of a half dozen or so.
I’m yet even more convinced to avoid ESET. US customer pre-sale support was not acceptable. What is of true value with this product to set it apart or even on par with Trend’s CSM for SMB? This is especially true now with Trend’s new Smart Host mail scanning checking mail before it ever reaches the gateway. I realize people want alternatives and this sounded good but the reality is inadequate and seems cludgy.
I changed from Symantec Coporate AntiVirus to Trend CSM 3.5 in February 2007, upgrading to 3.6 in May 2007. Like NOD32, Trend had lots of configuration headaches. But in response to the question about what sets NOD32 apart from Trend CSM, two points come to mind.
The first is overhead. On a desktop, a Trend install is 197MB on disk; NOD32 takes 28MB. The Trend memory footprint on my SBS server (with the Messaging component) was about 330MB–large enough to cause daily alerts about allocated memory. The NOD32 memory footprint (without the Exchange component) is about 43MB, and the alerts have stopped.
The second point was the case two weeks after installating Trend CSM where it identified several email attachments as “possible” worms, then passed them directly to the client desktop. Each one, when submitted to Trend’s automated online analysis, came back immediately as a confirmed threat. Yet the “recommended action” in Trend’s ActiveAction was to pass on these threats to the desktop and leave it up to the user to decide whether they wanted to execute the worm. The failure here in my book was not so much that the worm was new to Trend, but that the default was to pass the suspicious file to the end user. Not exactly a Worry-Free (TM) approach from a system administrator’s perspective!
I decided to do some more testing of Trend Client-Server compared to NOD32. See http://blogs.mcbsys.com/mark/post/Comparing-NOD32-27-to-Trend-Client-Server-36.aspx .
The first is overhead. On a desktop, a Trend install is 197MB on disk; NOD32 takes 28MB. The Trend memory footprint on my SBS server (with the Messaging component) was about 330MB–large enough to cause daily alerts about allocated memory. The NOD32 memory footprint (without the Exchange component) is about 43MB, and the alerts have stopped. thanks
We’re eSET Partners and fin NOD32 v2.7 to be an excellent, tight, fast piece of code. wonderful software.. v3 is OK, but not as tight or fast.. so we often find ourselves downgrading to overcome problems. In all, hightly recommended though.. whether for servers, mailservers or desktops.