Linux question -- how to tell if serial port in /dev is for real?

Interesting.

Do these tools operate at one or all levels of the "stack", i.e. at the instruction/data/memory/cache/multiprocessor levels up to the effects of any software FIFOs used to communicate between tasks/processors?

Static analysis in other areas has been shown to have significant limitations. I would presume, without evidence, that there is no reason to believe they will be more successful in this area.

I wonder what presumptions they make for their extrapolations, and whether the extrapolations are provably valid.

The engineering field is littered with academics that presumed normal distributions only to discover that the real world is non-linear. Classic example is "rogue waves"; ships used to be designed to cope with "100 year waves" - but then real-world measurements indicated far more 100 years waves than are theoretically possible. Yes, the sailor old wives tales of rogue waves were dismissed as mere "bar stories" by academics, but now the stories are shown to be accurate.

Alternatively I've come across many salesman claiming 99.999% uptime (i.e. downtime ~5mins/year) - but no salesman being able to back up that claim with hard evidence.

Reply to
Tom Gardner
Loading thread data ...

And since Windows doesn't page the page tables, that whole problem is avoided (Windows would have to lock the page tables pages necessary for the kernel if those were pageable). But you can still get multiple cache misses walking the page tables.

Reply to
Robert Wessel

Surely this gives overestimated values and hence demand too expensive hardware. However, this assumes that all work is done in one (or more) hard-RT task(s), in which case you must ensure that the CPU load never approaches 100 % but in normal operation might be something between 10 % and 50 % on average.

With a more sensible division of labor helps a lot between:

  • Interrupt service routines
  • Hard-RT task(s)
  • One or more soft-RT tasks
  • Optionally some non-RT tasks
  • A NULL task

It does not matter if the HRT task momentarily use up to 90 % of the CPU time starving the soft-RT and non-RT tasks for a few hundred microseconds or even a few milliseconds (at least in non-RT tasks). These low priority tasks have on average 50 % or even 90 % of the CPU power available.

Granted, you have to allow for the pre-emption delay, when the HRT needs to be started. Processors with a lot of internal registers will require a lot of time to save the context.

It is also critical, how this NULL task is implemented, if it is doing some real job, like burning CPU cycles and blinking a LED, the context save requirement in HRT+NULL combination is the same as in HRT+SRT+nRT+NULL case.

However, if the processor has something like a low power wait for interrupt instruction which saves the whole processor context before entering that wait, then the HRT+NULL is faster, since no more context saves needs to be done, when the next interrupt arrives and potentially activates the HRT task.

Reply to
upsidedown

On 07.8.2014 ?. 15:33, snipped-for-privacy@downunder.com wrote:>> ....

ROFL, that would be pathological indeed. Once I burned the CPU of a netmca board (CPU being an mpc5200b) very subtly [that is the damage was subtle, my toying with the power on/off behaviour of the power supply while connected to all the circuitry less so ...]. The system would boot pretty far, begin some disk I/O and then fail. I am a stubborn person and investigated for a few days until I found out some write to a cacheline would not write correctly or something like that (years ago). So I tried booting with the cache disabled - to my surprise, it did work - and was many many times slower, 10+ times perhaps, generally unusable.

Now back to IRQ latency. Of course it can be predicted on systems with a cache, e.g. the above mentioned system manages a few uS with no sweat at all, disk I/O, windows refresh, data acquisition etc. all running. The DDRAM is clocked at 133MHz; assuming each cacheline access will be a miss _and_ will take a line update and invalidation prior to loading the needed data is still in the nS range (15 cycles or so for 32 bytes). Then once the cacheline is loaded - 8 longwords - there will be subsequent hit accesses so behaviour will still be much faster than what it would be with the cache altogether disabled.

This of course implies proper system layout from the beginning, e.g. you cannot afford to have page fault exceptions in an IRQ handler, processing these takes too long so it must run unmasked. BAT translation and OS support take care of this. Also on some power chips (like the one mentioned) one can lock part of the cache which the IRQ handler will use and have always a hit - but I have never had to resort to that much sweat.

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

formatting link

------------------------------------------------------

formatting link

Reply to
dp

There you have a difference with RT extensions to Windows and Linux. With Windows, the Windows kernel is the same as always - and the RT kernel has to deal with whatever nonsense it does such as disabling interrupts. With modern x86 cpus with virtualisation features, that's not too bad - it just means a bit of extra overhead. But it used to be a significant problem, and meant that Windows could affect the functionality of the RT tasks. With Linux, you just re-compile the kernel with a replacement for the interrupt disable macros that disables them within the Linux task, but leaves the hardware interrupts enabled for the RT kernel to use.

Reply to
David Brown

Back in the nineties I wrote software for a MIPS processor which caches had to be manually managed; the software had to tell which memory range to cache. The ability to lock down cache lines makes it possible to eliminate one source of non-determinism without sacrificing performance (at least for the time critical parts).

For such a tool to produce meaningful figures it must exactly know what components are in the PC, how these are configured, their implementation (specifications tend to be too inaccurate to accurately predict behavior) and how they interact with each other. Having been involved with development PC peripherals myself (admittedly a long time ago), my experience is that there are very few things you can safely assume about PC's. Hence if such a tool exists for PC's I would have very little confidence in it.

Reply to
Dombo

The typical or classical WCET tool analyses a single task or thread at a time and computes a WCET bound for the task assuming no interrupts or preemptions, but using a very precise model of the processor and its timing behaviour. Then a schedulability analysis tool such as MAST

formatting link
or SymTA/S
formatting link
is used to find bounds on response times and end-to-end transactions, also for networks of tasks and processors.

