Pith. sign in

REVIEW 4 major objections 6 minor 26 references

Industrial Control via Application Containers: Migrating from Bare-Metal to IAAS

T0 review · 4 major / 6 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Real-time industrial control can migrate to cloud containers

desk verdict A useful, honestly-scoped benchmark for containerized real-time tasks on cloud IaaS, but the 'viable' claim runs ahead of what the measurements actually cover. read the letter →

arxiv 1908.04465 v1 pith:MV72QUX6 submitted 2019-08-13 cs.DC

Florian Hofer , Martin A. Sehr , Antonio Iannopollo , Ines Ugalde , Alberto Sangiovanni-Vincentelli , Barbara Russo This is my paper · ORCID
classification cs.DC
keywords industrialcontrolsystemsreal-timelatencyIaaSmigrationapplicationcontainersPREEMPT-RTType1hypervisorcyclictestclouddeterminism
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper seeks to establish that time-critical industrial control software, traditionally tied to dedicated hardware, can run on shared cloud infrastructure built from off-the-shelf container and virtualization technology. Its evidence is a series of latency tests on the firing delay of periodic real-time tasks under 100% CPU stress, comparing bare metal, Type 1 hypervisor instances, and a containerized deployment. With a PREEMPT-RT kernel and CPU isolation, AWS instances showed average latencies of 5 to 12 microseconds and most samples below 100 microseconds, close to the bare-metal baseline. The authors conclude that IaaS migration is feasible for control loops whose cycle times exceed the measured peaks, which would let control tasks share resources and cut operating cost.

What carries the argument

The argument is carried by cyclictest, which measures the firing latency $f_i$ of a periodic task, paired with the stress tool, which drives CPU load to create a worst-case shared-resource scenario. The measured quantity enters the real-time constraint $f_i + r_i = c_i \le d_i \le p_i$, so low $f_i$ is the precondition for meeting deadlines. The surrounding machinery is kernel and hypervisor tuning: control-group isolation of CPUs, disabling the scheduler load balancer, setting IRQ affinity, and selecting a PREEMPT-RT kernel, all applied to AWS hvm Type 1 instances that the paper takes to pass guest threads to hardware with reduced virtualization overhead. These settings are what bring cloud latencies into bare-metal range.

What would settle it

Run the same cyclictest workload under a real industrial control loop on a shared AWS instance, including fieldbus or network I/O, co-tenant memory and interrupt load, and check whether worst-case firing latency stays below the 100 microsecond target or below one tenth of the cycle time; if peaks routinely exceed 100 microseconds or the 5 to 12 microsecond averages no longer hold, the viability claim fails.

Watch

Extended reading notes

Core claim

The central discovery is that computation latency, the delay between a periodic real-time task's wake-up and its execution start, does not by itself block moving control software to the cloud. Under the selected isolation-with-load-balancer configuration, a PREEMPT-RT-patched guest on AWS Type 1 hypervisor instances produced average firing latencies of 5 to 12 microseconds over ten million samples, with the majority of samples below 100 microseconds; the bare-metal reference remained best in mean but showed similar spread. A compute-optimized C5 instance had the lowest spread and a 114-microsecond peak, while a general-purpose T3 instance exceeded 100 microseconds in only 96 of ten million samples, or 0.00096%, and had a 49-millisecond maximum. A containerized real-time task on the C5 instance averaged 7 microseconds under stress and 11.44 microseconds without stress. From these measurements, the paper argues that execution on virtualized IaaS is viable for cycle times above the observed peaks and that strict determinism can be approached with the right instance type and kernel configuration.

Load-bearing premise

The whole conclusion rests on the assumption that a stress tool driving 100% CPU load, together with the selected isolation configuration, produces timing interference representative of a real control workload sharing a cloud instance, and that computation latency alone is a fair proxy for end-to-end timing.

Editorial extensions

