Messages in this thread |  | | Date | Mon, 11 Sep 2000 14:58:25 -0700 (PDT) | From | "David A. Gatwood" <> | Subject | Re: [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: 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. It sounds like the BK server was a much more powerful machine.
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 bitmover.com'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. :-)
Later, David
--------------------------------------------------------------------- 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |