DPL: do not send the oldest possible timeframe to out of band channels

[ktf]

No description provided.

[ktf]

If this is not the case, the STF* stuff complains about the non-timeframe data.
@ironMann @davidrohr @vascobarroso @shahor02 this should workaround the issue seen on the FLP. However it's not clear to me this should be the final solution, in the sense that maybe it's better to change DD to handle it on its side, dropping the message when not needed. What do you think?

[davidrohr]

Thx, this was fast :)
Could you already test it on the FLPs?
I also don't see why we have this requirement, but since we have it only at a single place, from the output-proxy to the StfSender, I assume it does not hurt that much.

[ironMann]

What are the forwarded parts?

I gather this about the inputs to StfSender. It has a simple requirement for synchronous local processing: to receive all data of STFs as a standart stf fmq-message (including the original DATADIST header), and in the same STF-ID order as provided on DPL input – sequential.
Any data sent to StfSender outside this spec will be dropped.

[ktf]

@ironMann the forwarded parts in this particular case are whatever we send from the output-proxy to the downstream receiving device. In this particular context, before the changes for the "oldest possible timeframe", this was just the original timeframes being sent to the STFSender. With the new development, we have an extra message that was inserted which does not have a DataHeader (because in principle it can be sent also without data). This new message does not have a DISTSTF in the same FairMQParts and for this reason DD complained. This makes sure that the extra message is always attached to some timeframe, but I wonder if it's the correct thing to do.

@davidrohr I am about to try it in the FLP testbed.

[ktf]

@ironMann do you actually require a DataHeader for each header?

[davidrohr]

but what confuses me a bit: what has the oldestPossibleTimeframe to do with StfSender? is the output proxy sending it to there?

[ktf]

Yes, indeed, I am not sure it's the correct thing to do, as I said. The problem is that the output proxy uses the forwarding mechanism to redirect data, apparently.

[ktf]

So, I have done some other development which excludes the output proxy downstream channel from being sent the extra message and that seems to work in the FLP testbed. However I am not sure it's the right thing to do, since I think it would break the case in which the dpl-output-proxy sends data to a "dpl-input-proxy".

[davidrohr]

But isn't the input-proxy a source, which generates the oldestPossible message by itself? At least in case it gets the data from DD?

[ktf]

True... Ok then I guess the fix is simply to not add the extra message for non-DPL channels, which indeed should be very simple.

[ktf]

@vascobarroso @davidrohr Works in the standalone tests, works in the fullCI, works in the FLP setup with 600MB/s sustained since ~17:00. Merging.

[ktf]

@vascobarroso @davidrohr Works in the standalone tests, works in the fullCI, works in the FLP setup with 600MB/s sustained since ~17:00. Merging.