If this is right

  • A general-purpose AWS T3 instance with PREEMPT-RT can serve as an IaaS replacement for control loops with cycle times safely above the 49 ms maximum observed, since only 0.00096% of samples exceeded 100 microseconds.
  • A compute-optimized C5 instance offers stricter determinism, with the lowest spread and a 114 microsecond peak among the cloud instances tested.
  • Enabling the T3-Unlimited burst feature produced even better latency results, giving an economical path to tighter timing requirements.
  • Containerized real-time control on a C5 instance retains average latencies of 7 to 11.44 microseconds, indicating container overhead is acceptable for many industrial cycle times.
  • Type 1 hypervisor latency performance comparable to bare metal means the main remaining obstacle to full migration is I/O and system latency, which the paper explicitly defers to future work.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Because the tests cover computation latency only, a natural next step is to measure the complete control loop over real fieldbus or network I/O; end-to-end latency will likely add a systematic offset on top of the firing delays reported here.
  • The results depend on AWS hvm instances and their claimed direct hardware assignment; other providers or older hypervisors without equivalent pass-through may show larger virtualization overhead, so the numbers should not be assumed to transfer to every IaaS.
  • For sub-millisecond control cycles, the 49 ms peak on a T3 instance and even the 114 microsecond peak on C5 would miss a 1 ms deadline; the viability argument therefore holds for millisecond-scale and slower cycles, not for high-rate servo loops.
  • The incompatibility between PREEMPT-RT and RT-CGroup noted in the paper means container-level CPU isolation was unavailable in the best-performing configuration; future kernels that lift this restriction could change the recommended instance choice.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper studies the feasibility of moving time-critical industrial control applications from dedicated hardware to cloud IaaS using application containers. The authors run cyclictest latency measurements under the stress tool across several kernel configurations (standard Ubuntu, Xenomai 3, PREEMPT-RT) and environments: a VirtualBox Type-2 setup (offline tuning), a bare-metal Xeon server, and AWS T3.xlarge and C5.xlarge HVM instances, followed by a Balena container test. They identify 'Isolation, with load balancer' as the favorable configuration and report average wake-up latencies of 5–12 µs for PREEMPT-RT on AWS, with most measurements below 100 µs; they conclude that time-critical applications can viably run on cloud platforms. The container test reports averages of 7 µs (σ=0) and 11.44 µs (σ=0.71) on a C5 system.

Significance. The paper provides a useful, openly documented empirical baseline: 10 million loops per configuration, the standard cyclictest tool, and publicly archived scripts and data give the measurements credibility. If the reported latencies are representative, the study supports a migration path for computation-only control tasks with modest cycle times. The significance is currently limited by three issues: the evaluated configuration is selected from the same offline data used for the headline comparison; the bare-metal baseline is not hardware-matched to the cloud instances; and the container result is reported without enough statistical support. The conclusions should therefore be framed as a single-tenant, CPU-only feasibility demonstration, not as general cloud viability, until co-tenant and I/O interference are addressed.

major comments (4)
  1. [Section VII-B and Figure 1] The 'Isolation, with load balancer' configuration is selected after inspecting the offline results in Section VII-A, and the same configuration is then used for the AWS comparison. This post-hoc selection makes the headline numbers a best-case estimate; the paper needs an independent validation (for example, a fixed configuration rule set before the cloud runs, or a sensitivity analysis over neighboring configurations) before the comparison can support the viability claim.
  2. [Section VII, Figure 1] The bare-metal baseline uses a dual Xeon X5560 (Nehalem) system with 8 cores/16 threads, while the AWS T3.xlarge and C5.xlarge instances use 4 vCPUs of a newer generation with different memory systems. The 'comparable to bare metal' conclusion in Section VIII is therefore confounded by hardware-generation and resource-count differences, so the comparison does not isolate the effect of virtualization on latency.
  3. [Section VII-C] The container experiment reports mean latencies of 7 µs (σ=0) with stress and 11.44 µs (σ=0.71) without stress, with maxima of 7655/11644 µs, but gives no sample size or number of repeated runs; a σ of exactly 0 under stress suggests a single measurement. In addition, RT-CGroup could not be enabled with the PREEMPT-RT kernel, so the container run is not the real-time configuration advocated in Sections VII-B and VIII. This evidence is not sufficient to support the claimed evaluation of hard real-time container scheduling.
  4. [Sections III and VIII] The tests measure computation latency only, and the stress workload is generated inside the same guest CPU. The authors explicitly defer I/O, network, and system latency to future work. Since a shared IaaS deployment will also experience co-tenant CPU, cache, memory-bandwidth, and I/O-device interference, the measured 5–12 µs averages do not by themselves establish viability for a shared industrial control deployment; the abstract and conclusions should either be narrowed to the single-tenant, CPU-only setting or complemented by interference tests.
