[lkml]   [2000]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ANNOUNCE] Darkstar Development Project
On Mon, 11 Sep 2000, Larry McVoy 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:
> 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. It sounds like the BK server was a much more powerful

Also, the innominate server is WAY out. It took _25_ hops to get to that
server from here. It only took 11 to fsmlabs. Since bitmover is in San
Jose as I am (or at least's server is), I suspect you will
see a similarly dramatic difference in the distance. That's just not a
valid test by any measure.

I'd like someone to do a valid test of these two systems, as I'm curious
myself as to which is faster. A valid test includes the following things:

1. Raw checkout of a full tree
2. Raw checkin of a full tree

and does not include a "null update", as that is an atypical usage pattern
for most trees that unfairly skews the test towards software or kernels
that does caching of file stat results, which has little bearing on
typical use.

Critically, the test should be with two otherwise identically configured
servers and two identically configured clients, across identical networks.
Only then do the tests mean anything. I'd be very curious to see the
results. :-)


A brief Haiku:

Microsoft is bad.
It seems secure at first glance.
Then you read your mail.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.188 / U:15.712 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site