[Info-vax] VSI: "Official 8.4-1H1 Launch"

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Sun Jun 7 10:24:58 EDT 2015


On 2015-06-07 03:05:14 +0000, David Froble said:

> Sticking my big fat mouth into a discussion that I know nothing about ..
> 
> There is performance, and, there is response time.  They re not always 
> the same thing.  "Overall" doesn't really matter, if the specific you 
> need doesn't perform well enough.

Ayup.   For folks working real-time, it's both the performance and the 
predicability of that performance that matters.

A box that is "fast enough" is necessary, but you also don't want to 
get your processing stuck behind some other VM guest or stuck behind 
some VM operation or host hardware operation or some other consumer of 
the shared FC SAN controller bandwidth that's going to take (even 
rarely) an indeterminately-large time — even transient indeterminate 
responses that are larger than your response time requirements are a 
big problem.  (n.b. While it's unlikely that there'll be a shared FC 
SAN controller configured in most real-time systems, you might still 
take a performance hit or jitter hit from FC SAN controller activity or 
a local RAID controller rebuild or other "out-of-band" system activity.)

This is also one of the reasons why assembler and C are used for a fair 
amount of real-time programming, and why Rust doesn't have garbage 
collection — asynchronous garbage collection activity can inject 
~unpredictable delays in the applications.   This is also why you can 
see SQLite databases used in some of these applications, too.  SQLite 
can be run entirely in memory, and can be sufficiently predictable.

This variability is called jitter, as was mentioned up-thread.  Beyond 
the necessary performance, jitter also needs to be below some 
application-specific threshold.

One (old) real-world real-time system I'm familiar with was acquiring 
sensor data at not-all-that-much-less than the SBI speed of the 
VAX-11/780 box.  All the box had to do was analyze that arriving data 
for anomalies and get that anomaly data out to disk, and that was no 
small project.   Not the least of which because of the potential for 
jitter from those old SBI storage devices.  (FWIW, there's a recent 
SpaceX video around which discusses some analogous issues; where you 
have way too much data for the speed of the available hardware 
<https://www.youtube.com/watch?v=vYA0f6R5KAI>.  How you have to reduce 
the volume of data to match the available performance.)

Most folks doing RT work are probably not going to be running as guests 
within a VM, nor using emulation.   Though there'll be cases where 
either or both would probably work for some real-time applications, 
given the more than ample slop in the definition of what real-time is.


-- 
Pure Personal Opinion | HoffmanLabs LLC




More information about the Info-vax mailing list