On Mon, Sep 11, 2000 at 02:58:25PM -0700, David A. Gatwood wrote:
> > On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote:
> > > > Err, "faster"? The following is the moral equiv of 4 kernel updates
> > > > which had nothing to do using BitKeeper instead of CVS. The local copy
> > > > was in San Francisco and the remote copy is Cort's machine in New Mexico
> > > > over a 384Kbits/sec link. All 4 updates in 5 seconds. Anyone have a
> > > > CVS tree they can try to get comparable numbers?
> > >
> > > Try: http://innominate.org/~tgr/projects/lksr/
> >
> > Thanks, that was helpful. Comparison numbers for a null update of the
> > 2.3 kernel, which means you update and then update again, timing the
> > second update to get some idea of the system's best case throughput,
> > are:
> >
> > CVS: 139.5 seconds
> > BK: 1.6 seconds
> >
> > The BK tree is the 2.3 kernel tree maintained by FSMlabs.
>
> All right, this is ridiculous. Those statistics are worthless. The BK
> tree was on a horribly fast network and the CVS repository was on a
> horribly slow one. There's just no way that BK is that much faster than
> CVS in a comparable environment.
>
> I'm sorry, but I can't believe those numbers. It takes longer than 1.6
> seconds to stat all the kernel directories unless the BK machine has a
> huge disk cache.
Calm down, David. BK really is pretty fast. Here's a point by point
rebuttal to your mail.
First of all, I don't think you read the mail. Let me quote:
> > > > over a 384Kbits/sec link.
That's a 48Kbyte/sec link. Hardly a "horribly fast network". In fact,
the bandwidth to FSMlabs.com and innominate.org seems to be identical,
I suspect that my link is the bottleneck, not either of theirs.
In order for the link to be the reason for the performance difference,
innominate.org would need to be a .9Kbyte/second link. I kinda doubt
that seeing as a 128MB cvs checkout took 23 minutes (works out to around
90Kbyte/sec uncompressed, so cvs must compress it, so I'd guesstimate
they have around a 30Kbyte/sec link or so).
Second of all, if you ask around, you'll find that I'm a performance guy
more than anything and that I'm not given to skewing the numbers and *if*
that was your point, I resent the implication.
Third, BK is designed to be that much faster. It's inherent in the
nature of a distributed repositories with changesets. I can, and did,
reboot the machine, did the test again, and it took an average of 1.56
seconds per tree to do a null pull.
Fourth, non-null pulls are similarly faster, again, by design. BK only
moves the data it needs to move. That means if you have a 100GB file
in which you have changed one byte, BK will move on the order of 1 byte
to update that file. And that's it - it doesn't compare the two files,
or read the two files, or in any way look at the two files to figure out
that they need to be updated. It knows. That's a benefit of having
changesets, I only need to compare the ChangeSet file to know that 4 files
were updated 2 were moved, and 5 were created, then I move those *portions*
of those files across the wire. Other than the initial repository create
(aka cvs checkout), BK *never* moves an entire file across the wire.
Never means never and includes the process of deciding what to do. CVS
moves whole files just to discover there is nothing to do.
-- --- Larry McVoy lm@bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:16 EST