Operating system: 64-bit Windows 10 Enterprise LTSB 2016 (Version 1607). This is the long-term support version of Win10 Enterprise that comes with security and critical updates for 10 years after release (through Oct 2026), and avoids the obnoxious semiannual "feature updates" that come with a standard Windows 10 Pro edition. Maestro 4.x is built and tested with this version of Windows 10; it may not run on more recent Win10 releases. NOTE: We have found that even the "quality updates" (security and otherwise) that come with Win10 Enterprise 1607 LTSB can break RTX64; another advantage of using the Enterprise edition is that you can disable automatic updates!
RTX: IntervalZero's RTX64 Version 3.4 is required. Which edition of the RTX64 runtime you select will depend on how many CPU cores you dedicate to RTX. At a minimum, RTX should get 2 dedicated cores, with the rest reserved for Windows. In that configuration, you can go with the Entry edition. However, we have only tested Maestro 4 on an 8-core workstation with 4 RTX cores and 4 Windows cores; this configuration requires the Professional edition, and we recommend that edition over the Entry edition.
RT-TCP/IP Stack: In addition to the RTX64 runtime license, you must also purchase a separate license for RTX64 TCP/IP support (in 32-bit RTX, TCP/IP Stack support is included with the runtime license).
Processor: 3GHz+ Intel processor with 4-8 cores. This is pretty much the standard for Windows workstations purchased in 2016 or later. A minimum of 4 cores is a must, but we recommend 8 cores. Maestro 4 was built on a workstation with an Intel Core i7 7820X (Skylake-X) processor having 8 cores. IMPORTANT: Be sure to check the IntervalZero website for information about Intel processors compatible with RTX64 Version 3.4. It is quite possible that RTX64 will fail to run on the "latest and greatest" Intel processor!
RAM: 16GB recommended. While this is much more than Maestro itself will need, the Windows OS tends to be a resource hog, so it can't hurt.
Use a discrete (add-in) graphics card instead of integrated graphics. While not an absolute requirement, it is recommended that the workstation avoid using video integrated into the motherboard. Integrated graphics share resources with the CPU and system memory, which can lead to longer timer interrupt latencies that could degrade the real-time responsiveness of Maestro 4.
Hard disk space: We recommend getting two hard drives, 250GB or more for the OS partition, and 1TB or more for storing data files during an experiment. Solid-state hard drives have become commonplace and are proving more reliable and longer-lived than traditional hard drives, so they are a good option if you can afford the extra expense.
Required plug-in hardware: The National Instruments PCIe-6363 multi-function IO card and an RTX64-supported network interface card. The PCIe-6363 handles analog input, analog output, and digital IO and event timestamping, while the NIC provides the Maestro-RMVideo private Ethernet link. Check the IntervalZero website for a list of RTX64-supported NICs; the Lisberger lab use the Intel CT Gigabit Desktop adapter (82574L chipset). Both the PCIe-6363 and the Intel CT Gigabit NIC require a PCI-Express x1 slot, but they will also work on higher-capacity slots (x4, x8, x16). Finally, if you will use Maestro with the EyeLink 1000+ eye tracker, you will need a second NIC for the private Ethernet connection to the EyeLink's "Host PC"; the Intel Gigabit CT or any other Windows-supported NIC will suffice for this purpose. Note that Maestro 4 drops support for all legacy devices, including the very old Detroit C6x and Dakar DSP board that controlled the XYScope target display. These legacy device require ISA or conventional PCI slots, which are not found in new workstations.
Message-signaled (MSI) vs line-based interrupts: The PCIe-6363 supports message-signaled interrupts; be sure that the NIC you choose for the RMVideo link also supports MSI (the Intel CT Gigabit adapter does). Hardware line-based interrupts, or IRQs, are an extremely limited resource on a PC, and one of the most difficult issues to overcome when configuring a computer to run older versions of Maestro was getting device-exclusive IRQ access for both the AI device and the RMVideo network card. Message-signaled interrupts eliminate this issue.
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 hardware 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.