On Thu, 5 Aug 2004 16:15:53 -0701, Jacob Meuser <[EMAIL PROTECTED]> wrote: > On Thu, Aug 05, 2004 at 03:55:52PM -0700, larry price wrote:
> > I would be curious to see the difference in performance between the > > hardened gentoo and a plain vanilla install that's been secured to > > adequate standards (no xinetd running wideopen, a standard firewall, > > smtpd basics etc.). > > There are immense differences. The hardened stuff is a whole other > level of security. It's still important to use firewalls and basic > hardening techniques along with the kernel and ld.so enhancements. > Yes, one would expect a hit, but it's not a necessary hit in every case after all the speed of an algorithm is not necessarily coupled with it's security. > > What would be the variables that could be tested that would tell you > > something worthwhile? > > > > partial list: > > 1. read/write speed (also open, close, and sync) > > Heh, 2^10 small reads and writes, then pull the plug. How long did the > reads and writes take, and did the filesystem get corrupted. > Or N reads/writes/close on /mnt/tmp; umount /mnt/tmp; mount /mnt/tmp; check files > > 2. speed to respond to a network request ( how many requests/second > > before failure) > > what kind of "network request"? > apache serving a standard page? echo request.; chargen ? > > 3. speed of opening network sockets ( how many open, write, close > > cycles in a given t) > > would require "native" code for each platform. > I would think a perl or python script, or a posix-compliant C program would work, this would be more in the nature of testing "real world performance" so a scripting language would actually be a good measure of likely performance. > > 4. speed of performing a standard numeric benchmark > > standard in what sense? well there is the LINPACK benchmark, or the calculation of a set number of digits of pi > > > 5. fork and exec benchmark (how fast, how many, privilege checking) > > would require "native" code for each platform. > see #3 above > > Of course to be at all meaningful all other variable would need to be > > constrained... > > Well, for starters, we'd need each OS to have dedicated disks, all > identical. We couldn't just install them all on the same disk, as > position on the disk would skew disk access times. > > > It would be somewhat interesting way to compare OS's > > if we could count on having a standard reference box available > > it might be a good clinic project. > > It would be a fun and teaching challenge. It would probably be > expensive to do it "Really Right" though. > well, I'll ask around and see if we can get OPN to loan us a low-end box and just do one OS a week for several weeks, on the premise that actually hitting the limits of a slower older box will tell us more about the overhead imposed by the OS. Just went to set up a wiki page to edit benchmark, but wiki is gone, oh well. _______________________________________________ EUGLUG mailing list [EMAIL PROTECTED] http://www.euglug.org/mailman/listinfo/euglug
