FloodfillMonitorJob:

- Use lifetime average value for job lag
 - Change the job lag limit to less than 25ms
 - Consider and set the limit of backlogged tunnels to less than 5
This commit is contained in:
dg2-new
2015-02-15 22:40:36 +00:00
parent 9163d41228
commit f87d006a1c
3 changed files with 12 additions and 3 deletions

View File

@ -1,3 +1,9 @@
2015-02-15 dg
* FloodfillMonitorJob:
- Use lifetime average value for job lag
- Change the job lag limit to less than 25ms
- Consider and set the limit of backlogged tunnels to less than 5
2015-02-10 dg
* I2PSnark, Jetty, SAM, crypto: findbugs resource leaks.

View File

@ -18,7 +18,7 @@ public class RouterVersion {
/** deprecated */
public final static String ID = "Monotone";
public final static String VERSION = CoreVersion.VERSION;
public final static long BUILD = 23;
public final static long BUILD = 24;
/** for example "-test" */
public final static String EXTRA = "";

View File

@ -150,8 +150,11 @@ class FloodfillMonitorJob extends JobImpl {
int good = ffcount - failcount;
boolean happy = getContext().router().getRouterInfo().getCapabilities().indexOf("R") >= 0;
// TODO - limit may still be too high
// TODO - use jobQueue.jobLag stat instead?
happy = happy && getContext().jobQueue().getMaxLag() < 100;
// For reference, the avg lifetime job lag on my Pi is 6.
// Would per-hour or per-day be better than lifetime avg? A reference to avg. dropped ff jobs maybe?
RateStat lagStat = getContext().statManager().getRate("jobQueue.jobLag");
happy = happy && lagStat.getLifetimeAverageValue() < 25;
happy = happy && getContext().tunnelManager().getInboundBuildQueueSize() < 5;
// Only if we're pretty well integrated...
happy = happy && _facade.getKnownRouters() >= 200;
happy = happy && getContext().commSystem().countActivePeers() >= 50;