> On 10/11/06, Danny Braniss <[EMAIL PROTECTED]> wrote:
> > the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU)
> > dual cpu.
> >
> > running iperf -c (receiving):
> >
> > freebsd-4.100.0-10.0 sec936 MBytes785 Mbits/sec
> > freebsd-5.4 0.0-10.0 sec413 MBytes3
On 10/11/06, Danny Braniss <[EMAIL PROTECTED]> wrote:
the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU)
dual cpu.
running iperf -c (receiving):
freebsd-4.100.0-10.0 sec936 MBytes785 Mbits/sec
freebsd-5.4 0.0-10.0 sec413 MBytes346 Mbits/sec
freebsd.6.1
On Sat, Oct 07, 2006 at 08:53:33PM +0200, [EMAIL PROTECTED] wrote:
> Hello;
>
> FWIW, anyone planning to work in the keyboard or mouse systems is warned to
> look at the KII portions of KGI4BSD first. The main reference is the P4
> repository but there is some documentation here:
> http://wik
Vasil Dimov wrote:
> You (wrongly) assumed that two processed will do slower than a single
> one.
That assumption should be true, in general, at least on a
single-CPU machine. With two processes, there is additional
overhead for data copying through the pipe.
> It's exactly the opposite. Whi
the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU)
dual cpu.
running iperf -c (receiving):
freebsd-4.100.0-10.0 sec936 MBytes785 Mbits/sec
freebsd-5.4 0.0-10.0 sec413 MBytes346 Mbits/sec
freebsd.6.1 0.0-10.0 sec366 MBytes307 Mbits/sec
freebsd-6.
On Wed, Oct 11, 2006 at 11:34:10AM +0200, Oliver Fromme wrote:
> If gzip uses its own code instead of libz, that would
> explain the results of my test, of course. So it seems
> that gzip is 30% faster than libz ... quite significant,
> I think.
No, it isn't. I did benchmarks before importing th
Mike Meyer wrote:
> Not necessarily a known problem, but not a surprise. I'm not sure
> about the size issue - it's not clear what compression level it's
> running at. The real time difference is expected. tar uses libarchive,
> which does the compression in the process. So while piping tar's
On Tue, Oct 10, 2006 at 07:27:53PM +0200, Oliver Fromme wrote:
> Hi,
>
> While doing some performance tuning of a backup script
> I noticed that the -z option of our (bsd)tar behaves in
> a very suboptimal way. It's not only a lot slower than
> using gzip separately, it also compresses worse.
>
Hi
I've tested on 6.1-RELEASE-p5 box these are my results.
I'm wondering why the dragonfly results are so different. What have you
guys done?
Cheers Dale
Run 1
-
%time sh -c "bsdtar -czf test.tgz /usr/src/contrib/gcc"
9 matches
Mail list logo