[lttng-dev] [RFC PATCH CTF 0/3] Common Trace Format Updates (upcoming 1.8.3)

[lttng-dev] [RFC PATCH CTF 0/3] Common Trace Format Updates (upcoming 1.8.3)

[Mathieu Desnoyers]

Hi,

We noticed a few unspecified areas in the CTF 1.8.2 specification which
require some clarifications. We therefore plan to do a 1.8.3 release of
the specification including those changes.

Review is welcome,

Thanks,

Mathieu

Genevi?ve Bastien (1):
  Clarify that unlisted enum values are implementation-defined

Mathieu Desnoyers (2):
  Clarify monotonicity requirement on timestamp begin
  Clarify that timestamp begin/end need to be complete clock values

 common-trace-format-specification.md | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

-- 
2.11.0

[lttng-dev] [RFC PATCH CTF 1/3] Clarify that unlisted enum values are implementation-defined

[Mathieu Desnoyers]

From: Genevi?ve Bastien <gbastien+lttng@versatic.net>

Signed-off-by: Genevi?ve Bastien <gbastien+lttng at versatic.net>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
---
 common-trace-format-specification.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/common-trace-format-specification.md b/common-trace-format-specification.md
index fd49e59..f5fea51 100644
--- a/common-trace-format-specification.md
+++ b/common-trace-format-specification.md
@@ -464,6 +464,9 @@ enum {
 }
 ~~~
 
+The mappings in the enumeration type do not have to be exhaustive.
+Unlisted values are implementation defined.
+
 ### 4.2 Compound types
 
 Compound are aggregation of type declarations. Compound types include
-- 
2.11.0

[lttng-dev] [RFC PATCH CTF 1/3] Clarify that unlisted enum values are implementation-defined

[Jérémie Galarneau]

On Thu, 23 Apr 2020 at 16:52, Mathieu Desnoyers
<mathieu.desnoyers at efficios.com> wrote:
>
> From: Genevi?ve Bastien <gbastien+lttng@versatic.net>
>
> Signed-off-by: Genevi?ve Bastien <gbastien+lttng at versatic.net>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
> ---
>  common-trace-format-specification.md | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/common-trace-format-specification.md b/common-trace-format-specification.md
> index fd49e59..f5fea51 100644
> --- a/common-trace-format-specification.md
> +++ b/common-trace-format-specification.md
> @@ -464,6 +464,9 @@ enum {
>  }
>  ~~~
>
> +The mappings in the enumeration type do not have to be exhaustive.
> +Unlisted values are implementation defined.
> +

This is too vague to be useful knowing that the main rationale for this
change is to allow enums to express some type of bitfield of flags
in the tracer and readers [1].

What is the meaning of an unmapped value? This section should at
least describe the correct interpretation of unmapped values as flags
and when it is appropriate to do so.

Thanks,
J?r?mie

[1] https://review.lttng.org/c/babeltrace/+/3045

>  ### 4.2 Compound types
>
>  Compound are aggregation of type declarations. Compound types include
> --
> 2.11.0
>


-- 
J?r?mie Galarneau
EfficiOS Inc.
http://www.efficios.com

[lttng-dev] [RFC PATCH CTF 1/3] Clarify that unlisted enum values are implementation-defined

[Mathieu Desnoyers]

----- On Apr 23, 2020, at 6:51 PM, Jeremie Galarneau jeremie.galarneau at efficios.com wrote:

> On Thu, 23 Apr 2020 at 16:52, Mathieu Desnoyers
> <mathieu.desnoyers at efficios.com> wrote:
>>
>> From: Genevi?ve Bastien <gbastien+lttng@versatic.net>
>>
>> Signed-off-by: Genevi?ve Bastien <gbastien+lttng at versatic.net>
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
>> ---
>>  common-trace-format-specification.md | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/common-trace-format-specification.md
>> b/common-trace-format-specification.md
>> index fd49e59..f5fea51 100644
>> --- a/common-trace-format-specification.md
>> +++ b/common-trace-format-specification.md
>> @@ -464,6 +464,9 @@ enum {
>>  }
>>  ~~~
>>
>> +The mappings in the enumeration type do not have to be exhaustive.
>> +Unlisted values are implementation defined.
>> +
> 
> This is too vague to be useful knowing that the main rationale for this
> change is to allow enums to express some type of bitfield of flags
> in the tracer and readers [1].
> 
> What is the meaning of an unmapped value? This section should at
> least describe the correct interpretation of unmapped values as flags
> and when it is appropriate to do so.

