hotfixes for 1481, take one: reduce peer count scaling

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi,

I prepared an emergency fix because some of our users with the biggest
bandwidth report big problems with CPU load. They report that the update
from 1480 to 1481 increased their CPU load by factor 2 to factor
3. Since in the merge from master to merge we kept the min bandwidth
requirements of 10kB/s, the lowest peer count will be 4, which still
suffices for scaling (as shown by the link length fix).

Risk: Users might complain that their target peers are reduced, because
they don=E2=80=99t understand that this change does not reduce the bandwidth
they can use (because the bandwidth per peer is increased if the
peer-count decreases network-wide, and caching should actually become
more effective, countering potential problems due to longer paths).

Please comment on the pull-request:

https://github.com/freenet/fred/pull/646

I=E2=80=99d like to get this into testing tomorrow, since I won=E2=80=99t h=
ave lots of
time during the week.

(actually I=E2=80=99d prefer to release this tomorrow to see over the next =
week
whether it suffices to improve the user experience again)


As fallback, here=E2=80=99s the diff:

diff --git a/src/freenet/node/OpennetManager.java b/src/freenet/node/Openne=
tManager.java
=2D-- a/src/freenet/node/OpennetManager.java
+++ b/src/freenet/node/OpennetManager.java
@@ -190,12 +190,16 @@ public class OpennetManager {
 	/** Enable scaling of peers with bandwidth? */
 	public static final boolean ENABLE_PEERS_PER_KB_OUTPUT =3D true;
 	/** Constant for scaling peers: we multiply bandwidth in kB/sec by this
=2D	 * and then take the square root. scaling at 4 gives 4 peers at 5K,
=2D	 * 5 at 7K, 6 at 10K, 9 at 20K, 11 at
=2D	 * 30K, 15 at 60K, 20 at 100K, 24 at 140K, 100 at 2500K.
=2D	 * 122 at 30mbit/s (the mean upload in Japan in 2014) and
=2D	 * 210 at 88mbit/s (the mean upload in Hong Kong in 2014).*/
=2D	public static final double SCALING_CONSTANT =3D 4.0;
+	 * and then take the square root. Minimum is MIN_PEERs_FOR_SCALING.
+     *=20
+     * (define (peers kbps) (sqrt (* kbps scaling)))
+     *=20
+     * Scaling at 2.5 gives 4 peers at 5K (min peers),
+	 * 4 at 7K, 4 at 10K, 6 at 20K, 7 at 30K, 10 at 60K,=20
+     * 13 at 100K, 15 at 140K, 63 at 2500K.
+	 * 78 at 30mbit/s (the mean upload in Japan in 2014) and
+	 * 133 at 88mbit/s (the mean upload in Hong Kong in 2014).*/
+	public static final double SCALING_CONSTANT =3D 1.61803; // for Euclid an=
d Pythagoras!
 	/**
 	 * Minimum number of peers. As a rough estimate, because the vast majority
 	 * of requests complete in 5 hops, 10 peers give just one binary decision
diff --git a/src/freenet/node/UIDTag.java b/src/freenet/node/UIDTag.java
=2D-- a/src/freenet/node/UIDTag.java
+++ b/src/freenet/node/UIDTag.java
@@ -158,13 +158,18 @@ public abstract class UIDTag {
 	 * @param next The node we are no longer routing to.
 	 */
 	public void removeRoutingTo(PeerNode next) {
=2D		if(logMINOR)
+		if(logMINOR) {
 			Logger.minor(this, "No longer routing to "+next+" on "+this, new Except=
ion("debug"));
+		}
 		boolean noRecordUnlock;
 		synchronized(this) {
=2D			if(currentlyRoutingTo =3D=3D null) return;
+			if(currentlyRoutingTo =3D=3D null) {
+				return;
+			}
 			if(!currentlyRoutingTo.remove(next)) {
=2D				Logger.warning(this, "Removing wrong node or removing twice? on "+th=
is+" : "+next, new Exception("debug"));
+				if(logMINOR) {
+					Logger.minor(this, "Removing wrong node or removing twice? on "+this+=
" : "+next, new Exception("debug"));
+				}
 			}
 			if(handlingTimeouts !=3D null) {
 				handlingTimeouts.remove(next);
@@ -172,7 +177,9 @@ public abstract class UIDTag {
 			if(!mustUnlock()) return;
 			noRecordUnlock =3D this.noRecordUnlock;
 		}
=2D		if(logMINOR) Logger.minor(this, "Unlocking "+this);
+		if(logMINOR) {
+			Logger.minor(this, "Unlocking "+this);
+		}
 		innerUnlock(noRecordUnlock);
 	}
=20=09


Best wishes,
Arne
=2D-
Unpolitisch sein
hei=C3=9Ft politisch sein
ohne es zu merken

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE801qEjXQSQPNItXAE++NRSQDw+sFAlvnU/MACgkQE++NRSQD
w+v94g//ZMANPTuaNtYiNx81xN0z704gU2fDBrqR5n1kSEZr9rMXdL8KntLv2UZ0
4+dMO7KXCxk0fYCgMw+hpAHLVCPQ018EUOaTrlyJPe+72/BryBqJCYJ7/bJjkDim
dLXNOsnPzr0LUy1hReuriU2h3AtKnPwxYZC0pklEbvxCYvYfUwwtwPfxKTninzuV
b2eU4HXHGHbuzKm0DWs1pUZ8VBifTA5ODGlT98hiiiTQ0FIgQ8idZanknnlF0Ns0
21cxCOLp3Un2JdIoi3aYj4mUwu0+DFfxDy++8HSnoZiDPDqLnAslBCYKwkevhT0R
QFnpPk0NlydR++J7A9s/MeE2gwklyT+BAnJHPqQggiAuXyUSsF7V72zz0Jh4q+76
/diHyf2l8AQ2iAtB52uUQx2u65PKYEpWG+TF95BGTp3RGBVh2g63PAxMlnMxqGCO
27WlyLEuqIeWrlvTD4kCNotL+6cbIvRIoZ8qYUSuY/5N+t7OoJMO5NsvhIdIN+53
i5DrL5Z8ytSo668CQzOAZhECDk9ZqK8W/vzVLlZrl7Ai0O/kb16RNKI48oqpGE/1
4uJW817vyYsBQNSSJQY7DJTbGBxhXvesSDKKGcKx2TWElEYu/oamc5RwOFR6xflu
oBgfbUPO8ORYTZZT7FWFu1DwrcLq0rMHjTae7NFZi8lxuPetfG2IswQBAQgAHRYh
BN0ovebZh1yrzkqLHdzPDbMLwQVIBQJb51PzAAoJENzPDbMLwQVIA9cD/ileI88B
d8+YIfESYoRqYHD2OygM44T15U2EaGTf9BkwKK99j4SozkWrhmUpnLH33jSHWAGy
TEpbM4fyEyEslRb4xhwexsuwN8zPBbR77WL/okuamOl5TVaaW7F2g20IzeACUEaQ
sZGSbNgAFtB1OAESrBvluOaL7Zq3Q/WYuipg
=yYxo
-----END PGP SIGNATURE-----
--=-=-=--