minor comments (6)
  1. [Section II] The text contains typographical errors such as 'emphthey' and 'exploting'; the manuscript needs a careful copyedit.
  2. [Figure 1] The caption mentions a blue mean but does not define the abbreviations BM, Std, Prt, Xen, C5, T3, Prt.U, Xen.U, or the meaning of the dashed threshold lines; add a legend and a note that the thresholds are the 1/10-cycle-time limits for 100 ms and 1 ms cycles.
  3. [Table I] The header 'n>1mln' is not defined precisely (number of measurements per row, number of threads), and the text refers both to a single test thread and to 'one thread of each kind per vCPU'; state the thread count and sample size for each row.
  4. [Section VII-B] The 1/10-of-cycle-time feasibility threshold is manually chosen; the paper should state how sensitive the conclusions are to this choice, since it is the criterion by which 'viable' is judged.
  5. [Section VII] The description of the baseline server as 'two Xeon X5560 processors on 8 cores, 16 threads' is ambiguous about per-socket versus total core counts; specify the topology.
  6. [Section VII-C] The statement 'Details can be found at [21]' should be replaced with a direct citation of the kernel configuration flag and the kernel version in which the RT-CGroup incompatibility occurs.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper's latency claims are direct measurements against external benchmarks, with no fitted parameter or self-citation doing load-bearing work.

full rationale

The paper's central claim is that measured PREEMPT-RT latencies on AWS instances are comparable to bare metal and mostly below 100 µs. This is an empirical report: cyclictest measures firing latencies directly; the 'viable' conclusion is an interpretive judgment against a stated threshold (1/10 of cycle time), not a quantity derived from the measurement setup by construction. The configuration choice ('Isolation, with load balancer') was made after inspecting offline results, which is a methodological weakness (post hoc selection), but it is not circular: the reported values are still external measurements, and no parameter fitted to the outcome is reused as a prediction. The only self-citation (Ref. [2], Hofer's earlier systematic mapping) is contextual and not load-bearing. The paper explicitly limits scope to computation latency and defers I/O and system latency to future work, so the applicability of the result is narrower than the headline claim, but narrowing scope is not circularity. No equation is defined in terms of its own output, and no uniqueness theorem or ansatz is imported from the authors' prior work.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

The central claim depends on manually chosen evaluation thresholds and several untested domain assumptions about workload modeling and hypervisor behavior. No invented entities are introduced. The methods are experimental, so the main burden is on the representativeness of the test conditions rather than on fitted parameters.

free parameters (1)
  • Feasibility threshold of 1/10 cycle time
    Manual design rule (Section VII-B: 'Ideally, the maximum firing delay of the threads should stay below 1/10th of the cycle time. This upper limit has deliberately been set to allow minimal resource sharing for our sample application.') It defines 'viable' for interpreting latency results; not statistically derived.
assumptions (4)
  • domain assumption The stress tool driving the system to 100% load average models worst-case interference that a real-time task would experience in a shared cloud.
    Section VII describes stress as an 'extreme overload case' defining an upper limit; the representativeness of this model for real industrial workloads is assumed, not validated.
  • domain assumption AWS hvm Type 1 hypervisors allow direct assignment and control of hardware and resources, reducing virtualization overhead.
    Section VII attributes this to AWS documentation; the paper relies on it to argue cloud instances can approach bare-metal performance.
  • domain assumption A Type 2 hypervisor (VirtualBox) represents the worst-case latency environment, so improvements seen there will carry over to Type 1.
    Section IV states the Type 2 hypervisor is the worst-case scenario; the extrapolation to Type 1 is assumed.
  • domain assumption cyclictest provides a valid direct measurement of the task firing latency fi defined in Eq. 1.
    Section VII uses cyclictest as the latency measurement tool, following common practice in the cited literature; the measurement validity is taken for granted.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Industrial Control via Application Containers: Migrating from Bare-Metal to IAAS." pith.science (2026). https://pith.science/paper/MV72QUX6

