Could we add an "impossible" level to the logger? It will be of lesser
priority than the Error level and will be used to log things that are
impossible to happen or at least we think they are impossible
___
devl mailing list
[EMAIL PROTECTED]
http://h
> Unless I'm mistaken, you want c=a/m, which will range from 0 (if there
> is only 1 key, perfect clustering) to 1 (no clustering). Using m/a
> gives you a number from 1 to +infinity.
True.
Ian.
--
Ian Clarke [EMAIL PROTECTED]
Coordinator, The F
Ian Clarke ([EMAIL PROTECTED]) wrote:
> Basically, we get all of the distances between the keys (assuming that
> they are in ascending order), and take the average, call it 'a'.
>
> The maximum possible value for this average, call it 'm', will be if the
> keys are evenly dispersed,
> Now, if w
Ian Clarke ([EMAIL PROTECTED]) wrote:
> ISOs are often quite compressable - you might want to try that.
I wouldn't expect an ISO of a Linux distribution to be compressible.
It's going to contain mostly RPMs (in this case), which are already
compressed. (Aren't they? I'm pretty sure they are. I
On Sun, Apr 06, 2003 at 12:52:43AM +0100, Matthew Toseland wrote:
> On Sat, Apr 05, 2003 at 05:42:32PM -0600, [EMAIL PROTECTED] wrote:
> > Yes, anything done via sysctl is a system time, this means all I/O,
> > scheduling, etc.
>
> I don't think it is scheduling. I have since seen it show 21,000
I was investigating why the RT generation is so slow, and I think it
might be due to the inefficiency of the getSnapshot() method in
CPAlgoRoutingTable. In particular the use of Key.toString() and then
endsWith() to determine whether they keys are valid, and the
!keys.contains(..) condition co
I have found a way to measure key clustering in the RT.
Basically, we get all of the distances between the keys (assuming that
they are in ascending order), and take the average, call it 'a'.
The maximum possible value for this average, call it 'm', will be if the
keys are evenly dispersed, but
> I have them, but inserting 3.4GB is going to take a while. I will post
> the CHKs here when I'm done.
ISOs are often quite compressable - you might want to try that.
Ian.
--
Ian Clarke [EMAIL PROTECTED]
Coordinator, The Freenet Project
On Sat, Apr 05, 2003 at 05:42:32PM -0600, [EMAIL PROTECTED] wrote:
> Yes, anything done via sysctl is a system time, this means all I/O,
> scheduling, etc.
I don't think it is scheduling. I have since seen it show 21,000 context
switches per second and only 33% of cpu time in system. And it doesn
Yes, anything done via sysctl is a system time, this means all I/O,
scheduling, etc.
Scott
On Sat, Apr 05, 2003 at 11:31:05PM +0100, Matthew Toseland wrote:
> I run two freenet nodes, one of which is moderately heavily loaded, on
> an Athlon XP 1700+ attached to a cablemodem. They domina
I run two freenet nodes, one of which is moderately heavily loaded, on
an Athlon XP 1700+ attached to a cablemodem. They dominate my loadavg.
Recently I have noticed that I am having extremely high "system" % in
"top". I checked it out... first, DMA wasn't working, but that is fixed
now. Then I hea
Ian Clarke wrote:
If so, could you upload them to Freenet? I have had numerous requests
from people who are disappointed by the slow speeds of BitTorrent and
the small number of mirrors where it is currently available.
Making them available on Freenet would be a good demonstration of
Freenet'
If so, could you upload them to Freenet? I have had numerous requests
from people who are disappointed by the slow speeds of BitTorrent and
the small number of mirrors where it is currently available.
Making them available on Freenet would be a good demonstration of
Freenet's viability for lar
> > what about basic pcache not on "first response time" (latency) but on
"transfer speed" (ticker started when key is requested and stopped when the
last byte of
> > the requested key is tranferred, resulting into a bytes/sec value, just
like on the splitfile information pane) ?
> > in fact, ever
On Sat, 2003-04-05 at 03:58, [EMAIL PROTECTED] wrote:
> >This is a great idea, but I see one problem. What if a malicious node
> >just responds quickly but "trickles" the data at something like 10
> >bytes/minute? Should transfer speed also be taken into consideration
> >with this algorithm? I c
>This is a great idea, but I see one problem. What if a malicious node
>just responds quickly but "trickles" the data at something like 10
>bytes/minute? Should transfer speed also be taken into consideration
>with this algorithm? I could see a node serving up dozens of
>connections over a dialu
16 matches
Mail list logo
