System Requirements - Maestro 5.x

I developed and tested Maestro 5.0 on a Marquis C539-T from ASL Inc. For the benefit of those looking to purchase a workstation to run the application, here are the important configuration details:

• ASUS Prime Z790-A WIFI Z790 Express ATX motherboard

• Onboard Intel PCI Express 2.5Gigabit & Wi-Fi 6E Ethernet controller

• 1xPCIe x16 v5, 1xPCIe x16 v4, 1xPCIe x4 v4, 2xPCIe x1 v3 slots

• 1 x Intel Core i7-14700K (Raptor Lake Refresh+UHD770) 3.4ghz (5.4Ghz Turbo), 8P + 12E Cores, 28 threads, 125W/253W (Turbo) TDP, DDR5-5600mhz

• 2 x 16GB DDR5-5200mhz unbuffered, non-ECC module

• 1 x Samsung 980 Pro MZ-V8P1T0B/AM 1TB NVMe PCIe4 SSD, 7000/5000MB/s (R/W), 600 TBW (M.2 2280)

• Onboard Intel UHD 770 VGA, Dual Head, 1xHDMI 2.1,1xDP 1.4

• Microsoft Windows 11 Professional (Max CPU=2, Max Mem=512GB), 64-bit, OEM

Note the Intel Core i7 processor has 8 Performance (P) and 12 Efficient (E) cores. The P cores support Hyper Threading (2 threads of execution per core), while the E cores do not. RTX64 4.5 supports Hyper Threading; it "sees" a total of 8x2 + 12 = 28 logical CPUs on this machine.

I tested Maestro operation under 3 different RTSS boot configurations: 14 Windows/14 RTX cores; 22 Windows/6 RTX cores; and 26 Windows/2 RTX cores. I encountered no issues in ANY of the configurations. It's important to note that, in the latter two configurations, no "Performance" cores get assigned to the RTSS subsystem. The results suggest that Maestro is not too demanding on a system, and 2 RTX cores may suffice -- in which case you could elect to go with the RTX64 Runtime "Entry" edition; I still recommend choosing the "Professional" edition so that you can dedicate up to 7 logical cores to RTX. More importantly, you could opt for a less expensive processor -- the Intel Core i5-14600K has 6P + 8E cores (20 logical cores), while the Intel Core i3 has 4P + 0E cores (8 logical cores with hyper threading enabled). 

A key requirement for running Maestro is the Real-Time Extension package from IntervalZero. RTX serves 32-bit versions of Windows up to Windows 7, while RTX64 works with 64-bit versions of Windows 7 through 11. (Throughout this guide, the acronym RTX refers to both the 32-bit and 64-bit versions unless otherwise noted.) RTX brings to Windows the real-time performance, fine-grain thread scheduling, and easy hardware access that makes Maestro feasible as a Windows-based application.

Maestro's hardware controller must do many different tasks during each one-millisecond epoch of a trial, and it must stay in synch with the trial timeline, which is set by once-per-millisecond interrupts from the analog input device. The associated interrupt service routine (ISR) updates critical runtime variables and sets a "frameshift" flag to abort the trial if the controller's runtime service loop has fallen a full cycle behind the data acquisition timeline. Had we designed the controller as a Windows process, we would observe occasional frameshifts because Windows is not a real-time operating system. In fact, some frameshifts could be missed altogether because interrupt latencies in Windows are sometimes many milliseconds long. The occasional aborted trials, not to mention the far worse possibility that it might fail to detect and discard out-of-synch trials, would render Maestro unusable.

RTX's real-time subsystem (RTSS) provides the solution. Interrupt latencies in RTSS are on the order of 50us or less, averaging ~10us. RTSS threads are always scheduled to run ahead of Windows threads, including those in the kernel. By designing Maestro's hardware controller to run as an RTSS process, we get the real-time deterministic performance we require. Meanwhile, the less time-critical user interface is implemented as a Windows process, taking advantage of the large collection of Windows APIs available for user interface design.

With a Windows-based GUI and the RTX-based hardwared controller running on the same machine, thread scheduling becomes an issue. While executing a trial, the controller must own the CPU during the majority of each 1-ms epoch. On the other hand, when the user is editing experimental protocols in the GUI, the hardware side is idle and should use very little CPU time. Thus, to get the necessary performance on the hardware side without degrading the user’s experience on the GUI side, the application requires adjustable, fine-grained control of process and thread scheduling. One way to achieve this is to strategically place "sleep()" calls throughout the controller's code, but such an approach is unwieldy and difficult to maintain. Instead, using RTX's high-resolution timer and thread management functions, we developed a simple thread suspension manager that periodically suspends the controller's thread to yield the CPU to other threads, including the GUI. By changing the manager's duty cycle and suspend duration, we can easily modify the hardware controller's CPU usage as appropriate to the current operational mode. More recently, with the advent of multi-core processors and RTX support for them, we can improve performance even more by restricting Windows to one core and dedicating the rest to Maestro's hardware controller.

A final benefit of RTX is streamlined device communications. Using the RTX device management API, Maestro's controller can "talk" directly to the hardware, without going through a vendor-supplied driver. Device interactions are narrowly tailored to the minimum device functionality we require, leaving more time during each 1-ms epoch for additional control logic and more device accesses – thereby permitting a richer repertoire of experimental designs.