Hi, At the risk of being too abrasive, I'd like to weigh in on the issues of performance characterization I saw during the course of this thread and hope to clear up a potential misunderstanding. I begin by examining an argument presented on CPU utilization and move on to provide what I believe is a _slightly_ more rational approach to capturing a relative performance characterization of the Hurd.
>From Ludovig on his Hurd i386: > I noticed another one two. :) It's actually more a performance issue. For > instance, when unpacking a tarball, "ps aux | head" shows that the ext2fs > server starts consuming most of the CPU time (more than 30% on my 350MHz proc > machine). This happens also whith the pflocal server sometimes. >From Niels on his Linux Sparc station 4: > The numbers depend a lot on the actual hardware, and the relative > speed of the cpu and disks, I think. I just tried extracting > gcc-3.0.4.tar (note, no .gz, unzipping would soak up most of the idle > time). top reported that the tar process consumed about 60% cpu, and > an overall CPU usage of about 10% user, 50% system and 40% idle. >From Thomas Bushnell: > So on the Hurd, you had 30%, and on Linux, you have 60%?=20=20 Hmmm. I don't thing we've accurately characterized the relative performance of the Hurd vs. Linux. There appear to be three problems here. Firstly, %cpu time is an instantaneous rate of cpu consumption which varies widely from time to time depending on sample interval. What we're really interested in, I think, is the integral of %cpu over the lifetime of a process. That is, the amount of time (on behalf of the process both user and system) consumed. In other words, if I take 10% cpu time for 10 seconds, that is roughly equivalent to taking 100% cpu time for 1 second. The amount of system resource required to complete a task of known parameters is the same. Of course, there may be particular scheduling contstraints which make the former more desirable in some circumstances over the latter, but I leave that issue alone for the purposes of discussion. An equivalent metric for disk I/O is the transfer rate. That is, the number of bytes successfully transferred to/from a disk device or filesystem per unit time spent on said transfer. Secondly, the above comparison compares two very _different_ machines with different system parameters. A relative performance characterization of 30% vs 60% is essentially meaningless for capturing the differences between Hurd and Linux performance. Finally, high CPU utilization is usually a GOOD sign during I/O intensive operations because it indicates that the CPU is not spending lots of time waiting on the I/O but is instead being employed to good use. i.e. if the CPU utilization is high this generally indicates that the system is not waiting awfully long for I/O operations to be completed (at least in cache). The system's performance should be gated by the fastest individual component of the system (usually the CPU and front side bus). This is why I initially suggested that some relative (and independently verifiable) performance characterizations be gathered for the Hurd, lest we be fooled into believing that the Emperor is wearing clothes. Such performance data might also ultimately be useful in tracking the progress of the Hurd over time so that we can see what the changes we make are doing in terms of performance of various subsystems (io/network/...). Here's a start at some performance statistics. I suggest that if anyone else is interested in characterizing the system that they begin with downloading bonnie: http://www.textuality.com/bonnie/download.html Run it under the Hurd and Linux (on the same box) and send the results to me. To ensure that the numbers are clear and consistent, please make sure the bonnie program is run with no other applications active on the system (minimize interference from other applications). Also, please include the type, speed and amount of L1 and/or L2 cache present on your system and the type of drive with on-drive cache available (Linux dmesg should show you this). I can then compile the results and present them in a clear and understandable form. I realize that 'bonnie' is not the be-all/end-all of performance characterization tools, but is a better tool to begin with than 'tar' and 'top' in terms of consistency of measurement and use. ---------------------------------------------------------------------- Machine: Compaq Pentium III 850 Mhz 256 Kb L1 cache Under Linux-2.4.17 hdc: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=77545/16/63, UDMA(33) File './Bonnie.1126', size: 104857600 Writing with putc()...done Rewriting...done Writing intelligently...done Reading with getc()...done Reading intelligently...done Seeker 1...Seeker 3...Seeker 2...start 'em...done...done...done... -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 10464 91.5 140505 97.4 141525 99.5 11226 97.7 445682 100.1 21369.7 96.2 Under Hurd-0.2 Transfer mode unknown File './Bonnie.94', size: 104857600 Writing with putc()...done Rewriting...done Writing intelligently...done Reading with getc()...done Reading intelligently...done Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 1164 3.6 1375 1.0 1087 5.6 1508 5.3 3104 3.9 159.5 4.1 After examining the numbers, I think you will join me in appreciating the relative performance differences between the Hurd's ext2fs and Linux's ext2fs implementations. For the sake of completeness, it would be interesting to examine the numbers under FreeBSD and other similar systems. The more numbers we get, the better understanding we will have of the performance of the Hurd relative to other O/S implementations. This may lead ultimately in the direction of altering the implementation to the betterment of the system. Note that I have not yet begun to investigate the (many) reasons for the performance disparity. First of which I would like to attempt to examine is the transfer mode (DMA/UDMA/PIO) that Mach is using. This tends have a tremendous impact on disk throughput leaving filesystem implementation issues aside for the moment. That's all for now. I'll follow up if any conclusions or additional data become available. Jonathan S. Arney Software Engineer [EMAIL PROTECTED] ------------------------------------------------------------------------ Some people call me a nihilist. That would be true except I don't believe in nihilism. ------------------------------------------------------------------------ _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
