From owner-freebsd-hackers Wed Jul 21 7:28: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kronos.alcnet.com (kronos.alcnet.com [63.69.28.22]) by hub.freebsd.org (Postfix) with ESMTP id 553AF14DB1 for ; Wed, 21 Jul 1999 07:27:53 -0700 (PDT) (envelope-from kbyanc@alcnet.com) X-Provider: ALC Communications, Inc. http://www.alcnet.com/ Received: from kbyanc (ws-41.alcnet.com [63.69.28.41]) by kronos.alcnet.com (8.9.3/8.9.3/antispam) with SMTP id KAA78151; Wed, 21 Jul 1999 10:42:40 -0400 (EDT) From: "Kelly Yancey" To: "Peter Jeremy" Cc: Subject: Date: Wed, 21 Jul 1999 10:39:11 -0400 Message-ID: <002601bed386$cbc33940$291c453f@kbyanc.alcnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: Peter Jeremy > > "Leif Neland" wrote: > >My 60MHz Pentium, FreeBSD > > > >time file /usr/home/leif/vnc-3.3.2r > >/usr/home/leif/vnc-3.3.2r3_unixsrc.tgz: gzip compressed data, deflated, > >original filename, last modified: Thu Jan 21 19:23:21 1999 > > > >real 0m1.237s > >user 0m0.758s > >sys 0m0.394s > > I can't believe these figures. > > Matthew Dillon wrote: > > Someone would have to compare file sources or profile it to figure > > out what is causing the slowness. > > I can't reproduce the complaint using a 64MB PII-266 running -CURRENT - > there's no evidence of lack of speed, and profiling file(1) doesn't > show any anomolies. > > It is somewhat slower on my 8MB 386, but not unreasonably so: > pc0640% time file src/Z/dhcp-2.0b1pl26.tar.gz > src/Z/dhcp-2.0b1pl26.tar.gz: gzip compressed data, deflated, last > modified: Thu Jan 1 10:00:00 1970, os: Unix > file src/Z/dhcp-2.0b1pl26.tar.gz 1.96s user 0.83s system 98% cpu 2.823 > total > pc0640% > > Note that this is somewhat more than twice the time Leif claimed for > his P-60 - and a P-60 should be more than twice the speed of a > 386SX-25. > > Unfortunately, I can't profile it on my 386: It's running 2.x and I > deleted the profiling libraries due to lack of space. It will happily > run the profiled ELF file(1), but doesn't generate any timing data. > > Looking at ktrace with MALLOC_OPTIONS=U, it does do a lot of > realloc()ing (once for every 20 active lines in .../magic) and sbrk()s > to a maximum size of ~390KB - not really significant. > > All I can think of is that Leif has a problem with his P-60 system. Alright, I'll bite this too: First of all, we are all making the same benchmark? For example, the first time I run: $ time file pm_3.5.3_BSDOS_2.0.tar.Z pm_3.5.3_BSDOS_2.0.tar.Z: compress'd data 16 bits real 0m0.162s user 0m1.086s sys 0m0.060s I get much higher times than when I issue the same a command a second (or more) time: $ time file pm_3.5.3_BSDOS_2.0.tar.Z pm_3.5.3_BSDOS_2.0.tar.Z: compress'd data 16 bits real 0m0.144s user 0m0.090s sys 0m0.053s Presumably the difference come from the first invokation loading all the pages from the magic file into cache which gives the lower numbers on subsequent invokations. I just wanted to make sure before we start pointing fingers. Secondly, to compare with linux (as the original poster did): On FreeBSD 3.2-STABLE from May 18th: $ /usr/bin/time -l file radius_2.0.1_BSDOS_2.0.tar radius_2.0.1_BSDOS_2.0.tar: tar archive 0.14 real 0.09 user 0.04 sys 1140 maximum resident set size 20 average shared memory size 593 average unshared data size 135 average unshared stack size 1411 page reclaims 0 page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 0 voluntary context switches 2 involuntary context switches And from a RedHat Linux 5.2 (kernel 2.0.36) machine configured with identical hardware (albeit different other processes running at the same time): $ /usr/bin/time -v file radius_2.0.1_Linux_2.0.tar radius_2.0.1_Linux_2.0.tar: tar archive Command being timed: "file radius_2.0.1_Linux_2.0.tar" User time (seconds): 0.03 System time (seconds): 0.00 Percent of CPU this job got: 90% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.03 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 0 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 89 Minor (reclaiming a frame) page faults: 169 Voluntary context switches: 0 Involuntary context switches: 0 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 $ /usr/bin/time --portability file radius_2.0.1_Linux_2.0.tar radius_2.0.1_Linux_2.0.tar: tar archive real 0.03 user 0.03 sys 0.01 I find the linux numbers fairly inconsistent between invokations (ie the CPU % fluctuating between 0% and 500%...on a uniprocessor system). The number of faults fluctuated between 2 and about 200 for both "major" and "minor" faults. My favorite is that it reports the process used 0k of memory. :) I can only figure that linux isn't collecting those stats (who really needs to know that anyway :> ) I verified that the inaccurate numbers aren't because of the shortness of the process by using a script to invoke file 100 times...the times were about 100x the values shown, as were the faults, but everything listed as 0 above was still 0. Just FYI: The linux system reports: Mem: 386320K av, 379568K used, 6752K free, 41140K shrd, 5440K buff Swap: 72256K av, 76K used, 72180K free 362108K cached The FreeBSD system reports: Mem: 64M Active, 262M Inact, 31M Wired, 14M Cache, 5222K Buf, 5736K Free Swap: 768M Total, 768M Free I really can't make heads or tails out of all of this, but I'm hoping that I've provided some information to people who could use it. Kelly ~kbyanc@posi.net~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message