[mythtv-users] HowTo tune MySQL for schedule time and in general?

[Karl Newman]

On Mon, May 6, 2013 at 7:26 AM, David Engel <david at istwok.net> wrote:

> On Sun, May 05, 2013 at 12:44:31PM +0200, Thomas Börkel wrote:
> > On 05.05.2013 05:27, David Engel wrote:
> >
> > > Something doesn't add up here.
> > >
> > > In your first timing, the majority of time (5.88s) was spent in the
> > > place phase.  That phase shouldn't be affected that much by DB
> > > changes.  To get a later run in the 0.2s range, the place phase would
> > > have had to sped up a lot and I can't see that happening with just a
> > > DB change.  It is the match and check phases that are DB sensitive.
> >
> > Only thing I can say is that the scheduler always took these long times
> > before my changes and now it is always fast.
> >
> > > In addition, the scheduler normally only runs the match and check
> > > phases on things that might have changed.  That means you can't
> > > arbitrarily pick scheduler runs and compare them because they might
> > > not have done the same amount of work.  You can compare runs initiated
> > > with "mythutil --resched" because those cause the scheduler to re-run
> > > everything.  You can also compare runs by making a do-nothing change
> > > to a single recording rule because those cause the scheduler to only
> > > re-run the parts for that rule.
> >
> > I compared the times by scheduling a new non-conflict recording and then
> > deleting it again.
>
> That sounds like a reasonable test.  Still, that amount of improvement
> sounds way too good to be true.  If it works, though, enjoy. :)
>
> David
>

I've been following this thread (even though I don't have any tuners with
multiplexes and probably never will). I read your description of how the
scheduler works and it prompted me to think about another possible
scheduler strategy. As I understand it now (and I'm probably wrong on at
least some part so please correct me), the scheduler uses each physical
tuners first as it's assigning programs to tuners, and then uses the
virtual tuners in a second+ pass (if it needs to move a program?). The way
I was envisioning, it would start with the priority-ordered list of
programs, beginning with the highest priority. When scheduling a program
onto a tuner with multiple virtual tuners, the scheduler would then run
through the rest of the list (in priority order) and try to schedule other
programs onto the virtual tuners for that multiplex. After the virtual
tuners were full (or no more programs can record on that multiplex), then
move to the next physical tuner with the next unscheduled program in the
original program list. After this first pass, then run through the second
(or more?) "moving" pass to shuffle programs if needed (I'm a little fuzzy
about that part).

I'm sure there are some complexities that I'm glossing over or not aware
of, but is this even possible?

Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130506/f1c2bbea/attachment.html>