typically stupid ED article

On Wed, 2 Sep 2020 07:42:42 +0100, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

>On 02/09/20 02:12, whit3rd wrote:
>> On Tuesday, September 1, 2020 at 5:38:58 PM UTC-7, John Larkin wrote:
>> 
>>> "Any OS is an RTOS if it's fast enough."
>> 
>> Not true.   Our-of-order execution and uncontrolled interrupts are
>> tools of Finagle and his gremlins.
>
>Don't forget the effect of caches, which improve the /average/
>execution time.
>
>Strictly speaking, John's statement is correct. But the problem
>is /proving/ it is "fast enough".

I measured the Linux performance with an oscilloscope. My programmer
couldn't estimate timing within a factor of 20 or so. I have to push
him to do terrifying stuff like interrupting at 4 KHz. I did useful 20
KHz interrupts on a 68332, roughly one cent of the power in the Zynq.



-- 

John Larkin         Highland Technology, Inc

Science teaches us to doubt.

  Claude Bernard
  

On Wed, 2 Sep 2020 07:36:28 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>On 2020-09-01 12:49, piglet wrote:
>> On 01/09/2020 16:11, jlarkin@highlandsniptechnology.com wrote:
>>>
>>>
>>> https://www.electronicdesign.com/technologies/test-measurement/whitepaper/21140081/warning-your-dmm-is-discharging-your-battery-cell?utm_source=EG+ED+Today&utm_medium=email&utm_campaign=CPS200828010&o_eid=7322A4702401H9R&rdx.ident%5Bpull%5D=omeda%7C7322A4702401H9R&oly_enc_id=7322A4702401H9R 
>>>
>>>
>>> It's sad how bad the electronics press has become.
>>>
>>>
>>>
>> 
>> Ten gigaohms!? I want one that goes to eleven.
>> 
>> piglet
>> 
>
>Another Tap on the voltage divider.
>
>Cheers
>
>Phil Hobbs

Even a 10M input, $20 DVM is a decent picoammeter.



-- 

John Larkin         Highland Technology, Inc

Science teaches us to doubt.

  Claude Bernard
  

On 02/09/20 15:33, jlarkin@highlandsniptechnology.com wrote:
> On Wed, 2 Sep 2020 07:42:42 +0100, Tom Gardner
> <spamjunk@blueyonder.co.uk> wrote:
> 
>> On 02/09/20 02:12, whit3rd wrote:
>>> On Tuesday, September 1, 2020 at 5:38:58 PM UTC-7, John Larkin wrote:
>>>
>>>> "Any OS is an RTOS if it's fast enough."
>>>
>>> Not true.   Our-of-order execution and uncontrolled interrupts are
>>> tools of Finagle and his gremlins.
>>
>> Don't forget the effect of caches, which improve the /average/
>> execution time.
>>
>> Strictly speaking, John's statement is correct. But the problem
>> is /proving/ it is "fast enough".
> 
> I measured the Linux performance with an oscilloscope. My programmer
> couldn't estimate timing within a factor of 20 or so. I have to push
> him to do terrifying stuff like interrupting at 4 KHz. I did useful 20
> KHz interrupts on a 68332, roughly one cent of the power in the Zynq.

With anything that isn't bare silicon I'd be reluctant to
give /hard/ realtime guarantees - even with measurement.

The problem is twofold: there's a awful/aweful lot of
/stuff/ in a modern "desktop" OS, and very few people
understand all of the stuff stuffed in there. Plus who
knows what is going to kick off infrequently and even
less frequently at the most inconvenient time.

But then I like bare silicon coding.

