Hello,
On Sat, Apr 16, 2016 at 8:51 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
On 04/16/2016 06:50 PM, Dario Casalinuovo wrote:
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,
What are A and latency in this inequation?
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.
I don't get what you're aiming at. read_port_etc() itself doesn't imply a
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,
This comparison doesn't make sense: You defined T above as a point in time
while the processing latency is a duration.
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.
I don't get what you're talking about.
If someone followed my changes,
Just for clarity: I have not.
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.
If by "thread activation" you mean the period of time between the thread
having being scheduled and it being unscheduled, that is virtually
impossible to control.
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
I assume this is supposed to go into the BMediaNode::WaitForMessage() port
reading loop or guard the WaitForMessage() call in
BMediaEventLooper::ControlLoop(). If you replace RealTime() by
system_time()
and omit the subtraction of QUANTUM, this would make some sense.
It would save the time for the read_port_etc() syscall at this point, when
the time for the next scheduled event is already up.
However, it would also prevent an event whose message is pending at the
port from being scheduled quickly. If that event was even more urgent than
the next scheduled one, it would be delayed unnecessarily -- not sure, if
this is a situation that is of practical relevance.
Anyway, I don't get the QUANTUM thing. Why would it be beneficial to start
processing an event this early? If we're talking about the same code,
waitUntil is already offset by the estimated scheduling latency.
This simple change allow a perceivable performance improvement.
I suppose you're saying you made this change and the performance improved?
So
what's the problem? While I have been happy for beginning to solve this
discrepancy
What discrepancy? To clarify: I still don't know what the initial problem
is you're trying to solve.
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?
Actually: Why? Why does scheduling an event early cause a deadlock?
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.
Why is this a solution and to what problem?
* Avoid to handle too much events than the messages read
Not sure what you're trying to say.
* Instead to pick the higher event we can recursively fetch the
BTimedEventQueue head and select the events comprised in that range.
Ditto.
