Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError

From: Paul Aitken <[email-masked]>
Date: Thu, 07 Aug 2008 09:57:22 +0100

Tanja,

> Hi Benoit and Paul,
> 
>  
> 
> here my suggestions for clarification of the error IEs in PSAMP-INFO.
> 
> -    I suggest to rename the fixedError to absoluteError

Agreed.

> -    I suggest to introduce CI limits and level to also report 
> estimation errors
> 
> -    If it is still possible I would suggest to make a few small changes 
> in PSAMP-PROTO for consistency.
> 
> -    Upper and lower CI limits can be also specified as provided 
> absolute or relative limits. So we could also add 2 more IEs (for the 
> relative CI limits)
> 
>  
> 
> New description of IEs:
> 
>  
> 
> absoluteError
> 
> This Information Element specifies the maximum possible measurement 
> error of the reported value for a given Information Element. The 

We should indicate how to connect the *Error values to specific fields, 
eg by using an option with the specific field as scope. Else, someone 
may put the *Error elements adjacent to the relative fields in the data 
record - which could work, but is open to misinterpretation.

> absoluteError has the same unit as the information element it is 
> associated to. The real value of the metric can differ by absoluteError 

"with" ------^^

> (positive or negative) from the measured value. This information element 
> provides only the error for measured values. If an information element 
> contains an estimated values (from sampling) the confidence boundaries 
> and confidence level have to be provided instead.

I would name the IEs: "the confidence boundaries and confidence level 
have to be provided instead (with the upperCILimit, lowerCILimit and 
confidenceLevel).

> relativeError
> 
> This Information Element specifies the maximum possible measurement 
> error of the reported value for a given Information Element as 
> percentage of the measured value. The real value of the metric can 
> differ by relativeError percent (positive or negative) from the measured 
> value. This information element provides only the error for measured 
> values. If an information element contains an estimated values (from 
> sampling) the confidence boundaries and confidence level have to be 
> provided instead.

Again, as above, I would specifically name the IEs for this.

> upperCILimit
> 
> This Information Element specifies the upper limit of a confidence 
> interval. It is used to provide an accuracy statement for an estimated 
> value. The confidence limits define the range in which the real value is 
> assumed to be with a certain probability p. Confidence limits always 
> need to be associated with a confidence level that defines this 
> probability p. Please note that a confidence interval only provides a 
> probability that the real values lies within the limits. That means the 
> real value can lie outside the confidence limits.
>
>
>
> lowerCILimit
> 
> This Information Element specifies the lower limit of a confidence 
> interval. For further information see the description of upperCILimit.
> 
>  
> 
> confidenceLevel
> 
> This Information Element specifies the confidence level. It is used to 
> provide an accuracy statement for estimated values. The confidence level 
> provides the probability p with which the real value lies within a given 
> range. A confidence level always needs to be associated with confidence 
> limits that define the range in which the real value is assumed to be.

We should specify that upperCILimit, lowerCILimit and confidenceLevel 
are all required, and what to do if too few of them are provided.

