o reduce the incoming load, WITHOUT these things. The simplest
implementation of this concept is to send non-local RejectedOverload's when we
are *close* to the limits, not only local ones when we are *at* the limits
(which are then relayed as non-local); in other words, to send a slow down
message *before* it's too late.
>
> I am touched by your faith in "theoreticians", but I have a feeling we're in
> uncharted territory here. We need to agree on an approach that is simple
> enough to reason about, and then build a simulation for it. I think the
> simulation should just be a few days of work, we're not talking years here,
> hopefully not even months.
Weeks probably - and simulations themselves tend to have tunables. Anyway if I
start writing simulations people get mad because I'm not fixing bugs.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20110829/975bb061/attachment.pgp>
of bandwidth (too little slots) massively slows down NLM.
> the transfer times should actually be dominant
> though they are lower than the queue time.
> and freenet should get faster with faster network or lower chunk
> sizes.
> toad_: so first step: make sure all bandwidth gets used - maybe by
> allocating more slots till about 2? the current number are transferring
> -*- ArneBab is happy
> cool, lot's of stuff to read tomorrow morning. :)
> NLM should with the current network be slower than OLM by 23%. But
> in 18 month it should actually be faster by ~8%, given Moores Law holds for
> upload bandwidth.
> :)
> with faster I mean time to complete a request.
> reaction time ? latency
> digger3: maybe you can doublecheck the reasoning
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20110829/7d766e77/attachment.pgp>
ent was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20110829/37cfcada/attachment.pgp>
me, not by reported load.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20110829/0761719f/attachment.pgp>
rt --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20110829/c06395ac/attachment.pgp>
for routing accuracy (as
> > visible in success rates), and we can ensure that the input load is low
> > enough to avoid severe slowdown due to queueing for a long time.
>
> No, I think we need to avoid queueing except in case of emergency. Queueing
> only makes things worse by tying up more resources for longer.
I have the same attitude to misrouting.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20110829/0394eae5/attachment.pgp>
that queueing times are kept very low on average.
(Culmination of a long conversation where ArneBab was arguing I shouldn't give
up on NLM, see logs)
[18:37:55] ArneBab: i think we might be able to keep NLM
[18:38:32] mainly using queueing as a way to smooth out the fact that
the inter-request interval is quite long, so there's a good chance there isn't
a free slot immediately when a request arrives
[18:38:50] ArneBab: we will need to combine it with some sort of
early-slow-down-signal mechanism though
[18:38:55] ArneBab: see my latest reply to ian on devl
[18:39:17] yes
[18:39:33] okay, so we are on roughly the same page
[18:40:34] jupp
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20110829/aff20b05/attachment.pgp>
clear benefits for routing accuracy (as visible in success rates),
and we can ensure that the input load is low enough to avoid severe slowdown
due to queueing for a long time.
>
> Ian.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20110829/b007f4b4/attachment.pgp>
The project's current state is reflected in a dollar amount of remaining
project funds, along with an estimate of how much additional development time
it corresponds to. This amount will decrease suddenly and significantly when a
payment is made. It's not - at least supposed to be - a secret that t
___
> Devl mailing list
> Devl at freenetproject.org
> http://freenetproject.org/cgi-bin/mailman/listinfo/devl
>
--
Ian Clarke
Personal blog: http://blog.locut.us/
-- next part --
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20110829/79bd2904/attachment.html>
On Monday 29 Aug 2011 18:58:26 Ian Clarke wrote:
> On Mon, Aug 29, 2011 at 12:37 PM, Matthew Toseland <
> t...@amphibian.dyndns.org> wrote:
> > Misrouting is unacceptable, in general. Extremely overloaded or extremely
> > low capacity nodes may be routed around. We might even allow some bounded
>
Von: "Matthew Toseland"
>But the other question is, can queueing ever be helpful? It can if it allows
>us to route more accurately (which NLM clearly does), and/or to run enough
>requests in parallel that the longer time taken for the request to reach its
>destination is offset. Is this cond
On Tuesday 30 Aug 2011 00:18:35 Matthew Toseland wrote:
> On Tuesday 30 Aug 2011 00:08:16 Arne Babenhauserheide wrote:
> > After discussing and going deeper into this, it became apparent that the
> > problem is not overload of queues. I’ll repeat the result I came to here
> > (and
> > not in cha
On Tuesday 30 Aug 2011 00:08:16 Arne Babenhauserheide wrote:
> After discussing and going deeper into this, it became apparent that the
> problem is not overload of queues. I’ll repeat the result I came to here (and
> not in chatlog form :) ):
>
> The problem is in the load limiter:
>
>
> 1)
After discussing and going deeper into this, it became apparent that the
problem is not overload of queues. I’ll repeat the result I came to here (and
not in chatlog form :) ):
The problem is in the load limiter:
1) we need to use all bandwidth, because latency depends on the number of
f
These are good ideas Steve, I must confess that I've been a little
distracted lately - and we do definitely need to get our act together on
funding. Matthew, what is our current "drop-dead" date as best as you can
estimate it?
Ian.
On Mon, Aug 29, 2011 at 4:18 PM, Steve Dougherty wrote:
> The p
On Monday 29 Aug 2011 20:32:13 Ian Clarke wrote:
> On Mon, Aug 29, 2011 at 2:09 PM, Matthew Toseland > wrote:
>
> > On Monday 29 Aug 2011 19:28:50 Ian Clarke wrote:
> > > Ok, thinking about it, here is a proposal, or rather, the beginning of a
> > > proposal. I'm assuming that we get rid of NLM
? Perhaps you are right though, but this is
the kind of thought-process we need.
Ian.
--
Ian Clarke
Founder, The Freenet Project
Email: ian at freenetproject.org
-- next part --
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20110829/32287d0b/attachment.html>
decade, leaving us
pretty-much where we were in 2003. No, we don't understand how the current
system works, there is no point in trying to fix something when we don't
even know what is broken.
I am touched by your faith in "theoreticians", but I have a feeling we're in
uncharted territory here. We need to agree on an approach that is simple
enough to reason about, and then build a simulation for it. I think the
simulation should just be a few days of work, we're not talking years here,
hopefully not even months.
Ian.
--
Ian Clarke
Founder, The Freenet Project
Email: ian at freenetproject.org
-- next part --
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20110829/caeca808/attachment.html>
Okay, I don't understand most of that, I might be able to check the math if it
was written properly, but it looks difficult. However, as far as I can see:
- The most obvious way to increase bandwidth usage would be to increase the
timeout time for output bandwidth liability (and at the same time
The project's current state is reflected in a dollar amount of remaining
project funds, along with an estimate of how much additional development time
it corresponds to. This amount will decrease suddenly and significantly when a
payment is made. It's not - at least supposed to be - a secret that t
eally with a theoretical rather than
experimental foundation).
Ian.
--
Ian Clarke
Founder, The Freenet Project
Email: ian at freenetproject.org
-- next part --
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/2011
Am Montag, 29. August 2011, 14:32:13 schrieb Ian Clarke:
> Yes, small tweaks have worked so well for us for the last decade, leaving us
> pretty-much where we were in 2003. No, we don't understand how the current
> system works, there is no point in trying to fix something when we don't
> even kno
re slowdown due to queueing for a long time.
>
No, I think we need to avoid queueing except in case of emergency. Queueing
only makes things worse by tying up more resources for longer.
Ian.
--
Ian Clarke
Founder, The Freenet Project
Email: ian at freenetproject.org
-- next part --
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20110829/1d8153cd/attachment.html>
On Mon, Aug 29, 2011 at 2:21 PM, Matthew Toseland wrote:
> > >- What is the average load reported by responses this node
> forwarded, per
> > >remote node
> >
> > Ahhh, this one could be interesting - you could use it to penalise nodes
> which spam excessively.
>
> Actually, thinking abo
On Mon, Aug 29, 2011 at 2:09 PM, Matthew Toseland wrote:
> On Monday 29 Aug 2011 19:28:50 Ian Clarke wrote:
> > Ok, thinking about it, here is a proposal, or rather, the beginning of a
> > proposal. I'm assuming that we get rid of NLM, fair sharing, and
> anything
> > else intended to control l
On Monday 29 Aug 2011 20:09:58 Matthew Toseland wrote:
> On Monday 29 Aug 2011 19:28:50 Ian Clarke wrote:
> > Ok, thinking about it, here is a proposal, or rather, the beginning of a
> > proposal. I'm assuming that we get rid of NLM, fair sharing, and anything
> > else intended to control load, a
On Monday 29 Aug 2011 19:28:50 Ian Clarke wrote:
> Ok, thinking about it, here is a proposal, or rather, the beginning of a
> proposal. I'm assuming that we get rid of NLM, fair sharing, and anything
> else intended to control load, and replace it with this. We will absolutely
> need to simulate
On Monday 29 Aug 2011 18:58:26 Ian Clarke wrote:
> On Mon, Aug 29, 2011 at 12:37 PM, Matthew Toseland <
> t...@amphibian.dyndns.org> wrote:
>
> > That is because we do not have the time or funding to empirically test
> > hypotheses. We don't gather enough data, we don't have a huge testnet to try
Ok, thinking about it, here is a proposal, or rather, the beginning of a
proposal. I'm assuming that we get rid of NLM, fair sharing, and anything
else intended to control load, and replace it with this. We will absolutely
need to simulate this before we write a single line of code to deploy it.
On Mon, Aug 29, 2011 at 12:37 PM, Matthew Toseland <
t...@amphibian.dyndns.org> wrote:
> That is because we do not have the time or funding to empirically test
> hypotheses. We don't gather enough data, we don't have a huge testnet to try
> stuff on over extended periods, and so on. Most software
On Monday 29 Aug 2011 18:37:39 Matthew Toseland wrote:
> On Saturday 27 Aug 2011 21:35:58 Ian Clarke wrote:
> > Matthew,
> >
> > This makes sense from the perspective of making incremental changes, but I
> > think we need to be more drastic than that. I think we need to go back to
> > the drawing
On Saturday 27 Aug 2011 21:35:58 Ian Clarke wrote:
> Matthew,
>
> This makes sense from the perspective of making incremental changes, but I
> think we need to be more drastic than that. I think we need to go back to
> the drawing board with load management. We need to find a solution that is
>
33 matches
Mail list logo