@misc{pith2026190804465,
  author       = {Pith},
  title        = {Pith review of: Industrial Control via Application Containers: Migrating from Bare-Metal to IAAS},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MV72QUX6}},
  note         = {Machine review of arXiv:1908.04465}
}
read the original abstract

We explore the challenges and opportunities of shifting industrial control software from dedicated hardware to bare-metal servers or cloud computing platforms using off the shelf technologies. In particular, we demonstrate that executing time-critical applications on cloud platforms is viable based on a series of dedicated latency tests targeting relevant real-time configurations.

Figures

Figures reproduced from arXiv: 1908.04465 by the authors.

Figure 1
Figure 1. Boxplot of latencies, with averages and overshoot sizes - mean in blue [PITH_FULL_IMAGE:figures/full_fig_p007_1.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

26 extracted references · 26 canonical work pages

  1. [1]

    A real-time container architecture for dependable distributed embedded applications,

    K. Telschig, A. Sch ¨onberger, and A. Knapp, “A real-time container architecture for dependable distributed embedded applications,” in 2018 IEEE 14th International Conference on Automation Science and Engineering (CASE). IEEE, aug 2018

    work page 2018

  2. [2]

    Architecture, technologies and challenges for cyber-physical systems in industry 4.0 - a systematic mapping study,

    F. Hofer, “Architecture, technologies and challenges for cyber-physical systems in industry 4.0 - a systematic mapping study,” in 12th ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), 2018

    work page 2018

  3. [3]

    A container-based architecture for real-time control applications,

    T. Tasci, J. Melcher, and A. Verl, “A container-based architecture for real-time control applications,” in 2018 IEEE International Conference on Engineering, Technology and Innovation (ICE/ITMC) . IEEE, jun 2018

    work page 2018

  4. [4]

    OS-level virtualization for industrial automation systems: Are we there yet?

    A. Moga, T. Sivanthi, and C. Franke, “OS-level virtualization for industrial automation systems: Are we there yet?” in Proceedings of the 31st Annual ACM Symposium on Applied Computing - SAC '16. ACM Press, 2016

    work page 2016

  5. [5]

    Software containers for industrial control,

    T. Goldschmidt and S. Hauck-Stattelmann, “Software containers for industrial control,” in 2016 42th Euromicro Conference on Software Engineering and Advanced Applications (SEAA) . IEEE, aug 2016

    work page 2016

  6. [6]

    Open issues in scheduling microservices in the cloud,

    M. Fazio, A. Celesti, R. Ranjan, C. Liu, L. Chen, and M. Villari, “Open issues in scheduling microservices in the cloud,” IEEE Cloud Computing, vol. 3, no. 5, pp. 81–88, sep 2016

    work page 2016

  7. [7]

    A cyber-physical systems architecture for Industry 4.0-based manufacturing systems,

    J. Lee, B. Bagheri, and H.-A. Kao, “A cyber-physical systems architecture for Industry 4.0-based manufacturing systems,” Manufacturing Letters, vol. 3, pp. 18 – 23, 2015

    work page 2015

  8. [8]

    Towards safe dynamic updates of distributed embedded applications in factory automation,

    K. Telschig and A. Knapp, “Towards safe dynamic updates of distributed embedded applications in factory automation,” in22nd IEEE International Conference on Emerging Technologies and Factory Automation (ETFA) , no. reconfiguration. IEEE, sep 2017

    work page 2017