Considering that this is a patchlevel update to CTF, I would not expect
that we introduce new features in the specification. Only clarifications
to parts of the specification that were unclear.

Specifying a new behavior related to unmapped values would fall IMO into the
realm of "new feature", and would belong to a CTF 1.9 or CTF 2.0. As we
all know, there is a CTF 2.0 in the making, but it does not solve the
immediate problem of LTTng 2.12 which produces those unmapped enum values
within traces identified as CTF 1.8.

Moreover, to add to the problem, Babeltrace 2 has a strict match on CTF 1.8
in the CTF source plugin, and won't accept a CTF 1.9 trace (unlike Babeltrace 1
which would emit a warning about possibly unsupported features, but would accept
a 1.9 CTF trace nevertheless).

So this is why I am proposing this minimal clarification to the CTF 1.8
specification: that unmapped enum values are implementation defined (rather
than saying nothing about them). Considering that tracers can generate this
kind of trace data anyway, it's really a consideration that should have been
explicitly expressed in the specification from the start and was an
involuntary omission.

So perhaps we need to state something more than just "implementation defined",
but it's unclear what without ending up adding features into a patchlevel
update.

Thanks,

Mathieu


> Thanks,
> J?r?mie
> 
> [1] https://review.lttng.org/c/babeltrace/+/3045
> 
>>  ### 4.2 Compound types
>>
>>  Compound are aggregation of type declarations. Compound types include
>> --
>> 2.11.0
>>
> 
> 
> --
> J?r?mie Galarneau
> EfficiOS Inc.
> http://www.efficios.com

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

[lttng-dev] [RFC PATCH CTF 1/3] Clarify that unlisted enum values are implementation-defined

[Philippe Proulx]

----- Original Message -----
> From: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> To: "gbastien+lttng" <gbastien+lttng at versatic.net>, "Matthew Khouzam" <matthew.khouzam at ericsson.com>,
> diamon-discuss at linuxfoundation.org, pproulx at efficios.com, "Jeremie Galarneau" <jgalar at efficios.com>
> Cc: "lttng-dev" <lttng-dev at lists.lttng.org>, "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>
> Sent: Thursday, 23 April, 2020 16:52:24
> Subject: [RFC PATCH CTF 1/3] Clarify that unlisted enum values are implementation-defined

> From: Genevi?ve Bastien <gbastien+lttng@versatic.net>
> 
> Signed-off-by: Genevi?ve Bastien <gbastien+lttng at versatic.net>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
> ---
> common-trace-format-specification.md | 3 +++
> 1 file changed, 3 insertions(+)
> 
> diff --git a/common-trace-format-specification.md
> b/common-trace-format-specification.md
> index fd49e59..f5fea51 100644
> --- a/common-trace-format-specification.md
> +++ b/common-trace-format-specification.md
> @@ -464,6 +464,9 @@ enum {
> }
> ~~~
> 
> +The mappings in the enumeration type do not have to be exhaustive.
> +Unlisted values are implementation defined.
> +

Why not just:

    An enumeration field can have an integral value which its type does not
    map to a string.

?

Phil

> ### 4.2 Compound types
> 
> Compound are aggregation of type declarations. Compound types include
> --
> 2.11.0

[lttng-dev] [RFC PATCH CTF 1/3] Clarify that unlisted enum values are implementation-defined

[Mathieu Desnoyers]

----- On Apr 28, 2020, at 2:40 PM, Philippe Proulx pproulx at efficios.com wrote:

> ----- Original Message -----
>> From: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
>> To: "gbastien+lttng" <gbastien+lttng at versatic.net>, "Matthew Khouzam"
>> <matthew.khouzam at ericsson.com>,
>> diamon-discuss at linuxfoundation.org, pproulx at efficios.com, "Jeremie Galarneau"
>> <jgalar at efficios.com>
>> Cc: "lttng-dev" <lttng-dev at lists.lttng.org>, "Mathieu Desnoyers"
>> <mathieu.desnoyers at efficios.com>
>> Sent: Thursday, 23 April, 2020 16:52:24
>> Subject: [RFC PATCH CTF 1/3] Clarify that unlisted enum values are
>> implementation-defined
> 
>> From: Genevi?ve Bastien <gbastien+lttng@versatic.net>
>> 
>> Signed-off-by: Genevi?ve Bastien <gbastien+lttng at versatic.net>
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
>> ---
>> common-trace-format-specification.md | 3 +++
>> 1 file changed, 3 insertions(+)
>> 
>> diff --git a/common-trace-format-specification.md
>> b/common-trace-format-specification.md
>> index fd49e59..f5fea51 100644
>> --- a/common-trace-format-specification.md
>> +++ b/common-trace-format-specification.md
>> @@ -464,6 +464,9 @@ enum {
>> }
>> ~~~
>> 
>> +The mappings in the enumeration type do not have to be exhaustive.
>> +Unlisted values are implementation defined.
>> +
> 
> Why not just:
> 
>    An enumeration field can have an integral value which its type does not
>    map to a string.
> 
> ?

