[freenet-dev] Freenet 0.7.5 build 1401

[Arne Babenhauserheide]

Am Donnerstag, 1. September 2011, 17:02:16 schrieb xor:
> On Wednesday 31 August 2011 15:05:59 Matthew Toseland wrote:
> > I believed I had seriously screwed
> > everything up and wasted 6 months' work at the same time;
> 
> Don't be that strict with yourself. Even if the code isn't of much use you
> have at least most likely learned quite a few things from writing it.

I wanted to say something similar. 


Trust in yourself. 


You are the one with the most experience with Freenet, and you made it a 
reality. 

Also I think that NLM is quite good. I reenabled it, and suddenly my uploads 
and downloads are working well again. 

I still think, it just needs finetuning, like OLM did, too. 
(adjusting the bandwidth limiter is fine tuning)

Best wishes and many thanks for your work!
Arne
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Freenet 0.7.5 build 1401

[xor]

On Wednesday 31 August 2011 15:05:59 Matthew Toseland wrote:
> I believed I had seriously screwed
> everything up and wasted 6 months' work at the same time; 

Don't be that strict with yourself. Even if the code isn't of much use you 
have at least most likely learned quite a few things from writing it.

Re: [freenet-dev] Freenet 0.7.5 build 1401

[Arne Babenhauserheide]

Am Donnerstag, 1. September 2011, 17:02:16 schrieb xor:
 On Wednesday 31 August 2011 15:05:59 Matthew Toseland wrote:
  I believed I had seriously screwed
  everything up and wasted 6 months' work at the same time;
 
 Don't be that strict with yourself. Even if the code isn't of much use you
 have at least most likely learned quite a few things from writing it.

I wanted to say something similar. 


Trust in yourself. 


You are the one with the most experience with Freenet, and you made it a 
reality. 

Also I think that NLM is quite good. I reenabled it, and suddenly my uploads 
and downloads are working well again. 

I still think, it just needs finetuning, like OLM did, too. 
(adjusting the bandwidth limiter is fine tuning)

Best wishes and many thanks for your work!
Arne

signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Freenet 0.7.5 build 1401

[Matthew Toseland]

