Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #24919
| 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 |
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
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