Unfortunately, even with bare silicon coding, caches & OoO
can be a problem. They are designed to improve performance
/on average/, but with /hard/ realtime code nobody in their
right mind cares about average. (Soft realtime is fine, and
I've successfully used applications with GC in that mode.)

So, what's the effect of caches on peak/mean performance?
I haven't got any info for a modern processor, but even on
the intel 486 with its tiny caches and non-Out-of-Order
execution, there could be a 5:1 ratio. God only knows
what it is now.

So IMNSHO, linux + Out of Order + caches is not suitable
for interesting *hard* realtime performance.

jlarkin@highlandsniptechnology.com wrote:

> On Wed, 2 Sep 2020 07:36:28 -0400, Phil Hobbs
> <pcdhSpamMeSenseless@electrooptical.net> wrote:
>>Another Tap on the voltage divider.
>>
>>Cheers
>>
>>Phil Hobbs
 
> Even a 10M input, $20 DVM is a decent picoammeter.

Assuming 200 mV on the lowest scale, I get 20 nanoamperes full scale.

On 09/02/20 15:57, Tom Gardner wrote:
> On 02/09/20 15:33, jlarkin@highlandsniptechnology.com wrote:
>> On Wed, 2 Sep 2020 07:42:42 +0100, Tom Gardner
>> <spamjunk@blueyonder.co.uk> wrote:
>>
>>> On 02/09/20 02:12, whit3rd wrote:
>>>> On Tuesday, September 1, 2020 at 5:38:58 PM UTC-7, John Larkin wrote:
>>>>
>>>>> "Any OS is an RTOS if it's fast enough."
>>>>
>>>> Not true. Our-of-order execution and uncontrolled interrupts are
>>>> tools of Finagle and his gremlins.
>>>
>>> Don't forget the effect of caches, which improve the /average/
>>> execution time.
>>>
>>> Strictly speaking, John's statement is correct. But the problem
>>> is /proving/ it is "fast enough".
>>
>> I measured the Linux performance with an oscilloscope. My programmer
>> couldn't estimate timing within a factor of 20 or so. I have to push
>> him to do terrifying stuff like interrupting at 4 KHz. I did useful 20
>> KHz interrupts on a 68332, roughly one cent of the power in the Zynq.
>
> With anything that isn't bare silicon I'd be reluctant to
> give /hard/ realtime guarantees - even with measurement.
>
> The problem is twofold: there's a awful/aweful lot of
> /stuff/ in a modern "desktop" OS, and very few people
> understand all of the stuff stuffed in there. Plus who
> knows what is going to kick off infrequently and even
> less frequently at the most inconvenient time.
>
> But then I like bare silicon coding.
>
> Unfortunately, even with bare silicon coding, caches & OoO
> can be a problem. They are designed to improve performance
> /on average/, but with /hard/ realtime code nobody in their
> right mind cares about average. (Soft realtime is fine, and
> I've successfully used applications with GC in that mode.)
>
> So, what's the effect of caches on peak/mean performance?
> I haven't got any info for a modern processor, but even on
> the intel 486 with its tiny caches and non-Out-of-Order
> execution, there could be a 5:1 ratio. God only knows
> what it is now.
>
> So IMNSHO, linux + Out of Order + caches is not suitable
> for interesting *hard* realtime performance.

In practice, you don't rely software timing for hard real
time work. Long gone are the days where I would count cycles
in interrupt handlers to ensure timer accuracy, but modern cpus
are so fast compared to older 68xxxx and 8 bit processors that
outright performance is rarely an issue. It it is, the system
design is wrong, or you just put a cpu with more welly. It's
easier and less hassle to disable the cpu cache and use just
one core as well.

The last project I worked on had 11 sources of interrupt and
the hard real time requirements meant that a fair bit of processor
time was done in interrupt context. Usually considered dodgy
practice, but the system architecture and processor had already
been chosen and just had to make it work with what was there.
No real time os either, just a state driven loop. Rtos's may be
fashionable, but it's gross overkill for many projects, though
it can force good partitioning and better analysis of the
various subsystems...

Chris

On 01/09/2020 16:48, Phil Hobbs wrote:
> On 2020-09-01 11:11, jlarkin@highlandsniptechnology.com wrote:
>>
>>
>> https://www.electronicdesign.com/technologies/test-measurement/whitepaper/21140081/warning-your-dmm-is-discharging-your-battery-cell?utm_source=EG+ED+Today&utm_medium=email&utm_campaign=CPS200828010&o_eid=7322A4702401H9R&rdx.ident%5Bpull%5D=omeda%7C7322A4702401H9R&oly_enc_id=7322A4702401H9R 
>>
>>
>> It's sad how bad the electronics press has become.
> 
> Good golly, Miss Molly, I'm sure glad he put in that table.  Ohm's law 
> makes my head hurt.

:-) Helps to use up more real estate in the article.

We should go back to old school potentiometer measurements of voltage - 
then no current flows at all when you have balanced the bridge.

I am a bit surprised they use a 10M shunt though. Reliable precision 
100M and 1G resistors are relatively common and have been for ages.

> The guy works at _Keysight_.  "How are the mighty fallen."  Or maybe 
> it's their customers.

Formerly Agilent, formerly HP - do they change company name each time 
there is a body to be buried?

If he was complaining about the load that a Model 7 Avo puts on the 
battery under test which ISTR was 500R/volt then he might have a point. 
They were virtually indestructible though. I still have a mostly working 
one. The ohm's range is shot but current and voltage are fine.

-- 
Regards,
Martin Brown

On 02/09/20 16:45, Chris wrote:
> On 09/02/20 15:57, Tom Gardner wrote:
>> On 02/09/20 15:33, jlarkin@highlandsniptechnology.com wrote:
>>> On Wed, 2 Sep 2020 07:42:42 +0100, Tom Gardner
>>> <spamjunk@blueyonder.co.uk> wrote:
>>>
>>>> On 02/09/20 02:12, whit3rd wrote:
>>>>> On Tuesday, September 1, 2020 at 5:38:58 PM UTC-7, John Larkin wrote:
>>>>>
>>>>>> "Any OS is an RTOS if it's fast enough."
>>>>>
>>>>> Not true. Our-of-order execution and uncontrolled interrupts are
>>>>> tools of Finagle and his gremlins.
>>>>
>>>> Don't forget the effect of caches, which improve the /average/
>>>> execution time.
>>>>
>>>> Strictly speaking, John's statement is correct. But the problem
>>>> is /proving/ it is "fast enough".
>>>
>>> I measured the Linux performance with an oscilloscope. My programmer
>>> couldn't estimate timing within a factor of 20 or so. I have to push
>>> him to do terrifying stuff like interrupting at 4 KHz. I did useful 20
>>> KHz interrupts on a 68332, roughly one cent of the power in the Zynq.
>>
>> With anything that isn't bare silicon I'd be reluctant to
>> give /hard/ realtime guarantees - even with measurement.
>>
>> The problem is twofold: there's a awful/aweful lot of
>> /stuff/ in a modern "desktop" OS, and very few people
>> understand all of the stuff stuffed in there. Plus who
>> knows what is going to kick off infrequently and even
>> less frequently at the most inconvenient time.
>>
>> But then I like bare silicon coding.
>>
>> Unfortunately, even with bare silicon coding, caches & OoO
>> can be a problem. They are designed to improve performance
>> /on average/, but with /hard/ realtime code nobody in their
>> right mind cares about average. (Soft realtime is fine, and
>> I've successfully used applications with GC in that mode.)
>>
>> So, what's the effect of caches on peak/mean performance?
>> I haven't got any info for a modern processor, but even on
>> the intel 486 with its tiny caches and non-Out-of-Order
>> execution, there could be a 5:1 ratio. God only knows
>> what it is now.
>>
>> So IMNSHO, linux + Out of Order + caches is not suitable
>> for interesting *hard* realtime performance.
> 
> In practice, you don't rely software timing for hard real
> time work. Long gone are the days where I would count cycles
> in interrupt handlers to ensure timer accuracy, but modern cpus
> are so fast compared to older 68xxxx and 8 bit processors that
> outright performance is rarely an issue. It it is, the system
> design is wrong, or you just put a cpu with more welly. It's
> easier and less hassle to disable the cpu cache and use just
> one core as well.

Disabling the cache and "surplus" cores is a sensible workaround,
but feels so inelegant and wasteful :)

As for "plenty of performance for anybody", that feels like
"640k is plenty of RAM for anybody".


> The last project I worked on had 11 sources of interrupt and
> the hard real time requirements meant that a fair bit of processor
> time was done in interrupt context. Usually considered dodgy
> practice, but the system architecture and processor had already
> been chosen and just had to make it work with what was there.
> No real time os either, just a state driven loop. Rtos's may be
> fashionable, but it's gross overkill for many projects, though
> it can force good partitioning and better analysis of the
> various subsystems...

"RTOS" is a very variable feast.

There are very lean and simple RTOSs; some are so lean they
are a pain to use.,

Others were once lean and simple RTOSs but have expanded
over the decades to be "fully featured" behemoths.

I must admit to liking event-driven loops for hard realtime
systems, but you still have to know the maximum time it
could take to process an event.

One advantage of RTOSs is drivers for the things I'd rather
not have to bother with, e.g. ethernet or USB comms with a
host PC. But that's not a killer advantage.

On Wednesday, 2 September 2020 17:11:40 UTC+1, Martin Brown  wrote:

> If he was complaining about the load that a Model 7 Avo puts on the 
> battery under test which ISTR was 500R/volt then he might have a point. 
> They were virtually indestructible though. I still have a mostly working 
> one. The ohm's range is shot but current and voltage are fine.

I thought the Avo 7 managed 20k/volt, but it's been a mercifully long time since I last used one.
My deity, the first version was 60 ohms per volt!
Model 8 MkII was 20kpv.


NT

On 02/09/20 17:11, Martin Brown wrote:
> On 01/09/2020 16:48, Phil Hobbs wrote:
>> On 2020-09-01 11:11, jlarkin@highlandsniptechnology.com wrote:
>>>
>>>
>>> https://www.electronicdesign.com/technologies/test-measurement/whitepaper/21140081/warning-your-dmm-is-discharging-your-battery-cell?utm_source=EG+ED+Today&utm_medium=email&utm_campaign=CPS200828010&o_eid=7322A4702401H9R&rdx.ident%5Bpull%5D=omeda%7C7322A4702401H9R&oly_enc_id=7322A4702401H9R 
>>>
>>>
>>> It's sad how bad the electronics press has become.
>>
>> Good golly, Miss Molly, I'm sure glad he put in that table.  Ohm's law makes 
>> my head hurt.
> 
> :-) Helps to use up more real estate in the article.
> 
> We should go back to old school potentiometer measurements of voltage - then no 
> current flows at all when you have balanced the bridge.

