Hello Stefan, I've been chatting with Andy on this. He is the engineer who developed the installer. He should be responding shortly about that piece. I will answer some of the other questions...
Monday, August 4, 2008, 8:46:30 AM, you wrote: <snip/> > 2.) Anything I MUST read and understand before upgrading? You probably should (not necessarily must) read this so you will understand the differences: http://www.armresearch.com/support/articles/installation/upgradeHelp.jsp > 3.) What about network traffic generated by V3 compared to V2? > Our (small) company has a DSL-line which is used by > the mailserver exclusively. But it is not a full flat, > so at some point we have to pay traffic. V3 will SYNC every minute with our servers. The session size depends upon how much traffic you are seeing, however in all cases it is fairly small. Our spam trap processor handling about 4000 msg/min at the moment produced about 35K down and 49K up in it's last session. A customer node handling about 430 msg/min at the moment produced about 18.3K down and 24.5K up in it's last session. A customer node handling about 60 msg/min at the moment produced about 3.4K down and 5.8K up during it's last session. That should give you an idea about the extra traffic. If you have been uploading log files then you will not need to do that with the new version. > 4.) What about processor load? Do we need more power to get V3 > running smoothly. V3 typically uses less CPU than V2... Sometimes significantly less depending upon what it has learned. In general the engine is slightly more efficient due to optimizations, and in addition to that it is able to "truncate" the scanning process on between 10% and 50% of messages based on learned IP statistics. The new version also uses less CPU and I/O because jobs are coordinated via a local TCP connection instead of job files on disk. The new version is also fully multi-threaded so it's work can be spread among the physical & virtual CPUs in your system. > 5.) Anything important I forgot to ask? > I'd like to know the answer to that, too ;-) I don't think so. If you have gateways or other message processing systems in front of SNF you will want to be sure to tell GBUdb about them so that they can be skipped when SNF is determining the source IP for the message. The rest I think you covered. Best, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. ############################################################# This message is sent to you because you are subscribed to the mailing list <sniffer@sortmonster.com>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