Show all 26 references
  1. [9]

    A fog computing-based framework for process monitoring and prognosis in cyber-manufacturing,

    D. Wu, S. Liu, L. Zhang, J. Terpenny, R. X. Gao, T. Kurfess, and J. A. Guzzo, “A fog computing-based framework for process monitoring and prognosis in cyber-manufacturing,” Journal of Manufacturing Systems , vol. 43, pp. 25–34, apr 2017

    2017

  2. [10]

    A new approach of PHM as a service in cloud computing,

    L. S. Terrissa, S. Meraghni, Z. Bouzidi, and N. Zerhouni, “A new approach of PHM as a service in cloud computing,” in 2016 4th IEEE International Colloquium on Information Science and Technology (CiSt) , NA, Ed., IEEE. IEEE, oct 2016, pp. 610–614

    2016

  3. [11]

    Visualising the digital twin using web services and augmented reality,

    G. Schroeder, C. Steinmetz, C. E. Pereira, I. Muller, N. Garcia, D. Espindola, and R. Rodrigues, “Visualising the digital twin using web services and augmented reality,” in 2016 IEEE 14th International Conference on Industrial Informatics (INDIN) , NA, Ed. IEEE, jul 2016

    2016

  4. [12]

    Continuous maintenance and the future – foundations and technological challenges,

    R. Roy, R. Stark, K. Tracht, S. Takata, and M. Mori, “Continuous maintenance and the future – foundations and technological challenges,” CIRP Annals, vol. 65, no. 2, pp. 667–688, 2016

    2016

  5. [13]

    Container-based architecture for flexible industrial control applications,

    T. Goldschmidt, S. Hauck-Stattelmann, S. Malakuti, and S. Gr ¨uner, “Container-based architecture for flexible industrial control applications,” Journal of Systems Architecture , vol. 84, pp. 28–36, 2018

    2018

  6. [14]

    Challenges in real-time virtualization and predictable cloud computing,

    M. Garc ´ıa-Valls, T. Cucinotta, and C. Lu, “Challenges in real-time virtualization and predictable cloud computing,” Journal of Systems Architecture, vol. 60, no. 9, pp. 726–740, oct 2014

    2014

  7. [15]

    An updated performance comparison of virtual machines and linux containers,

    W. Felter, A. Ferreira, R. Rajamony, and J. Rubio, “An updated performance comparison of virtual machines and linux containers,” in 2015 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS). IEEE, mar 2015

    2015

  8. [16]

    Performance evaluation of container-based virtualization for high performance computing environ- ments,

    C. Arango, R. Dernat, and J. Sanabria, “Performance evaluation of container-based virtualization for high performance computing environ- ments,” 2017

    2017

  9. [17]

    G. C. Buttazzo, Hard real-time computing systems: predictable scheduling algorithms and applications. Springer Science & Business Media, 2011, vol. 24

    2011

  10. [18]

    [Online]

    Xenomai 3 - Project Wiki. [Online]. Available: https://gitlab.denx.de/ Xenomai/xenomai/wikis/Start Here

  11. [19]

    Linux and real-time: Current approaches and future opportunities

    C. Scordino and G. Lipari, “Linux and real-time: Current approaches and future opportunities.” IEEE, 2008

    2008

  12. [20]

    Linux PREEMPT- RT v2.6.33 versus v3.6.6,

    H. Fayyad-Kazan, L. Perneel, and M. Timmerman, “Linux PREEMPT- RT v2.6.33 versus v3.6.6,” ACM SIGBED Review , vol. 11, no. 1, pp. 26–31, feb 2014

    2014

  13. [21]

    [Online]

    The Linux Foundation - Real-Time Linux. [Online]. Available: https://wiki.linuxfoundation.org/realtime/

  14. [22]

    [Online]

    Amazon AWS User guide - The C5 instance. [Online]. Available: https://aws.amazon.com/ec2/instance-types/c5/

  15. [23]

    [Online]

    rt-tests - test programs for real-time kernels. [Online]. Available: https://directory.fsf.org/wiki/Rt-tests

  16. [24]

    [Online]

    Stress - the stress testing tool. [Online]. Available: http://people.seas. harvard.edu/∼apw/stress/

  17. [25]

    [Online]

    Test archive. [Online]. Available: http://bit.ly/2XdoYPn

  18. [26]

    [Online]

    LinuxRealtime.org - Improving the Real-Time Properties. [Online]. Available: http://linuxrealtime.org/index.php/Improving the Real-Time Properties

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.