Start process and time chunk

[matthieuG]

Hello,

I resume here a discussion which could help developers :

Start process
_I can't lunch process of a box, even if I use this->getBoxAlgorithmContext()->markAlgorithmAsReadyToProcess();
_Process is not done while a chunk does not arrived, if the box has at least one input.
You can escape this by using clockActivation (processClock()). Don't forget getClockFrequency(void) which return 'X'LL<<32 for XHz.

time chunk
_what are start/end time for chunk, where are they used?
_start time and end time are duration associated with data. So avoid to give a nul duration.
_how real time measure is controlled in kernel?
_the kernel measure time between each callback of a box during 1 second of execution and compare it to the mean time that could be reasonable to execute 1 nth second if n is the number of boxes.
In real-time visual control, box color are :
+green below 1 nth
+green->red between 1-4 nth second
+red over 4 nth second

if uncorrect answer...check!

[matthieuG]

Yann find this post hard to understand without context, I try better :

Start process
If you want to enter in the process of a box from itself (start process automatically), markAlgorithmAsReadyToProcess() is not enough. The only way is to use an intern clock (processClock() with getClockFrequency()).

Code to add in your box description : (of course don't forget their equivalent in header part...)

Code: Select all

uint64 CBox::getClockFrequency(void)
{return 60LL<<32;} //for example

boolean CBox::processClock(CMessageClock& rMessageClock)
{
	getBoxAlgorithmContext()->markAlgorithmAsReadyToProcess();
	return true;
}

real time in openViBE
"the kernel measure time between each callback of a box during 1 second of execution and compare it to the mean time that could be reasonable to execute 1 nth second if n is the number of boxes."

[yrenard]

Start process
If you want to enter in the process of a box from itself (start process automatically), markAlgorithmAsReadyToProcess() is not enough. The only way is to use an intern clock (processClock() with getClockFrequency()).

Code to add in your box description : (of course don't forget their equivalent in header part...)

In fact, returning non 0 clock frequency causes the kernel to request the processing of clock messages.
Then whatever process{clock|input|signal} function is called by the kernel, marking the algorithm as ready to process causes the kernel to request the actual processing.

real time in openViBE
"the kernel measure time between each callback of a box during 1 second of execution and compare it to the mean time that could be reasonable to execute 1 nth second if n is the number of boxes."

The point matthieuG wants to explain here is about the "information" button in the designer (bottom right of the UI). This button puts colors on the boxes, giving an idea of the whole performance of the processing pipeline. The monitoring is refreshed on the last second. Suppose you have n boxes. Then in order to match realtime requirements, it makes sense that each box does not take more than 1/n seconds for its own processing. Therefore the colors are chosen as follows :

• - green if the box took less than 1/n second to process on the last second of execution
  - green to red if the box took between 1/n and 4/n second to process on the last second of execution
  - red if the box took more than 4/n second to process on the last second of execution

Having red boxes does not necessary mean there will be performance issues. Just that this box takes a significantly higher time than what it ideally should take. If you have enough green boxes to save processing time, then the whole performance could be just fine.

Thank you matthieuG for pointing this out. But next time, please try to take the time to explain things with details so your message do not confuse the readers.

Best regards,
Yann