Hello,
one thing I wanted to push was a little change that allowed to put all
BMediaEventLooper events in a quantum of time.
The idea is that all events comprised in a certain range should be handled
before the next read_port. The reason for this is that in the worst case we
might have an event B subsequent to an event A, suppose the event B is
scheduled at a time T so that A+latency > T, in simple words the event will
be mathematically scheduled late. To some level we can recover from that
situation by handling a limited number of events without reading the port,
this will make us able to get rid of the scheduling latency.
This is exactly the crux of the situation, if we are lucky enough handling
a group of events will solve the situation, this is I think the main reason
for the media_kit having a bit of problems in handling low buffer sizes
(and would make us able to lower the hda default buffer size). The worst of
the worst case is that the event is effectively taking a processing latency
that is greater than T, in this case we can't do better and we can only
increase the latency. In any case to have the event handling set to process
a quantum of events is the max we can do without dealing with the latency
mechanism IMHO.
If someone followed my changes, I already stated that I wanted to have a
linear relation between event handling and port writes. This means that if
we have an event to handle and a message to read we will attempt to do both
in the same thread activation.
The simpler implementation is to decide at the moment if it's the case to
read the port or just time out and allow to read it at next cycle using a
constant QUANTUM range. In pseudo code :
if (RealTime() < (waitUntil - QUANTUM))
ret = read_port
else
ret = B_TIMED_OUT
This simple change allow a perceivable performance improvement. So what's
the problem? While I have been happy for beginning to solve this
discrepancy I just figured out it re-introduce a very bad issue. Basically
what happens is that under stress conditions (20 nodes or so) at some point
some event is scheduled before than what it should and there's a dreadlock
of the buffers locking mechanism preventing the unlock to happen. So what
then?
I think this is the right solution to the problem :
* Have a dynamic QUANTUM, calculated using the latency and some other
factor.
* Balance always events and ports, more simply if we handle N events in a
quantum we should attempt to read N messages from the port then.
* Avoid to handle too much events than the messages read
* Instead to pick the higher event we can recursively fetch the
BTimedEventQueue head and select the events comprised in that range.
Other possible solution :
* Don't care about that and leave it as now (linear relationship)
Since some people is having some problem in following what I'm doing, then
I hope I have already documented it properly when it will happen.
As always if someone is interested in the topic, comments welcome.
--
Best Regards,
Dario
