lkml.org 
[lkml]   [2000]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ANNOUNCE] Darkstar Development Project
On Mon, 11 Sep 2000, Larry McVoy wrote:

> That's a 48Kbyte/sec link. Hardly a "horribly fast network". In fact,

I meant FSMlabs, but yeah. ;-)


> 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.

No, wasn't my point. Sorry if it came out that way. My point was for
anyone reading not to jump to conclusions based on just those numbers, and
that I'd like to see some real-world tests on comparable systems.


> 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.

This is an interesting point. As far as changes are concerned, it should
have lower network utilization. However, in effect, it does compare the
files. It compared the file when you checked it into your local
repository. It's just shifting the burden of the comparison to a local
repository instead of doing it over the network. Faster, yes, but it
still does the same thing, just in a different way that uses less
bandwidth.


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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [from the cache]
©2003-2011 Jasper Spaans