Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #24919

Re: Instrumentation question.

Subject Re: Instrumentation question.
Newsgroups comp.arch.embedded
References <nqo9eb$9ti$1@dont-email.me> <xEPzz.149439$7k5.143805@fx38.am4> <nqpkpe$sar$1@dont-email.me>
From Tom Gardner <spamjunk@blueyonder.co.uk>
Message-ID <Go0Az.176349$7k5.157150@fx38.am4> (permalink)
Organization virginmedia.com
Date 2016-09-07 23:20 +0100

Show all headers | View raw


On 07/09/16 19:10, Les Cargill wrote:
> Tom Gardner wrote:
>> On 07/09/16 06:50, Les Cargill wrote:
>>> I've always suspected there was something clever that I could use for
>>> a thing
>>> like this, but ... I was too afraid to ask about it.
>>>
>>> Suppose I am on an extremely deterministic platform.
>>>
>>> Suppose I can calculate the number of microsconds it takes to call
>>> something[1].
>>>
>>> Suppose I can check and calculate things about this count every <n>
>>> seconds.
>>>
>>> Suppose also that there are two cases for "something" :
>>>
>>> - There is nothing to do.
>>> - There is something to do. "Something" is constrained to "one thing"
>>> by design.
>>>
>>> Let's also assume I can (cheaply) calculate the minimum and maximum
>>> number of
>>> microseconds to do either of "nothing" or "something".
>>>
>>> Obviously a histogram is in order. But wait!.
>>>
>>> It seems to me that I should be able to estimate a histogram based on:
>>> - minimum time
>>> - maximum time
>>> - average time.
>>>
>>> What is this sort of ... inquiry called, and how do I stop being quite
>>> so dull about it?
>>>
>>> [1] I suspect that one answer is to extend the number of buckets
>>> into more finely grained measurements of sub-operations of "something".
>>> Example: a check for "serial port has data" vs. "relieve one unit from
>>> serial
>>> port" vs the overhead from all the dance surrounding those two.
>>
>> Latencies are usually displayed in the form of a
>> cumulative distribution function, where the x-axis
>> is time and the y-axis range is 0 to 1 indicating
>> the probability that the latency is less than the
>> time on the x-axis. Effectively the CDF is the
>> integral of the PDF.
>>
>> Either the PDF or CDF will show multimodal
>> distributions and extreme values.
>>
>> For hard real-time systems either the absolute min
>> or max is necessary. For soft real-time systems the
>> 5th or 95th percentile is more useful. (or 1/99th
>> percentile etc).
>>
>> With the CDF it is trivial to read off the various
>> percentiles.
>
>
> That may be something I try, but for now, even a simple CDF
> requires a lot of RAM for a target with 8K main memory:)
>
> But I'll continue playing with it.

You store the PDF, and compute the CDF when needed.
The range and resolution translates directly into
the number of "buckets", and the number of bits in
each bucket is determined by the number of samples.
No surprises there.

Sometimes pulsing an output line high during the
interval, and averaging with an RC filter is
sufficient.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

Instrumentation question. Les Cargill <lcargill99@comcast.com> - 2016-09-07 00:50 -0500
  Re: Instrumentation question. Paul Rubin <no.email@nospam.invalid> - 2016-09-07 00:05 -0700
    Re: Instrumentation question. Les Cargill <lcargill99@comcast.com> - 2016-09-07 13:07 -0500
  Re: Instrumentation question. Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-09-07 08:49 +0100
    Re: Instrumentation question. Les Cargill <lcargill99@comcast.com> - 2016-09-07 13:10 -0500
      Re: Instrumentation question. Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-09-07 23:20 +0100

csiph-web