On Monday 29 Aug 2011 02:48:59 Evan Daniel wrote:
> On Fri, Aug 26, 2011 at 11:50 AM, Matthew Toseland
>  wrote:
> > Freenet 0.7.5 build 1401 is now available. Please upgrade, it will be 
> > mandatory at midnight. This build turns off New Load Management, for the 
> > time being. If performance continues to be poor we will know the problem is 
> > elsewhere (it is possible that it is a problem with the asyncGet changes, 
> > although I don't see how). There are also fixes related to dropping peers 
> > due to the one IP per connection setting. You should not normally enable 
> > this setting on darknet (core settings); it can cause your friends to be 
> > lost.
> >
> > Thanks, and sorry for all the problems lately.
> 
> Was it really necessary to have the update be mandatory on such short
> notice? I'm not trying to be sarcastic, this is a serious question and
> I'm curious about your opinion.

There were very serious problems. 1397 enabled NLM across the network, 1398 
turned off AIMDs. While this increased success rates substantially, it also 
dramatically reduced throughput, especially for SSKs. It was necessary to turn 
AIMDs back on (which I now believe is appropriate anyway), and after that 
didn't appear to improve matters significantly, I turned NLM off as well.

Unfortunately, inserts were so slow that 1401 didn't actually start to get 
deployed until *after it was already mandatory*. Which likely caused additional 
problems, scrambling the opennet topology for a while.
> 
> It seems to me that you get most of the impact thanks to the
> auto-updates, which most of the network uses. Some of us, however, do
> not. I can't use the auto-update without it regularly interfering with
> the network size graphs I produce. (Yes, the scripts that run it are
> brittle and sensitive to things like that. Yes, I'd like to throw them
> out and write something better, but motivation to actually do that has
> yet to strike.) So I have to manually perform updates at times when
> they aren't running, and I missed the window on that one. The result
> is wonky network size info that I'm pretty sure is entirely an
> artifact of that, and has no relationship to what the recent
> performance issues have done to network size, which would have been an
> interesting question.
> 
> Anyway, a little more warning would have been nice, but obviously the
> health of the network comes first.
> 
> Is there a policy on what the requirements are for a build to be made
> mandatory at all? And what the warning period should be? If not, it
> seems like something we should have.

Basically this was firefighting. I believed I had seriously screwed everything 
up and wasted 6 months' work at the same time; this also explains the 
discussions about load management.

Generally, IMHO, builds should be mandatory in a week or so if they do anything 
that affects network behaviour. This can be accelerated if we need to try stuff 
out quickly for various reasons. Very short mandatories should only happen when 
something is seriously broken.
-- 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: 

Re: [freenet-dev] Freenet 0.7.5 build 1401

[Matthew Toseland]

On Monday 29 Aug 2011 02:48:59 Evan Daniel wrote:
 On Fri, Aug 26, 2011 at 11:50 AM, Matthew Toseland
 t...@amphibian.dyndns.org wrote:
  Freenet 0.7.5 build 1401 is now available. Please upgrade, it will be 
  mandatory at midnight. This build turns off New Load Management, for the 
  time being. If performance continues to be poor we will know the problem is 
  elsewhere (it is possible that it is a problem with the asyncGet changes, 
  although I don't see how). There are also fixes related to dropping peers 
  due to the one IP per connection setting. You should not normally enable 
  this setting on darknet (core settings); it can cause your friends to be 
  lost.
 
  Thanks, and sorry for all the problems lately.
 
 Was it really necessary to have the update be mandatory on such short
 notice? I'm not trying to be sarcastic, this is a serious question and
 I'm curious about your opinion.

There were very serious problems. 1397 enabled NLM across the network, 1398 
turned off AIMDs. While this increased success rates substantially, it also 
dramatically reduced throughput, especially for SSKs. It was necessary to turn 
AIMDs back on (which I now believe is appropriate anyway), and after that 
didn't appear to improve matters significantly, I turned NLM off as well.

Unfortunately, inserts were so slow that 1401 didn't actually start to get 
deployed until *after it was already mandatory*. Which likely caused additional 
problems, scrambling the opennet topology for a while.
 
 It seems to me that you get most of the impact thanks to the
 auto-updates, which most of the network uses. Some of us, however, do
 not. I can't use the auto-update without it regularly interfering with
 the network size graphs I produce. (Yes, the scripts that run it are
 brittle and sensitive to things like that. Yes, I'd like to throw them
 out and write something better, but motivation to actually do that has
 yet to strike.) So I have to manually perform updates at times when
 they aren't running, and I missed the window on that one. The result
 is wonky network size info that I'm pretty sure is entirely an
 artifact of that, and has no relationship to what the recent
 performance issues have done to network size, which would have been an
 interesting question.
 
 Anyway, a little more warning would have been nice, but obviously the
 health of the network comes first.
 
 Is there a policy on what the requirements are for a build to be made
 mandatory at all? And what the warning period should be? If not, it
 seems like something we should have.

Basically this was firefighting. I believed I had seriously screwed everything 
up and wasted 6 months' work at the same time; this also explains the 
discussions about load management.

Generally, IMHO, builds should be mandatory in a week or so if they do anything 
that affects network behaviour. This can be accelerated if we need to try stuff 
out quickly for various reasons. Very short mandatories should only happen when 
something is seriously broken.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Freenet 0.7.5 build 1401

[Evan Daniel]

On Fri, Aug 26, 2011 at 11:50 AM, Matthew Toseland
 wrote:
> Freenet 0.7.5 build 1401 is now available. Please upgrade, it will be 
> mandatory at midnight. This build turns off New Load Management, for the time 
> being. If performance continues to be poor we will know the problem is 
> elsewhere (it is possible that it is a problem with the asyncGet changes, 
> although I don't see how). There are also fixes related to dropping peers due 
> to the one IP per connection setting. You should not normally enable this 
> setting on darknet (core settings); it can cause your friends to be lost.
>
> Thanks, and sorry for all the problems lately.

Was it really necessary to have the update be mandatory on such short
notice? I'm not trying to be sarcastic, this is a serious question and
I'm curious about your opinion.

It seems to me that you get most of the impact thanks to the
auto-updates, which most of the network uses. Some of us, however, do
not. I can't use the auto-update without it regularly interfering with
the network size graphs I produce. (Yes, the scripts that run it are
brittle and sensitive to things like that. Yes, I'd like to throw them
out and write something better, but motivation to actually do that has
yet to strike.) So I have to manually perform updates at times when
they aren't running, and I missed the window on that one. The result
is wonky network size info that I'm pretty sure is entirely an
artifact of that, and has no relationship to what the recent
performance issues have done to network size, which would have been an
interesting question.

Anyway, a little more warning would have been nice, but obviously the
health of the network comes first.

Is there a policy on what the requirements are for a build to be made
mandatory at all? And what the warning period should be? If not, it
seems like something we should have.

Evan Daniel

Re: [freenet-dev] Freenet 0.7.5 build 1401

[Evan Daniel]

On Fri, Aug 26, 2011 at 11:50 AM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
 Freenet 0.7.5 build 1401 is now available. Please upgrade, it will be 
 mandatory at midnight. This build turns off New Load Management, for the time 
 being. If performance continues to be poor we will know the problem is 
 elsewhere (it is possible that it is a problem with the asyncGet changes, 
 although I don't see how). There are also fixes related to dropping peers due 
 to the one IP per connection setting. You should not normally enable this 
 setting on darknet (core settings); it can cause your friends to be lost.

 Thanks, and sorry for all the problems lately.

Was it really necessary to have the update be mandatory on such short
notice? I'm not trying to be sarcastic, this is a serious question and
I'm curious about your opinion.

It seems to me that you get most of the impact thanks to the
auto-updates, which most of the network uses. Some of us, however, do
not. I can't use the auto-update without it regularly interfering with
the network size graphs I produce. (Yes, the scripts that run it are
brittle and sensitive to things like that. Yes, I'd like to throw them
out and write something better, but motivation to actually do that has
yet to strike.) So I have to manually perform updates at times when
they aren't running, and I missed the window on that one. The result
is wonky network size info that I'm pretty sure is entirely an
artifact of that, and has no relationship to what the recent
performance issues have done to network size, which would have been an
interesting question.

Anyway, a little more warning would have been nice, but obviously the
health of the network comes first.

Is there a policy on what the requirements are for a build to be made
mandatory at all? And what the warning period should be? If not, it
seems like something we should have.

Evan Daniel
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Freenet 0.7.5 build 1401

[Matthew Toseland]

Freenet 0.7.5 build 1401 is now available. Please upgrade, it will be mandatory 
at midnight. This build turns off New Load Management, for the time being. If 
performance continues to be poor we will know the problem is elsewhere (it is 
possible that it is a problem with the asyncGet changes, although I don't see 
how). There are also fixes related to dropping peers due to the one IP per 
connection setting. You should not normally enable this setting on darknet 
(core settings); it can cause your friends to be lost.

Thanks, and sorry for all the problems lately.
-- 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: 

[freenet-dev] Freenet 0.7.5 build 1401

[Matthew Toseland]

Freenet 0.7.5 build 1401 is now available. Please upgrade, it will be mandatory 
at midnight. This build turns off New Load Management, for the time being. If 
performance continues to be poor we will know the problem is elsewhere (it is 
possible that it is a problem with the asyncGet changes, although I don't see 
how). There are also fixes related to dropping peers due to the one IP per 
connection setting. You should not normally enable this setting on darknet 
(core settings); it can cause your friends to be lost.

Thanks, and sorry for all the problems lately.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl