Open str4d opened 7 years ago
Trac update at 20140826T09:38:08:
to clarify: not a fixed intervall should be chosen at random, but the concrete time for each individual mail check be chosen randomly (uniform distribution).
Trac update at 20140826T09:50:45: user changed parents from "" to "1359"
Trac update at 20150110T04:16:56:
Trac update at 20150205T04:26:01:
A comment from [ticket:1450 rfree]:
( I offer small tip of 0.01 Bitcoin - so a beer at current prices - for who ever implements this, e.g. from https://blockchain.info/address/152fnfBqRjVMDvRa5LQ2upx9tJAeHnyqHC )
A few details about delay of "cronjobs" - especially the "check email" action: For each account, where T is the configured time of action, e.g. 10 minutes for "check email each 10 minutes": and L option: Sometimes pretend to be offline for up to .... hours to make others confused about when your computer is online.
1) At start, job should delay random(T0 to T2) 2) After running the check, job should schedule next run, to be randomly between time from now sleeptime = random(T0.5 to T1.5) if random(0..100) is < 30 then sleeptime += randomGauss(0 to L/5) if random(0..100) is < 10 then sleeptime += randomGauss(0 to L)
choose the scheduled time: ID.nextrun = now() + sleeptime
It is a good idea to look at the possibility of randomizing other cronjobs, if they are visibly tied to an identity.
Trac update at 20150216T20:14:20:
i'd like the option to manually set the intervall from which to draw the actual wait time randomly. But i also see the convenience of just putting one approximate time. So what about this compromise: for what abouve you call sleeptime, and previously was called checkintervall, either let the user specify an intervall [min,max] in the config files. in the UI, however, just prompt for one value T for check intervall and set min:=T(1-x) and max:=T(1+x). whether x should equal 0.5 or not is up to debate. Then casual user has it easy, and advanced user can adjust it to his likings without recompiling source. This calculation is only performed on saving this very setting from the ui. otherwise it only readys the two values from config and displays the mean average of them. Or always show two values in UI, then it could be average wait time and spread (x). Again default vlaue of x to be determined. unit distribution, not gauss. wrt the above mentioned L feature: I don't desperately need it. but if you do it, nice. should imho be off / set to 0 by default thought, in order not to delay things too much for users that expect some quicker workings. but then rather coose an offline duration and a "timezone" and simply gauß the period
to:
1426365611893046
I'd like the option to manually set the intervall from which to draw the actual {{{waitTime}}} randomly. But I also see the convenience of just putting one approximate time. So what about this compromise: For what above you call sleeptime, and previously was called checkintervall, either let the user specify either an intervall [ {{{min}}},{{{max}}}] or one value {{{checkIntervall}}} for check intervall and a randomization/spread factor {{{factor}}}. Either way, you can transform them. (With user-set {{{min}}} and {{{max}}} values, you obtain {{{factor}}} from {{{factor := (max-min)/(max+min)}}} and {{{checkInterval := (max+min)/2}}} This calculation is only performed on saving this very setting from the ui. Otherwise it only reads the two needed values {{{checkIntervall}}} and {{{factor}}} from the config file.)
For determining the next check time you first obtain two values {{{helpFactor1}}} and {{{helpFactor2}}} of a Gaussian random variable centered around the randomization factor {{{factor}}} independently from one another, set {{{finalMin := (1-helpFactor1)checkInterval}}} and {{{finalMax := (1+helpFactor2)checkInterval}}} (both helpFactors can be discarded now) (Assert that {{{finalMin <= finalMax}}}) Then choose {{{waitTime}}} from a uniform distribution between {{{[finalMin, finalMax]}}}. (both values can be discarded now) Finally, you get the {{{scheduledTime = timeOfLastCheck + waitTime}}}.
This does not yet take the L option rfree mentions into account.
Heck, if you want, you can even provide both options and let the user choose which input method is more intuitive for him, giving the average and a randomization factor, or giving min and max.
And the very same calculations can be used to determine the exact wait time per relay which is sent to the respective Bote relay node.
Default vlaues to be determined.
wrt the above mentioned L feature: I don't desperately need it. but if you do it, nice. Should imho be off / set to 0 by default thought, in order not to delay things too much for users that expect some quicker workings. but then rather choose an offline duration and a "timezone" and simply gauß the period.
to:
1426365706654267
I'd like the option to manually set the intervall from which to draw the actual
waitTime
randomly. But I also see the convenience of just putting one approximate time. So what about this compromise: For what above you call sleeptime, and previously was called checkintervall, either let the user specify either an intervall [min
,max
] or one valuecheckIntervall
for check intervall and a randomization/spread factorfactor
. Either way, you can transform them. (With user-setmin
andmax
values, you obtainfactor
fromfactor := (max-min)/(max+min)
andcheckInterval := (max+min)/2
This calculation is only performed on saving this very setting from the ui. Otherwise it only reads the two needed valuescheckIntervall
andfactor
from the config file.)For determining the next check time you first obtain two values
helpFactor1
andhelpFactor2
of a Gaussian random variable centered around the randomization factorfactor
independently from one another, setfinalMin := (1-helpFactor1/100.0)*checkInterval
andfinalMax := (1+helpFactor2/100.0)*checkInterval
(both helpFactors can be discarded now) (Assert thatfinalMin <= finalMax
) Then choosewaitTime
from a uniform distribution between[finalMin, finalMax]
. (both values can be discarded now) Finally, you get thescheduledTime = timeOfLastCheck + waitTime
.This does not yet take the L option rfree mentions into account.
Heck, if you want, you can even provide both options and let the user choose which input method is more intuitive for him, giving the average and a randomization factor, or giving min and max.
And the very same calculations can be used to determine the exact wait time per relay which is sent to the respective Bote relay node.
Default vlaues to be determined.
wrt the above mentioned L feature: I don't desperately need it. but if you do it, nice. Should imho be off / set to 0 by default thought, in order not to delay things too much for users that expect some quicker workings. but then rather choose an offline duration and a "timezone" and simply gauß the period.
Trac update at 20150216T20:36:48: user commented:
just saw #40, yes, something like that is what I vaguely had in mind. But then the L thing here above is onbsolete, or what is it for? Or is the L independed of timezone just a ramdom "computer switched off"?
Trac update at 20170115T14:08:34:
trivial.
The intervall for automatic mail checking should be taken as a guideline, not as exact time. Rather should the exact checking time be more random, so to add more entropy.
Migrated from https://trac.i2p2.de/ticket/1360