Literally, in my case. NiFe + Weston cell + metre rule + resistance wire.
Ah, them's were the days.


> If he was complaining about the load that a Model 7 Avo puts on the battery 
> under test which ISTR was 500R/volt then he might have a point. They were 
> virtually indestructible though. I still have a mostly working one. The ohm's 
> range is shot but current and voltage are fine.

I remember a story told at GPO/BT Martlesham Labs.

They had an Avo salesman and a (newfangled) DMM salesman demonstrate
the virtues of their equipment. It was neck-and-neck at the end of
the formal evaluation.

Then the DMM salesman threw the DMM across the room, walked over and
picked it up, and made another measurement.

I don't know whether or not he was grinning.

On Wed, 02 Sep 2020 16:45:21 +0100, Chris <xxx.syseng.yyy@gfsys.co.uk>
wrote:

>On 09/02/20 15:57, Tom Gardner wrote:
>> On 02/09/20 15:33, jlarkin@highlandsniptechnology.com wrote:
>>> On Wed, 2 Sep 2020 07:42:42 +0100, Tom Gardner
>>> <spamjunk@blueyonder.co.uk> wrote:
>>>
>>>> On 02/09/20 02:12, whit3rd wrote:
>>>>> On Tuesday, September 1, 2020 at 5:38:58 PM UTC-7, John Larkin wrote:
>>>>>
>>>>>> "Any OS is an RTOS if it's fast enough."
>>>>>
>>>>> Not true. Our-of-order execution and uncontrolled interrupts are
>>>>> tools of Finagle and his gremlins.
>>>>
>>>> Don't forget the effect of caches, which improve the /average/
>>>> execution time.
>>>>
>>>> Strictly speaking, John's statement is correct. But the problem
>>>> is /proving/ it is "fast enough".
>>>
>>> I measured the Linux performance with an oscilloscope. My programmer
>>> couldn't estimate timing within a factor of 20 or so. I have to push
>>> him to do terrifying stuff like interrupting at 4 KHz. I did useful 20
>>> KHz interrupts on a 68332, roughly one cent of the power in the Zynq.
>>
>> With anything that isn't bare silicon I'd be reluctant to
>> give /hard/ realtime guarantees - even with measurement.
>>
>> The problem is twofold: there's a awful/aweful lot of
>> /stuff/ in a modern "desktop" OS, and very few people
>> understand all of the stuff stuffed in there. Plus who
>> knows what is going to kick off infrequently and even
>> less frequently at the most inconvenient time.
>>
>> But then I like bare silicon coding.
>>
>> Unfortunately, even with bare silicon coding, caches & OoO
>> can be a problem. They are designed to improve performance
>> /on average/, but with /hard/ realtime code nobody in their
>> right mind cares about average. (Soft realtime is fine, and
>> I've successfully used applications with GC in that mode.)
>>
>> So, what's the effect of caches on peak/mean performance?
>> I haven't got any info for a modern processor, but even on
>> the intel 486 with its tiny caches and non-Out-of-Order
>> execution, there could be a 5:1 ratio. God only knows
>> what it is now.
>>
>> So IMNSHO, linux + Out of Order + caches is not suitable
>> for interesting *hard* realtime performance.
>
>In practice, you don't rely software timing for hard real
>time work. Long gone are the days where I would count cycles
>in interrupt handlers to ensure timer accuracy, but modern cpus
>are so fast compared to older 68xxxx and 8 bit processors that
>outright performance is rarely an issue. It it is, the system
>design is wrong, or you just put a cpu with more welly. It's
>easier and less hassle to disable the cpu cache and use just
>one core as well.
>
>The last project I worked on had 11 sources of interrupt and
>the hard real time requirements meant that a fair bit of processor
>time was done in interrupt context. Usually considered dodgy
>practice, but the system architecture and processor had already
>been chosen and just had to make it work with what was there.
>No real time os either, just a state driven loop. Rtos's may be
>fashionable, but it's gross overkill for many projects, though
>it can force good partitioning and better analysis of the
>various subsystems...
>
>Chris

I've written three RTOSs and don't see any reason to use one these
days. Just do the "realtime" stuff in a periodic state machine in a
high-priority task. Overkill on CPU power until you feel comfortable.

Do the really fast processing in the FPGA fabric. For example, let the
FPGA filter a delta-sigma ADC stream, square and filter again. Let the
uP pick that up and finish the RMS calculation whenever it wants to.

Similarly, the fast parts of PID control can be delegated to hardware.






-- 

John Larkin         Highland Technology, Inc

Science teaches us to doubt.

  Claude Bernard