> Changes to PSAMP-PROTO if still possible:
> 
>  
> 
> -    Rename fixedError to absoluteError
> 
> -    Slightly modify paragraph 2
> 
> OLD:
> 
> ...  The accuracy SHOULD be reported either with the fixedError 
> Information Element [PSAMP-INFO 
> <http://tools.ietf.org/html/draft-ietf-psamp-protocol-09#ref-PSAMP-INFO>], 
> or with the relativeError Information Element [PSAMP-INFO 
> <http://tools.ietf.org/html/draft-ietf-psamp-protocol-09#ref-PSAMP-INFO>].
> 
> NEW:
> 
> ... The accuracy for a measured information elelment SHOULD be reported 
> either with the fixedError Information Element [PSAMP-INFO 
> <http://tools.ietf.org/html/draft-ietf-psamp-protocol-09#ref-PSAMP-INFO>], 
> or with the relativeError Information Element [PSAMP-INFO 
> <http://tools.ietf.org/html/draft-ietf-psamp-protocol-09#ref-PSAMP-INFO>]. 
> The accuracy for an estimated information element (from sampling) SHOULD 
> be reported with confidence limits and confidence level.[PSAMP-INFO]

Agreed. I'd also like to add something indicating how this can be done, 
eg by using an option with the correct scope.

> 
>  
> 
> -    Remove the following paragraph (very important! Otherwise it would 
> lead to confusion):
> 
> For example, the accuracy of an Information Element to estimate the 
> accuracy of a sampled flow, for which the unit would be specified in 
> octets, can be specified with the relativeError Information Element with 
> the octet units.  In this case, the error interval is the Information 
> Element value +/- the value reported in the relativeError times the 
> reported Information Element value.
> 
>  
> 
> -    Avoid the term error interval
> 
> OLD:
> 
> In this case, the error interval is the Information Element value +/- 
> the value reported in the fixedError.
> 
> NEW:
> 
> In this case, the real values lies within the range of the Information 
> Element value +/- the value reported in the absoluteError.
> 
>  
> 
>  
> 
> -    Remove the following paragraph (since absolute or relative error 
> are just different representations I would not gain something if I 
> report both)
> 
> Alternatively to reporting either the fixedError Information Element or 
> the relativeError Information Element in the Accuracy Report 
> Interpretation, both Information Elements MAY be present.  This scenario 
> could help in more complex situations where the system clock drifts, on 
> the top of having its own accuracy, during the duration of a measurement.

The intention was to say that the clock is 5 minutes slow, +/- 10 
seconds - so there's both an absolute error and a relative error.

> Sorry for the late comments, I was quite busy with PSAMP-TECH before...

Thanks for your input!

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.
_______________________________________________
PSAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/psamp

---

From: "Zseby, Tanja" <[email-masked]>
Date: Fri, 8 Aug 2008 15:31:48 +0200

Hi Paul,

see comments below.

> -----Original Message-----
> From: Paul Aitken [mailto:[email-masked]]
> Sent: Thursday, August 07, 2008 10:57 AM
> To: Zseby, Tanja
> Cc: Benoit Claise; psamp; Juergen Quittek
> Subject: Re: PSAMP-INFO IE realtiveError
> 
> Tanja,
> 
> > Hi Benoit and Paul,
> >
> >
> >

Maybe I don't understand the comment correctly. Isnt the usage explained
in the example in PSAMP-PROTO? The error can also be applied to relative
values.

> > associated to. The real value of the metric can differ by

? Where to put the with?

> 
> > (positive or negative) from the measured value. This information
> > element provides only the error for measured values. If an
> information
> > element contains an estimated values (from sampling) the confidence
> > boundaries and confidence level have to be provided instead.
> 

o.k.

> > differ by relativeError percent (positive or negative) from the
> > measured value. This information element provides only the error for
> > measured values. If an information element contains an estimated
> > values (from

again o.k.

> > value. The confidence limits define the range in which the real
value
> > is assumed to be with a certain probability p. Confidence limits
> > always need to be associated with a confidence level that defines
> this
> > probability that the real values lies within the limits. That means
> > the real value can lie outside the confidence limits.
> >
> >
> >
> > lowerCILimit
> >
> > provide an accuracy statement for estimated values. The confidence
> > level provides the probability p with which the real value lies
> within
> > a given range. A confidence level always needs to be associated with
> > confidence limits that define the range in which the real value is
> assumed to be.
> 

Maybe just a sentence: "All three values (upperCILimit, lowerCILimit and
confidenceLevel) are necessary to provide an complete accuracy
statement."

I think the checking for the complete accuracy statement as out of scope
for IPFIX/PSAMP. I think this is something that the applications that
requires the statement should check. So I would consider no mandatory
action by collector.

> eg by using an option with the correct scope.

o.k. Maybe you can add a sentence for this?

> seconds - so there's both an absolute error and a relative error.

NOW I finally understand what you meant by fixedError initially !!
This I would not consider as error. Any fixed deviation I would rather
name "offset"...
If it is known couldn't you add it to the value and report the correct
time?
Or maybe check whether the NTP and TICTOC have a term for this...

Kind regards
Tanja

---

From: Paul Aitken <[email-masked]>
Date: Fri, 08 Aug 2008 15:05:27 +0100

Tanja,

> in the example in PSAMP-PROTO? The error can also be applied to relative

Either in the description for these fields, or at least in the title for 
the section, we should indicate that they should be used for the 
"Accuracy Report Interpretation" in PSAMP-PROTO.

>>> associated to. The real value of the metric can differ by

Before the wrapping, the ^^ originally pointed to "to" - ie "to" -> "with".

> requires the statement should check. So I would consider no mandatory

If the *Error elements are provided in an option (eg, the Accuracy 
Report Interpretation) then the collector can obviously ignore them.

But that's not the only way to use them. What if they appeared right in 
a data record - and there weren't enough of them? Should the collector 
ignore the entire data record?

> o.k. Maybe you can add a sentence for this?

It should be per the "Accuracy Report Interpretation" in PSAMP-PROTO - 
which should be updated to include these new IEs.

> If it is known couldn't you add it to the value and report the correct

In that case there would be no need to ever report "absoluteError" - 
because all the original measurements can be corrected before being 
exported.

However, it may be we want to export the actual observed value, rather 
than a corrected value.

> Or maybe check whether the NTP and TICTOC have a term for this...

We need a generic solution that works for all different kinds of IEs, 
not just for time.

Thanks.

---

From: "Zseby, Tanja" <[email-masked]>
Date: Fri, 8 Aug 2008 16:28:31 +0200

Hi Paul,

> Sent: Friday, August 08, 2008 4:05 PM
> To: Zseby, Tanja
> >> We should indicate how to connect the *Error values to specific
> >> fields, eg by using an option with the specific field as scope.
> Else,
> >> someone may put the *Error elements adjacent to the relative fields
> >> in the data record - which could work, but is open to
> misinterpretation.
> >
> > Maybe I don't understand the comment correctly. Isnt the usage
> > explained in the example in PSAMP-PROTO? The error can also be
> applied
> > to relative values.
> 
> Either in the description for these fields, or at least in the title
> for the section, we should indicate that they should be used for the

o.k. maybe just put the sentence "The fields absoluteError, fixedError,
upperCILimit, lowerCILimit and confidenceLevel are used in the Accuracy
Report Interpretation as described in PSAMP-PROTO."

> Before the wrapping, the ^^ originally pointed to "to" - ie "to" ->
Ah now I see :-) o.k.
 
> > I think the checking for the complete accuracy statement as out of
> > scope for IPFIX/PSAMP. I think this is something that the
> applications
> > that requires the statement should check. So I would consider no
> > mandatory action by collector.
> 

No I think the collector does not need to take care of this since there
is nothing wrong with the reporting itself just that the reported values
may be useless due to an incomplete accuracy statement. But I think this
is something the application should check.

> >>> NEW:
> >>>
> >>> ... The accuracy for a measured information elelment SHOULD be
> >>> reported either with the fixedError Information Element
[PSAMP-INFO
<http://tools.ietf.org/html/draft-ietf-psamp-protocol-09#ref-PSAMP-
> I
> >>> NFO>], or with the relativeError Information Element [PSAMP-INFO
> >>>
<http://tools.ietf.org/html/draft-ietf-psamp-protocol-09#ref-PSAMP-
> INFO>].
> >>> The accuracy for an estimated information element (from sampling)
> >>> SHOULD be reported with confidence limits and confidence
> >>> level.[PSAMP-INFO]
> >>

Maybe for clarification:
The absoluteError that I propose is different from what you intended by
fixedError. absoluteError is a maximum error that you would expect due
to the inaccurate measurement (e.g. the timestamp may vary by +/- 5 ms).
The real error that you make during measurements is unknown and can
vary. Your fixedError is different. It is a fixed and known offset for
the measured values, correct?

Kind regards
Tanja

---

From: Andrew Johnson <[email-masked]>
Date: Fri, 08 Aug 2008 16:14:02 +0100

[SNIP]
> the measured values, correct?

I think the absoluteError is the same as the originally fixedError.  In
Paul's example above the fixedError was +/- 10 seconds.  I'm not sure
how you would communicate the "5 minutes slow" part...

The original idea was fixedError would say this is accurate to within X
units.  Both the fixed and the absolute error can be used together, but
you just have to go with the least accurate one.  For example, if my
bathroom scales have a fixed error of 0.25kg and a relative error of
0.5%, then they can weigh a person very accurate, but are rubbish for
weighing mice:
  Person1:   81.50kg +/- 0.4kg
  Mouse1:     0.25kg +/ 0.25kg

Cheers

Andrew

---

From: "Zseby, Tanja" <[email-masked]>
Date: Fri, 8 Aug 2008 18:07:49 +0200

Hi Andrew,

lets first forget about the fixed error and say we agree that we need
something like an absolute error that defines the maximum error that can
happen at each measurement (given the real error is unknown). 
Then it was unclear for me why you report this together with a relative
error which provides exactly the same information but only as percentage
of the measured value. It is only for convenience that we can report
either format.

relError=abserror/measured value

e.g. you can e.g. say: The absolute error is +/- 0.2 kg:
Person:   80.50kg +/- 0.2kg
Mouse:     0.50 kg +/- 0.2kg

That corresponds to the relative errors:
Person:   0.249 %
Mouse:   40%

Or you could say: The relative error is +/- 10 %. Then you get the
corresponding absolute errors:
Person:   80.50kg +/- 8.05 kg
Mouse:     0.50 kg +/ 0.05 kg

If this is o.k., the second question would be:  do we need something
like an offset/fixed error ?
e.g. Offset: 0.25
Person (real value):   80.50kg 
Person (measured):     80.75kg 

Mouse (real value):   0.50 kg 
Mouse (measured):     0.75 kg 

The only thing that might be confusing is if you have an offset and
report it together with a relative error, since the  relative error
should still refer to the real value (without offset). But we probably
do not need the offset value. 

Hope this was not even more confusing...

Kind regards
Tanja (starting to see white mice)

> From: Andrew Johnson [mailto:[email-masked]]
> Sent: Friday, August 08, 2008 5:14 PM
> To: Zseby, Tanja
> Cc: Paul Aitken; psamp; Juergen Quittek
> Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError
> 
> [SNIP]
> > The absoluteError that I propose is different from what you intended
> > by fixedError. absoluteError is a maximum error that you would
expect
> > due to the inaccurate measurement (e.g. the timestamp may vary by
+/-
> 5 ms).

---

From: Andrew Johnson <[email-masked]>
Date: Fri, 08 Aug 2008 19:48:13 +0100

> That corresponds to the relative errors:

In the Accuracy Report Interpretation you only provide one accuracy for
the field, you don't report the accuracy per measurement.  The idea is
to provide the margin of error for all measurements of a certain type.

The only use of the error field types that was originally intended was
in the Accuracy Report Interpretation, where the error is scoped to the
field (and optionally template).  Unless you use a new template per
record I'm not sure how you would scope the error value to an individual
measurement.

> do not need the offset value. 

I don't think we have any need for an offset.

> Hope this was not even more confusing...

I think I understand how you may have misunderstood how the error IEs
were intended to be used.  I hope I'm making things clearer... perhaps
the draft needs some clarification.

Cheers

Andrew

---

From: "Zseby, Tanja" <[email-masked]>
Date: Sat, 9 Aug 2008 01:19:05 +0200

Hi Andrew,

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Andrew Johnson
> Sent: Friday, August 08, 2008 8:48 PM
> To: Zseby, Tanja
> Cc: psamp; Juergen Quittek
> > something like an absolute error that defines the maximum error that
> > can happen at each measurement (given the real error is unknown).
> > Then it was unclear for me why you report this together with a
> > relative error which provides exactly the same information but only
> as
> > percentage of the measured value. It is only for convenience that we
> > can report either format.
> >
> record I'm not sure how you would scope the error value to an
> individual measurement.

But this is absolutely in-line with the above. You can provide one
absolute error for all timestamps or all byte measurements (or all
weight measurements). With this you say what is the maximum error when
measuring the timestamp or bytes. This maximum error usually depends on
the measurement method and therefore the absolute error (= the maximum
possible error) is usually the same for all of the values measured with
this method. I think this is exactly the same that you want to express,
correct? 

> I don't think we have any need for an offset.

o.k. I agree.

> the draft needs some clarification.

I think we have the same understanding (see above). The absoluteError
gives the maximum value from which a measured value can differ from the
real value. The error is usually bound to the measurement method or
system (i.e. the same for subsequent values).

Kind regards,
Tanja

> > > > > >> The intention was to say that the clock is 5 minutes slow,
> > > > > >> +/-
> > > 10
> > > > > > NOW I finally understand what you meant by fixedError
> > > > > > initially
> > > !!
> > > > > > This I would not consider as error. Any fixed deviation I
> > > > > > would
> > > > > rather
> > > > > > name "offset"...
> > > > > > If it is known couldn't you add it to the value and report
> the
> > > > > correct
> > > > > > time?
> > > > >
> > > > > In that case there would be no need to ever report
> "absoluteError"
> > > -
> > > > The absoluteError that I propose is different from what you
> > > > intended by fixedError. absoluteError is a maximum error that
you
> > > > would
> > > > The real error that you make during measurements is unknown and
> > > > can vary. Your fixedError is different. It is a fixed and known
> > > > offset
> > > for
> > > I think the absoluteError is the same as the originally
fixedError.
> > In
> > > Paul's example above the fixedError was +/- 10 seconds.  I'm not
> > > sure how you would communicate the "5 minutes slow" part...
> > >
> > > The original idea was fixedError would say this is accurate to
> > > within
> > X
> > > units.  Both the fixed and the absolute error can be used
together,
> > but
> > > 0.5%, then they can weigh a person very accurate, but are rubbish
> > > for weighing mice:

---

From: Andrew Johnson <[email-masked]>
Date: Wed, 13 Aug 2008 23:12:58 +0100

Hi Tanja

> this method. I think this is exactly the same that you want to express,

Ah I see what you mean now.  In general I think that only one type of
error will be reported at once and that most of the time that will be an
absolute error.

I think there is still value in providing a way to express a relative
error though.  For example, clocks tend to drift over time so the larger
the time measurement the larger the error, i.e. accurate to within 1
second per day is 0.0011574%.

Cheers

Andrew

---

From: "Zseby, Tanja" <[email-masked]>
Date: Thu, 14 Aug 2008 15:03:10 +0200

Hi Andrew,

great. So it seems that after a lot of mice stepping on and off the
scale we have a common understanding of the terms :-)
So to summarize:
- we don't need an offset IE
- we definitely include the absoluteError IE
- we can also include the relativeError IE (maybe you as authors
decide?)  

Kind regards
Tanja

> Sent: Thursday, August 14, 2008 12:13 AM
> To: Zseby, Tanja
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Andrew Johnson
> > > > something like an absolute error that defines the maximum error
> > > > that can happen at each measurement (given the real error is
> unknown).
> > > > percentage of the measured value. It is only for convenience
that
> > > > we can report either format.
> > > >
> > > In the Accuracy Report Interpretation you only provide one
accuracy
> > for
> > > the field, you don't report the accuracy per measurement.  The
idea
> > > is to provide the margin of error for all measurements of a
certain
> type.
> > >
> > > The only use of the error field types that was originally intended
> > > was in the Accuracy Report Interpretation, where the error is
> scoped
> > > to
> > the
> > measuring the timestamp or bytes. This maximum error usually depends
> > on the measurement method and therefore the absolute error (= the
> > maximum possible error) is usually the same for all of the values
> > measured with this method. I think this is exactly the same that you
> > want to express, correct?
> 
> error will be reported at once and that most of the time that will be
> an absolute error.
> 
> error though.  For example, clocks tend to drift over time so the
> larger the time measurement the larger the error, i.e. accurate to
> within 1 second per day is 0.0011574%.
> 
> Cheers
> 
> Andrew
> 
> 
> > >
> > >
> > > > If this is o.k., the second question would be:  do we need
> > > > something like an offset/fixed error ?
> > > > e.g. Offset: 0.25
> > > > The only thing that might be confusing is if you have an offset
> > > > and report it together with a relative error, since the
relative
> > > > error should still refer to the real value (without offset). But
> > > > we
> > > probably
> > > I think I understand how you may have misunderstood how the error
> > > IEs were intended to be used.  I hope I'm making things clearer...
> > > perhaps the draft needs some clarification.
> >
> > gives the maximum value from which a measured value can differ from
> > the real value. The error is usually bound to the measurement method
> > or system (i.e. the same for subsequent values).
> >
> > Kind regards,
> > Tanja
> >
> > >
> > > Cheers
> > >
> > > Andrew
> > >
> > >
> > > > Kind regards
> > > > > > > >> seconds - so there's both an absolute error and a
> > > > > > > >> relative
> > > > > error.
> > > > > > > >>
> > > > > > > >
> > > > > > > because all the original measurements can be corrected
> > > > > > > before
> > > > being
> > > > > > > exported.
> > > > > >
> > > > > > Maybe for clarification:
> > > > > > due to the inaccurate measurement (e.g. the timestamp may
> vary
> > by
> > > > +/-
> > > > > 5 ms).
> > > > > > The real error that you make during measurements is unknown
> > > > > > and can vary. Your fixedError is different. It is a fixed
and
> > > > > > known offset
> > > > > you just have to go with the least accurate one.  For example,
> > > > > if
> > > my
> > > > > bathroom scales have a fixed error of 0.25kg and a relative
> > > > > error
> > > of
> > > > > 0.5%, then they can weigh a person very accurate, but are
> > > > > rubbish for weighing mice:

---

From: "Thomas Dietz" <[email-masked]>
Date: Thu, 14 Aug 2008 15:25:35 +0200

Hi Tanja, Andrew, Paul,

since the topic seems to be settled now can you please summarize your
discussion in this thread? I would like to know what to put into an updated
version of the draft so that it can get published asap.

Best Regards,

Thomas

-- 
Thomas Dietz                 E-mail: [email-masked]
NEC Europe Ltd.              Phone:  +49 6221 4342-128
NEC Laboratories Europe      Fax:    +49 6221 4342-155
Network Research Division
Kurfuersten-Anlage 36
69115 Heidelberg, Germany    http://www.nw.neclab.eu

NEC Europe Limited           Registered in England 2832014
Registered Office: NEC House, 1 Victoria Road, London W3 6BL

> Of Zseby, Tanja
> Sent: Donnerstag, 14. August 2008 15:03
> To: Andrew Johnson
> Behalf
> > > > > lets first forget about the fixed error and say we agree that
> we
> > > need

---

From: Andrew Johnson <[email-masked]>
Date: Thu, 14 Aug 2008 14:37:01 +0100

Hi Thomas

I don't think much has changed.  If I filter out the misunderstandings I
think you get something like this:

Tanja:    What's this fixedError thing for?
Paul:     It's the uncertainty of the measurement expressed as a fixed
          amount of the measured units.
Tanja:    That's a confusing name, let's call it absoluteError.
Everyone: OK.
Tanja:    Why do we even need relativeError then?
Andrew:   I think it might be useful for certain measurement devices.
Tanja:    OK, well keep it if you want.

In conclusion, fixedError is now called absoluteError and we'll keep
relativeError in case it's needed.

For those who followed the thread, does that sound fair?

Cheers

Andrew

---

From: "Zseby, Tanja" <[email-masked]>
Date: Thu, 14 Aug 2008 15:44:11 +0200

Hi Thomas and Andrew,

I agree. But I also would add the confidence boundaries levels and the
small changes in PSAMP-PROTO as suggested in my first mail. 
But those changes were mainly agreed by the authors, correct? 

Kind regards
Tanja

> Sent: Thursday, August 14, 2008 3:37 PM
> To: Thomas Dietz
> Cc: Zseby, Tanja; Paul Aitken; psamp; Juergen Quittek
> Subject: RE: [PSAMP] PSAMP-INFO IE realtiveError
> 
> Hi Thomas
> 
> I don't think much has changed.  If I filter out the misunderstandings
> I think you get something like this:
> 
> > discussion in this thread? I would like to know what to put into an
> > updated version of the draft so that it can get published asap.
> >
> > Best Regards,
> >
> > Thomas
> >
> > --
> > > Behalf Of Zseby, Tanja
> > > scale we have a common understanding of the terms :-) So to
> > > summarize:
> > > > > > From: [email-masked] [mailto:[email-masked]]
> > > > > > On Behalf Of Andrew Johnson
> > > > > > > something like an absolute error that defines the maximum
> > > > > > > error that can happen at each measurement (given the real
> > > > > > > error is
> > > > unknown).
> > > > > > > Then it was unclear for me why you report this together
> with
> > > > > > > a relative error which provides exactly the same
> information
> > > > > > > but only
> > > > > > as
> > > > > > field (and optionally template).  Unless you use a new
> > > > > > template
> > > per
> > > > > But this is absolutely in-line with the above. You can provide
> > > > > one absolute error for all timestamps or all byte measurements
> > > > > (or all weight measurements). With this you say what is the
> > > > > maximum error
> > > > when
> > > > > on the measurement method and therefore the absolute error (=
> > > > > the maximum possible error) is usually the same for all of the
> > > > > values measured with this method. I think this is exactly the
> > > > > same that
> > > you
> > > > Ah I see what you mean now.  In general I think that only one
> type
> > > > of error will be reported at once and that most of the time that
> > > > will be an absolute error.
> > > >
> > > > I think there is still value in providing a way to express a
> > > > relative error though.  For example, clocks tend to drift over
> > > > time so the larger the time measurement the larger the error,
> i.e.
> > > > accurate to within 1 second per day is 0.0011574%.
> > > >
> > > > Cheers
> > > >
> > > > Andrew
> > > >
> > > >
> > > > > >
> > > > > >
> > > > > > > Or you could say: The relative error is +/- 10 %. Then you
> > > > > > > get
> > > > the
> > > > > > > The only thing that might be confusing is if you have an
> > > > > > > offset and report it together with a relative error, since
> > > > > > > the
> > > relative
> > > > > > > error should still refer to the real value (without
> offset).
> > > But
> > > > > > > we
> > > > > > probably
> > > > > > I think I understand how you may have misunderstood how the
> > > > > > error IEs were intended to be used.  I hope I'm making
things
> > > clearer...
> > > > > gives the maximum value from which a measured value can differ
> > > > > from the real value. The error is usually bound to the
> > > > > measurement
> > > method
> > > > > > > > > > > NOW I finally understand what you meant by
> > > > > > > > > > > fixedError initially
> > > > > > > > !!
> > > > > > > > > > > This I would not consider as error. Any fixed
> > > > > > > > > > > deviation
> > > I
> > > > > > > > > > > would
> > > > > > > > > > rather
> > > > > > > > > > > name "offset"...
> > > > > > > > > > > If it is known couldn't you add it to the value
and
> > > > report
> > > > > > > > > The absoluteError that I propose is different from
what
> > > > > > > > > you intended by fixedError. absoluteError is a maximum
> > > > > > > > > error
> > > that
> > > > > you
> > > > > > > > > would
> > > > > > > expect
> > > > > > > > > The real error that you make during measurements is
> > > > > > > > > unknown and can vary. Your fixedError is different. It
> > > > > > > > > is a fixed
> > > and
> > > > > > > > > known offset
> > > > > > > > for
> > > > > > > > Paul's example above the fixedError was +/- 10 seconds.
> > > > > > > > I'm
> > > > not
> > > > > > > > The original idea was fixedError would say this is
> > > > > > > > accurate
> > > to
> > > > > > > > within
> > > > > > > X
> > > > > > > > bathroom scales have a fixed error of 0.25kg and a
> > > > > > > > relative error
> > > > > > of

---

From: Paul Aitken <[email-masked]>
Date: Thu, 14 Aug 2008 14:47:24 +0100

Andrew,

> For those who followed the thread, does that sound fair?

Yes.

Tanja,

> But those changes were mainly agreed by the authors, correct? 

Yes.