As has already been said, the effect of interrupts and preemptions on the state of caches and other stateful accelerator HW is a sore point in this traditonal two-stage analysis. The present solutions are far from ideal but can work.

WCET analysis for multi-core systems is the subject of much academic research and experimentation, for example in the TACLe network

formatting link
Some results have been reported, for example in the WCET Analysis Workshop series
formatting link
but I don't know of any commercial tool with multicore capability. XMOS have a WCET-analysis tool for the their multicores, but AFAIK it analyses the program in one core at a time.

It solves some problems in some contexts, typically for critical systems where less exact methods are not as trusted and where SW developers are willing to constrain SW designs to make the analysis work.

Another difficulty is that a traditional static-analysis WCET tool is built on exact knowledge of the processor architecture. For PC processors such knowledge is generally not published.

However, there is a very interesting new processor architecture called "the Mill" being developed by Mill Computing (formerly known as Out-of-the-Box Computing),

formatting link
The Mill is a high-performance processor architecture intended for general computing (including desk-top apps) but it is statically scheduled and in fact the way it stores and uses intermediate results depends on the statically known latencies of each operation. There is a chance that this architecture will be amenable to static WCET analysis (necessarily including analysis of Mill caches and some more special Mill features).

Indeed. They use a theorem similar to the Central Limit Theorem, saying that if a number of stochastic variables are independent, then the distribution of their maximum or minimum converges to a normal form as the number of variables goes to infinity. AIUI, the value distributions of the variables are not important; what is important is their independence, and the limit at infinity. See

formatting link

The early work that tried to apply extreme-value statistics to WCET analysis was IMO weakened by suspect independence assumptions. The present trend seems to be to force the HW to behave randomly -- for example, caches which choose eviction victims randomly -- and therefore ensure independence by construction. See, for example,

formatting link

I don't like the approach, and have not tracked the work closely.

--
Niklas Holsti 
Tidorum Ltd 
 Click to see the full signature
Reply to
Niklas Holsti

Such a "sensible" division of labor is not always possible. It depends on the application.

Yes, sometimes one can soak up excess CPU power in non-HRT tasks.

The question is how valuable those non-HRT tasks are for the application (i.e. the user), and if this value is high enough to pay for over-dimensioning the processor.

An anecdote about low-power waits (not relevant to HRT): A space application I did SW work for, a decade ago, had a requirement to put the processor (an 80C32) in a low-power wait between task activations. When the system was assembled and tested, the processor's variable power drain was found to couple into the low-voltage analog part, which messed up the measurements. A NOP loop gave much better results -- stable power drain, no analog interference. Perhaps the board could have provided more decoupling...

--
Niklas Holsti 
Tidorum Ltd 
 Click to see the full signature
Reply to
Niklas Holsti

We had a similar problem. Unit powered by a single AA battery, some analog power electronics drawing directly off the battery, processor was put into low power sleep mode in the idle task, to wait for an interrupt with something to do.

We had a problem with a low level, but noticeable, injection of noise in the analog output at the frequency of the system tick interrupt. The changing processor load was modulating the battery voltage, and the analog system didn't have enough power supply rejection.

Reply to
Richard Damon

A similar situation occurred with various Windows versions in mid

1990's.

Windows NT 3.51 had always required quite good quality motherboards, so it had not problems when the low power NULL task with low power wait started execution.

With MS-DOS and Windows 3.x quite bad quality motherboards were acceptable, however, when trying to use them with Windows 95 (originally with a low power wait state), the system crashed when exiting the wait state, due the current peak drawn. With too few bypass capacitors, there was a big voltage swing, causing the processor to malfunction.

To combat this, the distribution version Win95 NULL task consisted of a busy loop and the processor dissipated the same power, regardless of amount of true work and the voltage swing remained within limit even for bad motherboards.

Later on with better and more stable motherboards, the was a market for "power saver" applications, which consisted of a low power wait loop and the task was execution at a low priority, just above the busy loop real NULL task priority. When there was no application program running, the power saver application was constantly running the low power wait loop, preventing the execution of the real busy loop NULL task.

Reply to
upsidedown

Well, it probably isn't guaranteed, but running the programs on a lightly loaded system that isn't running X always seemed to work well enough for my needs. [I don't often need that sort of response time, but when I did, I didn't have any problems.]

If you want, you can jump through some hoops to run programs using real-time priorities, but on a lightly loaded system, I never say any difference.

--
Grant Edwards               grant.b.edwards        Yow! I demand IMPUNITY! 
                                  at                
 Click to see the full signature
Reply to
Grant Edwards

What's hard to believe? Intel has been building slow, hot, crappily designed processors for decades.

The desktop ones, yes.

--
Grant Edwards               grant.b.edwards        Yow! ONE LIFE TO LIVE for 
                                  at               ALL MY CHILDREN in ANOTHER 
 Click to see the full signature
Reply to
Grant Edwards

Don't be silly. Their devices are excellent for their market.

And, of course, for many other processor families from many other manufacturers.

Reply to
Tom Gardner

Did your "needs" include devices where, even when they functioned according to design, could kill someone?

Look harder.

Reply to
Tom Gardner

It seems like there is the age-old mix-up between "fast" and "real-time" here. I think Grant is claiming to have had fast response times - faster than many would think possible with Python on a Linux system - but it is not real-time. Unplanned delays /could/ happen.

If it does the job he needs, then why should he?

I too have made Python code on a PC that has reaction times of under a millisecond. Would I use such code for a sampling system recording data? Absolutely. Would I use it for controlling the steering on a car? Absolutely not.

Reply to
David Brown

I completely agree.

My point was simply to tie his comments to the points made elsewhere on this thread about the infrequent problems found in many modern processors.

Reply to
Tom Gardner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.