Good point, I will use that wording.

Thanks,

Mathieu

> 
> Phil
> 
>> ### 4.2 Compound types
>> 
>> Compound are aggregation of type declarations. Compound types include
>> --
> > 2.11.0

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

[lttng-dev] [RFC PATCH CTF 1/3] Clarify that unlisted enum values are implementation-defined

[Mathieu Desnoyers]

----- On Apr 28, 2020, at 2:51 PM, Mathieu Desnoyers mathieu.desnoyers at efficios.com wrote:

> ----- On Apr 28, 2020, at 2:40 PM, Philippe Proulx pproulx at efficios.com wrote:
> 
>> ----- Original Message -----
>>> From: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
>>> To: "gbastien+lttng" <gbastien+lttng at versatic.net>, "Matthew Khouzam"
>>> <matthew.khouzam at ericsson.com>,
>>> diamon-discuss at linuxfoundation.org, pproulx at efficios.com, "Jeremie Galarneau"
>>> <jgalar at efficios.com>
>>> Cc: "lttng-dev" <lttng-dev at lists.lttng.org>, "Mathieu Desnoyers"
>>> <mathieu.desnoyers at efficios.com>
>>> Sent: Thursday, 23 April, 2020 16:52:24
>>> Subject: [RFC PATCH CTF 1/3] Clarify that unlisted enum values are
>>> implementation-defined
>> 
>>> From: Genevi?ve Bastien <gbastien+lttng@versatic.net>
>>> 
>>> Signed-off-by: Genevi?ve Bastien <gbastien+lttng at versatic.net>
>>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
>>> ---
>>> common-trace-format-specification.md | 3 +++
>>> 1 file changed, 3 insertions(+)
>>> 
>>> diff --git a/common-trace-format-specification.md
>>> b/common-trace-format-specification.md
>>> index fd49e59..f5fea51 100644
>>> --- a/common-trace-format-specification.md
>>> +++ b/common-trace-format-specification.md
>>> @@ -464,6 +464,9 @@ enum {
>>> }
>>> ~~~
>>> 
>>> +The mappings in the enumeration type do not have to be exhaustive.
>>> +Unlisted values are implementation defined.
>>> +
>> 
>> Why not just:
>> 
>>    An enumeration field can have an integral value which its type does not
>>    map to a string.
>> 
>> ?
> 
> Good point, I will use that wording.

Genevi?ve pointed out on IRC that the sentence above is weird. Would the
following convey the right meaning ?

"An enumeration field can have an integral value for which the associated enumeration
type does not map to a string."

Thanks,

Mathieu

> 
> Thanks,
> 
> Mathieu
> 
>> 
>> Phil
>> 
>>> ### 4.2 Compound types
>>> 
>>> Compound are aggregation of type declarations. Compound types include
>>> --
>> > 2.11.0
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

[lttng-dev] [RFC PATCH CTF 1/3] Clarify that unlisted enum values are implementation-defined

[Philippe Proulx]

----- Original Message -----
> From: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> To: "Philippe Proulx" <pproulx at efficios.com>
> Cc: "gbastien+lttng" <gbastien+lttng at versatic.net>, "Matthew Khouzam" <matthew.khouzam at ericsson.com>, "Jeremie
> Galarneau" <jgalar at efficios.com>, "lttng-dev" <lttng-dev at lists.lttng.org>, "diamon-discuss"
> <diamon-discuss at lists.linuxfoundation.org>
> Sent: Wednesday, 29 April, 2020 08:08:04
> Subject: Re: [RFC PATCH CTF 1/3] Clarify that unlisted enum values are implementation-defined

