Date: Wed, 21 Jul 1999 10:39:11 -0400 From: "Kelly Yancey" <kbyanc@alcnet.com> To: "Peter Jeremy" <jeremyp@gsmx07.alcatel.com.au> Cc: <freebsd-hackers@freebsd.org> Message-ID: <002601bed386$cbc33940$291c453f@kbyanc.alcnet.com>
next in thread | raw e-mail | index | archive | help
> From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au>
>
> "Leif Neland" <leifn@neland.dk> 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 <dillon@apollo.backplane.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002601bed386$cbc33940$291c453f>