Applications, Challenges, and Possibilities - Real-Time Rendering: Computer Graphics with Control Engineering - page 103

7.2 SOFTWARE AND HARDWARE
PERFORMANCE CONSIDERATIONS
The process of establishing a valid control system for a real-time rendering applica-
tion requires special attention beginning from data collection and pre-processing
and proceeding to system level moderation. We provide a list of the key hardware
and software considerations below.
7.2.1 d ata i integRity
When a non-real-time operating system is used, it is inevitable for kernel processes
to introduce disturbance to the rendering system output. Consequently, the data col-
lected for system identification may contain spikes and occasional data points that do
not follow the trend of the change in data direction. If such data are used for system
identification directly, the result would be greater difficulty in deriving an accurate
system model. Therefore, it is imperative to use a number of de-noising, filtering, and
de-trending tools to preprocess data before the system identification step.
7.2.2 P lant -c ontRolleR c ommunication l atency
When network communication is involved as it is in Configurations B and C
(described in Section 7.1), it is important to consider the network latency that may
arise from closed-loop feedback data movement. For Configuration B, even if the
interprocess communication is handled via a loop-back network communication, the
latency would be negligible because of the local network hardware. In contrast, this
assumption deviates more with Configuration C because of real data routing latency
across network switches and other physical media. To minimise latency, the set-up
should include a high-speed switch and local area isolated network. This arrange-
ment was used in all our experiments.
From a software implementation perspective, the selected communication proto-
col plays an important role in system performance. In typical network communica-
tion arrangements the transmission control protocol (TCP) or universal datagram
protocol (UDP) may be used. Configuration B would demonstrate a negligible differ-
ence between these options since performance is largely driven by hardware.
However, this is not true for systems using Configuration C. If the network con-
necting the plant and controller cannot be isolated for certain reasons, it would be
better to use TCP as the mode of communication because it guarantees lossless
delivery. Conversely, if a network is unlikely to be congested, UDP can be a good
choice because it provides better speed.
7.2.3 d ata s tRuctuRes and h andling
For optimised transmission efficiency, it is always advantageous to use simple data
structures. Complex data structures should be avoided to prevent data marshalling
issues that may arise due to incompatibility in machine-specific hardware. Also, it is
a good practice to utilise a single network communication channel for sending and