> ----- On Apr 28, 2020, at 2:51 PM, Mathieu Desnoyers
> mathieu.desnoyers at efficios.com wrote:
> 
>> ----- On Apr 28, 2020, at 2:40 PM, Philippe Proulx pproulx at efficios.com wrote:
>> 
>>> ----- Original Message -----
>>>> From: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
>>>> To: "gbastien+lttng" <gbastien+lttng at versatic.net>, "Matthew Khouzam"
>>>> <matthew.khouzam at ericsson.com>,
>>>> diamon-discuss at linuxfoundation.org, pproulx at efficios.com, "Jeremie Galarneau"
>>>> <jgalar at efficios.com>
>>>> Cc: "lttng-dev" <lttng-dev at lists.lttng.org>, "Mathieu Desnoyers"
>>>> <mathieu.desnoyers at efficios.com>
>>>> Sent: Thursday, 23 April, 2020 16:52:24
>>>> Subject: [RFC PATCH CTF 1/3] Clarify that unlisted enum values are
>>>> implementation-defined
>>> 
>>>> From: Genevi?ve Bastien <gbastien+lttng@versatic.net>
>>>> 
>>>> Signed-off-by: Genevi?ve Bastien <gbastien+lttng at versatic.net>
>>>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
>>>> ---
>>>> common-trace-format-specification.md | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>> 
>>>> diff --git a/common-trace-format-specification.md
>>>> b/common-trace-format-specification.md
>>>> index fd49e59..f5fea51 100644
>>>> --- a/common-trace-format-specification.md
>>>> +++ b/common-trace-format-specification.md
>>>> @@ -464,6 +464,9 @@ enum {
>>>> }
>>>> ~~~
>>>> 
>>>> +The mappings in the enumeration type do not have to be exhaustive.
>>>> +Unlisted values are implementation defined.
>>>> +
>>> 
>>> Why not just:
>>> 
>>>    An enumeration field can have an integral value which its type does not
>>>    map to a string.
>>> 
>>> ?
>> 
>> Good point, I will use that wording.
> 
> Genevi?ve pointed out on IRC that the sentence above is weird. Would the
> following convey the right meaning ?
> 
> "An enumeration field can have an integral value for which the associated
> enumeration
> type does not map to a string."

Sure.

Phil

> 
> Thanks,
> 
> Mathieu
> 
>> 
>> Thanks,
>> 
>> Mathieu
>> 
>>> 
>>> Phil
>>> 
>>>> ### 4.2 Compound types
>>>> 
>>>> Compound are aggregation of type declarations. Compound types include
>>>> --
>>> > 2.11.0
>> 
>> --
>> Mathieu Desnoyers
>> EfficiOS Inc.
>> http://www.efficios.com
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com

[lttng-dev] [RFC PATCH CTF 2/3] Clarify monotonicity requirement on timestamp begin

[Mathieu Desnoyers]

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
---
 common-trace-format-specification.md | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/common-trace-format-specification.md b/common-trace-format-specification.md
index f5fea51..53b70f4 100644
--- a/common-trace-format-specification.md
+++ b/common-trace-format-specification.md
@@ -836,10 +836,12 @@ TSDL metadata):
     range between these timestamps should include all event timestamps
     assigned to events contained within the packet. The timestamp at the
     beginning of an event packet is guaranteed to be below or equal the
