LTTng » LTTng-UST

When using LTTNG_UST_BLOCKING_RETRY_TIMEOUT, it is desirable to know when blocking occured. This way an analyst will stay informed of periods in the trace where precision of events had to be traded for completeness.

This has been discussed informally in the IRC channel:

[09:08:06] rnsanchez   such points could be of interest in my analysis  :+)
[09:59:35] Compudj     rnsanchez: no
[10:01:19] Compudj     rnsanchez: but looking at event clusters in your trace will help
[10:01:36] rnsanchez   Compudj: what about throwing a single/occasional event for a corresponding tid/pid that was ungraced due to excessive events?
[10:01:56] Compudj     rnsanchez: with multi-session support, that would not be that easy
[10:02:04] Compudj     we'd have to know which buffers are affected
[10:02:22] Compudj     so we don't generate noise into other sessions
[10:02:36] rnsanchez   I see
[10:02:37] rnsanchez   sounds fair
[10:03:35] Compudj     rnsanchez: if we add such info eventually, I'd be tempted to add a packet header field for that
[10:03:47] Compudj     which could counts the "blocking" a buffer has had so far
[10:04:11] Compudj     so we don't rely on events to relay information that is transport-level
[10:04:35] Compudj     that would be doable (you may want to add a feature request on bugs.lttng.org)
[10:05:26] rnsanchez   well that kind of info could be "rendered" into tools such as Trace Compass.  it would be informative enough for the analyst to take a convolute period with a grain/spoon of salt
[10:05:57] rnsanchez   Compudj: I can do that, sure
[10:06:04] Compudj     rnsanchez: yes, and having those counters in the packet header would nicely match the spots where the situation occurs
[10:06:15] Compudj     blocking always happen at sub-buffer (packet) boundary
[10:09:06] rnsanchez   so it would act (briefly) as a relaxed clock?  i.e., "between events En and En+1, we blocked, take that into account" 
[10:09:24] rnsanchez   (relaxed as in not actually probing clocks for a timestamp)
[10:10:43] Compudj     yes, if we detect that the blocking counter increased between two consecutive packets, we can put a marker between timestamp end of the first packet and timestamp begin of the second packet saying that the source has been blocked during that time
[10:11:11] rnsanchez   perfect
[10:12:19] Compudj     you may want to paste this conversation into the bug tracker feature request, it will make it easier to remember the details when/if we get to implement it
[10:13:26] rnsanchez   doing that as we speak