Hello Joel,
thanks for the review, I tried to address all your issues in v3 with one
exception:
On 07/11/2019 22:55, Joel Sherrill wrote:
Overall, this is really good. I am sure we will polish details as
things progress. I marked a few places with notes. Mostly
grammar or minor points.
[...]
+.. _ReqEngResAndPerf:
+
+Resources and Performance
+-------------------------
+
+Normally, resource and performance requirements are formulated like
this:
+
+* The resource U shall need less than V storage units.
+
+* The operation Y shall complete within X time units.
+
+Such statements are difficult to make for a software product like
RTEMS which
+runs on many different target platforms in various configurations.
So, the
+performance requirements of RTEMS shall be stated in terms of
benchmarks. The
+benchmarks are run on the project-specific target platform and
configuration.
+The results obtained by the benchmark runs are reported in a human
readable
+presentation. The application designer can then use the benchmark
results to
+determine if its system performance requirements are met. The
benchmarks shall
+be executed under different environment conditions, e.g. varying
cache states
+(dirty, empty, valid) and system bus load generated by other
processors. The
+application designer shall have the ability to add additional
environment
+conditions, e.g. system bus load by DMA engines or different system bus
+arbitration schemes.
+
+To catch resource and performance regressions via test suite runs
there shall be
+a means to specify threshold values for the measured quantities.
The threshold
+values should be provided for each validation platform. How this
can be done
+and if the threshold values are maintained by the RTEMS Project is
subject to
+discussion.
We focused on big-O and whether methods were constant time, bounded, or O(n)
when designing. Perhaps the focus could be there. But this is a design
goal for all
of RTEMS and something we would document. Nothing to do except a general
design goal.
This section also sounds like part of what is required by a systems
integrator
when leveraging what the FAA calls a Reusable Software Component:
https://www.faa.gov/regulations_policies/advisory_circulars/index.cfm/go/document.information/documentID/22207
You get credit for what's common and have to fill in details for your
system.
I added a ticket for this:
https://devel.rtems.org/ticket/3819
I think it is important to look at, but I need some time to read the
advisory.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