-    timestamp at the end of that event packet. The timestamp at the end
-    of an event packet is guaranteed to be below or equal the
-    timestamps at the end of any following packet within the same stream.
-    See [Clocks](#spec8) for more detail.
+    timestamp at the end of that event packet. The timestamp at the
+    beginning of an event packet is guaranteed to be above or equal the
+    timestamps at the beginning of any prior packet within the same
+    stream. The timestamp at the end of an event packet is guaranteed to
+    be below or equal the timestamps at the end of any following packet
+    within the same stream. See [Clocks](#spec8) for more detail.
   * **Events discarded count**. Snapshot of a per-stream
     free-running counter, counting the number of events discarded that
     were supposed to be written in the stream after the last event in
-- 
2.11.0

[lttng-dev] [RFC PATCH CTF 2/3] Clarify monotonicity requirement on timestamp begin

[Philippe Proulx]

----- Original Message -----
> From: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> To: "gbastien+lttng" <gbastien+lttng at versatic.net>, "Matthew Khouzam" <matthew.khouzam at ericsson.com>,
> diamon-discuss at linuxfoundation.org, pproulx at efficios.com, "Jeremie Galarneau" <jgalar at efficios.com>
> Cc: "lttng-dev" <lttng-dev at lists.lttng.org>, "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>
> Sent: Thursday, 23 April, 2020 16:52:25
> Subject: [RFC PATCH CTF 2/3] Clarify monotonicity requirement on timestamp begin

> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
> ---
> common-trace-format-specification.md | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/common-trace-format-specification.md
> b/common-trace-format-specification.md
> index f5fea51..53b70f4 100644
> --- a/common-trace-format-specification.md
> +++ b/common-trace-format-specification.md
> @@ -836,10 +836,12 @@ TSDL metadata):
>     range between these timestamps should include all event timestamps
>     assigned to events contained within the packet. The timestamp at the
>     beginning of an event packet is guaranteed to be below or equal the
> -    timestamp at the end of that event packet. The timestamp at the end
> -    of an event packet is guaranteed to be below or equal the
> -    timestamps at the end of any following packet within the same stream.
> -    See [Clocks](#spec8) for more detail.
> +    timestamp at the end of that event packet. The timestamp at the
> +    beginning of an event packet is guaranteed to be above or equal the

"greater than or equal to"

> +    timestamps at the beginning of any prior packet within the same
> +    stream. The timestamp at the end of an event packet is guaranteed to
> +    be below or equal the timestamps at the end of any following packet

"less than or equal to"

Phil

> +    within the same stream. See [Clocks](#spec8) for more detail.
>   * **Events discarded count**. Snapshot of a per-stream
>     free-running counter, counting the number of events discarded that
>     were supposed to be written in the stream after the last event in
> --
> 2.11.0

[lttng-dev] [RFC PATCH CTF 2/3] Clarify monotonicity requirement on timestamp begin

[Mathieu Desnoyers]

----- On Apr 28, 2020, at 2:42 PM, Philippe Proulx pproulx at efficios.com wrote:

> ----- Original Message -----
>> From: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
>> To: "gbastien+lttng" <gbastien+lttng at versatic.net>, "Matthew Khouzam"
>> <matthew.khouzam at ericsson.com>,
>> diamon-discuss at linuxfoundation.org, pproulx at efficios.com, "Jeremie Galarneau"
>> <jgalar at efficios.com>
>> Cc: "lttng-dev" <lttng-dev at lists.lttng.org>, "Mathieu Desnoyers"
>> <mathieu.desnoyers at efficios.com>
>> Sent: Thursday, 23 April, 2020 16:52:25
>> Subject: [RFC PATCH CTF 2/3] Clarify monotonicity requirement on timestamp begin
> 
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
>> ---
>> common-trace-format-specification.md | 10 ++++++----
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>> 
>> diff --git a/common-trace-format-specification.md
>> b/common-trace-format-specification.md
>> index f5fea51..53b70f4 100644
>> --- a/common-trace-format-specification.md
>> +++ b/common-trace-format-specification.md
>> @@ -836,10 +836,12 @@ TSDL metadata):
>>     range between these timestamps should include all event timestamps
>>     assigned to events contained within the packet. The timestamp at the
>>     beginning of an event packet is guaranteed to be below or equal the
>> -    timestamp at the end of that event packet. The timestamp at the end
>> -    of an event packet is guaranteed to be below or equal the
>> -    timestamps at the end of any following packet within the same stream.
>> -    See [Clocks](#spec8) for more detail.
>> +    timestamp at the end of that event packet. The timestamp at the
>> +    beginning of an event packet is guaranteed to be above or equal the
> 
> "greater than or equal to"

done

> 
>> +    timestamps at the beginning of any prior packet within the same
>> +    stream. The timestamp at the end of an event packet is guaranteed to
>> +    be below or equal the timestamps at the end of any following packet
> 
> "less than or equal to"

done,

Thanks!

Mathieu

> 
> Phil
> 
>> +    within the same stream. See [Clocks](#spec8) for more detail.
>>   * **Events discarded count**. Snapshot of a per-stream
>>     free-running counter, counting the number of events discarded that
>>     were supposed to be written in the stream after the last event in
>> --
> > 2.11.0

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

[lttng-dev] [RFC PATCH CTF 3/3] Clarify that timestamp begin/end need to be complete clock values

[Mathieu Desnoyers]

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
---
 common-trace-format-specification.md | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/common-trace-format-specification.md b/common-trace-format-specification.md
index 53b70f4..7681ce5 100644
--- a/common-trace-format-specification.md
+++ b/common-trace-format-specification.md
@@ -1580,7 +1580,8 @@ stream {
 };
 ~~~
 
-For a N-bit integer type referring to a clock, if the integer overflows
+Within the stream event context, event context, and event payload,
+fields of N-bit integer type referring to a clock, if the integer overflows
 compared to the N low order bits of the clock prior value found in the
 same stream, then it is assumed that one, and only one, overflow
 occurred. It is therefore important that events encoding time on a small
@@ -1589,8 +1590,8 @@ N-bit overflow occurs.
 
 In a packet context, clock field names ending with `_begin` and `_end`
 have a special meaning: this refers to the timestamps at, respectively,
-the beginning and the end of each packet.
-
+the beginning and the end of each packet. Those are required to be
+complete representations of the clock value.
 
 ## A. Helper macros
 
-- 
2.11.0