[mythtv] Ticket #2194: Patch to randomise mythfilldatabase times
William Uther
willu.mailingLists at cse.unsw.edu.au
Fri Sep 15 07:34:40 UTC 2006
Alo,
On 15/09/2006, at 2:55 PM, MythTV wrote:
> #2194: Patch to randomise mythfilldatabase times
> ------------------------------------------------
> +---------------------------
> Reporter: willu.mailingLists at cse.unsw.edu.au | Owner:
> cpinkham
> Type: enhancement | Status: new
> Priority: minor | Milestone: 0.21
> Component: mythtv | Version: head
> Severity: medium | Resolution:
> ------------------------------------------------
> +---------------------------
> Comment (by cpinkham):
>
> Doesn't this patch have the adverse side effect that jobs we want
> to run
> once a day could potentially run every 12 hours because of the
> following
> line:
>
> longEnough = ((period * oneday) - oneday/2);
Yes. It does have that side-effect. This is because the old logic
was "don't run more frequently than every 24 hours", NOT "run once
per calendar day".
I was after an effect that was something like "grab once per day, at
a random time". If I left the old logic, then when the system
grabbed late one day it would be forced to grab late the next day too
(else it would have grabbed more than once in 24 contiguous hours).
The only way it could get back to grabbing early would be to ratchet
back in 5 minute intervals, or skip a day entirely.
I decided that I did't want to fill the database too frequently, so I
allow it to ratchet back in 12 hour increments rather than 5 minute
increments. You could adjust that 6 hour increments if you want.
I'd suggest leaving it as 12 hours - it isn't going to ratchet back
easily because of the random delays.
There is another issue that I thought about after submitting the
patch... the patch currently assumes that your machine is running all
the time. I haven't played with the auto shutdown-startup stuff in
myth. It might not play nice with this patch.
> That alone would be a bad thing, but is probably prevented by what
> appears
> to be flawed logic in the random time check:
>
> ((random()%((maxhour-minhour+1)*6)) == 0)
>
> So if maxhour is 24 and minhour is 0, then you're checking if the
> random
> number is evenly divisible by (24 - 0 + 1) * 6 which works out to
> 150.
> Those would seem to be very very low odds which would mean we'd
> always be
> running in the last half hour of our window when the "(hour ==
> maxhour &&
> minute > 30)" check kicked in. Doesn't seem very randomized.
Myth is making that check every 5 minutes. So in your example you
have 24*12 = 288 chances to succeed, each of which, individually, has
probability 1/150. The probability you don't run at all is (149/150)
^288 = 0.15. So you are right in that it is slightly biased.
Exactly how biased depends upon the range of time you give it to run.
The probability currently isn't uniform because I didn't think it was
worth the hassle. If you want to make it uniform then you need to
make the probability 1/(# remaining chances to run today) as opposed
to the current probability of 2/(# total chances to run today).
I think this does it:
((random()%((maxhour-hour)*12 + (60-minute)/5 - 6) == 0))
(maxhour-hour)*12 = the number of attempts in the remaining full hours
(60-minute)/5 = the number of attempts in the remaining partial hour
- 6 = we don't want to include the last 30 minutes where a run is forced
Of course, I've tested the other code, whereas I haven't tested
this. Although the new formula plays more nicely with the auto-
shutdown/wakeup stuff, in that if you wake up half-way through the
"ok period" then you have boosted chance of running.
> Can you check the logs to see when your mythfilldatabase runs were
> actually occuring to show this is really random and not semi-
> random, but
> mostly in the last 30 minutes of the window?
I checked this before posting the patch. But here is the data from
my current logs. I set my grabber to run between 2 and 4 pm daily.
% grep "mythbackend: Running mythfilldatabase" *
mythbackend.log:2006-09-15 15:00:36.423 mythbackend: Running
mythfilldatabase
mythbackend.log.1:2006-09-14 16:04:14.974 mythbackend: Running
mythfilldatabase
mythbackend.log.10:2006-09-05 16:34:44.054 mythbackend: Running
mythfilldatabase
mythbackend.log.11:2006-09-04 16:32:59.660 mythbackend: Running
mythfilldatabase
mythbackend.log.12:2006-09-03 15:44:55.887 mythbackend: Running
mythfilldatabase
mythbackend.log.13:2006-09-02 14:42:09.719 mythbackend: Running
mythfilldatabase
mythbackend.log.14:2006-09-01 14:05:05.174 mythbackend: Running
mythfilldatabase
mythbackend.log.2:2006-09-13 14:56:30.569 mythbackend: Running
mythfilldatabase
mythbackend.log.3:2006-09-12 14:13:42.043 mythbackend: Running
mythfilldatabase
mythbackend.log.4:2006-09-11 14:31:46.024 mythbackend: Running
mythfilldatabase
mythbackend.log.5:2006-09-10 15:22:02.131 mythbackend: Running
mythfilldatabase
mythbackend.log.6:2006-09-09 14:04:50.952 mythbackend: Running
mythfilldatabase
mythbackend.log.7:2006-09-08 15:19:28.773 mythbackend: Running
mythfilldatabase
mythbackend.log.8:2006-09-07 14:26:42.468 mythbackend: Running
mythfilldatabase
mythbackend.log.9:2006-09-06 15:10:30.554 mythbackend: Running
mythfilldatabase
Hrm, maybe between 2 and 5pm... ahh - I remember now: MaxHour is
inclusive :). And that answers your followup mail :) Although that
means that the 24 on lines 174 & 178 really should change to 23, as
should the 24s in programs/mythfrontend/globalsettings.cpp
Or you could fix it so that maxhr is non-inclusive (it was inclusive
before my patch in the code, but not the preference comments).
That's probably a better fix.
So here is the complete set of fixes - same as before but with a
uniform distribution and non-inclusive max hour.
Index: housekeeper.cpp
===================================================================
--- housekeeper.cpp (revision 10995)
+++ housekeeper.cpp (working copy)
@@ -48,7 +48,7 @@
unsigned int longEnough = 0;
if (period)
- longEnough = ((period * oneday) - 600);
+ longEnough = ((period * oneday) - oneday/2);
else
longEnough = oneday / 8;
@@ -70,8 +70,13 @@
if ((now.toTime_t() - lastrun.toTime_t()) > longEnough)
{
int hour = now.toString(QString("h")).toInt();
- if ((hour >= minhour) && (hour <= maxhour))
- runOK = true;
+ if ((hour >= minhour) && (hour < maxhour))
+ {
+ int minute = now.toString(QString("m")).toInt();
+ if ((hour == maxhour-1 && minute > 30)
+ || ((random()%((maxhour-hour-1)*12+(60-
minute)/5 - 6) == 0))
+ runOK = true;
+ }
}
}
else
@@ -202,7 +207,7 @@
if ((nextRun < now) &&
(lastRun.secsTo(now) > (3 * 60 * 60)) &&
- ((minhr <= hour) && (hour <= maxhr)))
+ ((minhr <= hour) && (hour < maxhr)))
runMythFill = true;
}
else if (wantToRun("MythFillDB", period, minhr,
maxhr))
@@ -241,7 +246,7 @@
updateLastrun(dbTag);
}
- sleep(300);
+ sleep(300 + (random()%8));
}
}
But that is totally untested.
Be well,
Will :-}
--
Dr William Uther National ICT Australia
Phone: +61 2 8306 0424 Computer Science and Engineering
Email: william.uther at nicta.com.au University of New South Wales
Email: willu at cse.unsw.edu.au Sydney, Australia
Web: http://www.cse.unsw.edu.au/~willu/ or http://www.nicta.com.au/
NICTA email Disclaimer:
http://www.cse.unsw.edu.au/~willu/NICTAEmailDisclaimer.html
UNSW email Disclaimer:
http://www.eng.unsw.edu.au/emaildis.htm
More information about the mythtv-dev
mailing list