Realtime FAQ


FAQ1013: Firmware settings regarding realtime optimization

WARNING:
You are changing firmware settings on your own risk.
Every system is different and changing a setting might work for one system but prevent another from starting or even cause physical damage.
Please ensure you know how to clear settings in case the system does not start any more.

It is a wise strategy is to note every change and modify only one setting at a time. Some will require a power cycle to make them effective.
Generally said it is always "power saving" versus "latency" so disabling power savings typically reduces latency.

List of settings known to influence latency behaviour:

Disable when available:

  • Intel Turbo Boost Technology
  • Enhanced Intel Speed Step (EIST)
  • Intel Hyper-Threading Technology (HT)
  • C-States
  • Intel Speed Shift Technology (SST)
  • PCI Express Link ASPM Control
  • DMI Link ASPM Control
  • Aggressive LPM Support
  • Render Standby (RC6)
  • GT PM Support
  • PCI Clock Gating
  • Throttling (Thermal, PCH, ...)

Enable when available:

  • Legacy IO Low Latency

Set when available:

  • 0 for offset of Thermal Control Circuit (TCC) activation temperature
  • Fixed (high) for SA Speed Enhanced Speed Steps (SA-GV)

You know other firmware settings optimizing realtime behaviour? Let us know and we can add them here.

Last update on 2022-04-26 by Realtime Support Team.

FAQ1012: Why is it important to configure the system properly before creating a virtual dongle (CmAct) license request?

The virtual dongle locks to the hardware found. Assigning processors or devices to RTOS will change this configuration from the virtual dongles point of view.

We use the recommended medium tolerance level for our licenses so not every change has to break the license but it is strongly recommended to create the license not before the system is configured properly - meaning:

  • Configure the correct number of CPUs for Windows and RTOS.
  • The devices designated for RTOS should already be assigned (especially network cards).
  • Remove all optional or temporary installed device from the system (especially network cards).

This will ensure the license can bind to the proper hardware.

Last update on 2022-04-26 by Realtime Support Team.

FAQ1011: The network card uses an address different from the one manually configured.

Our "Realtime OS Virtual Network Adapter" network address on Windows is typically "192.168.157.1". In rare cases the configured value is ignored by the card.
The TCP/IP dialog setting should be verified against the output of the shell command "ipconfig /all".
 
The reason is most likely a corrupted network stack where the (index based) configurations and cards got out of sync.
We observed such behaviour in the context of updating network driver and adding/removing network adapter.
 
There are several solutions:
- Use "192.168.157.3" instead of "192.168.157.1". It is an easy workaround when "192.168.157.1" is not a requirement.
- "reset network stack" is also possible. Searching the web for this brings up several articles describing the process.
- Another option is to uninstall all network card drivers (do not remove the driver packages), reboot and let Windows find and install the driver again.
Warning: All manual network settings will be lost with the later two options and have to be restored.

Last update on 2022-04-26 by Realtime Support Team.

FAQ1010: How to gather information required to analyze software dongle (CmAct) license problems

To analyze CmAct problems the following information might be required:

  1. CmDust-Result.log - instruction below
  2. Logs
    Windows: C:\ProgramData\CodeMeter\Logs
    Linux: /var/logs/CodeMeter
  3. License files
    Windows: C:\ProgramData\CodeMeter\CmAct
    Linux: /var/lib/CodeMeter/CmAct

CmDust-Result.log instructions

  • Windows
    Open Start -> CodeMeter -> CmDust
    Program will close immediately and open file explorer at created "CmDust-Result.log".
  • Linux
    Run "cmu --cmdust --file CmDust-Result.log" to create the file.

Last update on 2022-04-26 by Realtime Support Team.

FAQ1009: How to solve an interrupt conflict

There is an interrupt conflict when at least two devices, one from RTOS and one not, are sharing the same physical wire for signaling an interrupt. This way a non RTOS device could interrupt RTOS resulting in the loss of realtime capability.
 
A possible solution is
  • to assign the device without an interrupt. This requires specialized software and driver for the device on RTOS side like our Ethercat-LinkLayer. This solution does not work for any standard driver because they always expect the interrupt to be available.
  • to use Message-Signaled-Interrupts (MSI) instead of the legacy line interrupt. This must be supported by the device and driver but will avoid any conflict.
  • to put the device into another slot. Typically the interrupt lines are swapped between the slots so another line should be used.
  • to disable the conflicting non-RTOS device or also assign it to RTOS.
    In very rare cases host configuration allows the non-RTOS devices to be configured without an interrupt (like LPT for example).
  • to use a more recent or alternative version of the device supporting MSI.
 
If the conflict can't be solved this device can't be used for realtime on this platform due to the shared interrupt.
 

Last update on 2021-09-07 by Realtime Support Team.

FAQ1008: How to enable VT-x support only (without enabling VT-d)

Enabling VT-x without enabling VT-d is only useful for test purposes as no physical devices which need DMA support will work then. This may be usedful for example to determine if SMIs can be suppressed.

VT-x only can be enabled using the following config file entry:

[Vmf]
"VtAllowed"=dword:5

Last update on 2021-03-15 by Realtime Support Team.

FAQ1007: How to get an update for the RTOS32Win, RT-Win and EC-Win(RTOS-32) products?

Request an update from acontis through the following site: https://developer.acontis.com/ethercat-latest-versions.html

You will get the latest version then from acontis.

Check the On Time RTOS-32 version which is required for the update.

If necessary, update your On Time RTOS-32 version to this version. Do not use a different version, this is not supported by acontis.

Last update on 2020-12-17 by Realtime Support Team.

FAQ1006: How can I create my own setup?

Please checkout chapter 15 Appendix C - "Installation" of RtosVM-UserManual.pdf.

Last update on 2020-12-17 by Realtime Support Team.

FAQ1004: How can I generate an Error Report using the System Manager?

The following steps have to be executed to generate the error report:

  1. Start System Manager
  2. Load the Virtual Machine
    Start VMF
  3. Ignore the error message (e.g. cancel), do not stop the System Manager or shutdown Windows
  4. Generate the error report
    Generate Report

Last update on 2020-12-17 by Realtime Support Team.

FAQ1003: How can I get a virtual dongle to unlock my target?

Please checkout the following document RtosVM-UserManual-Licensing.pdf.

Last update on 2020-12-17 by Realtime Support Team.

FAQ1002: Can I use hyperthreading?

It can be enabled, but it is not recommended as the jitter will be significant higher and real-time behavior in most cases is not acceptable.

Last update on 2020-12-17 by Realtime Support Team.

FAQ1001: How can I determine, if my hardware is capable to run Real-time applications?

Please checkout our PC-Hardware and Real-time Optimization section.

Last update on 2020-12-17 by Realtime Support Team.

FAQ1000: Error 0x0022270B - Timer frequency measurement delay limit reached

The measuring periods to determine the timer input frequency varied above a minimum.

In case of problems regarding timer period (e.g. clock drift between master and slaves) this message indicates a possible reason. It can be ignored in other cases.

The message can be disabled using the following config file entry:

[Vmf]
"TimerMeasureDelayLimit"=dword:0

Disabling the message as no negative side effects.

Last update on 2021-03-15 by Realtime Support Team.

Back to top

FAQ1205: How to add .NET Core to the rtlinux image

Take package sources_x64.tar.xz from the LxWin installation and extract it.

Build LxWin image at first using the command:
./build.sh x64

In this manual it is assumed that the file build.sh is located at "/home/rte/build_test/sources_x64/" folder and all commands in the bash shell are executed from this folder.

Additional repositories are required for dotnet-core. Start the following commands:
git clone -b thud git://git.openembedded.org/meta-openembedded
git clone -b thud git://git.yoctoproject.org/meta-security
git clone -b thud https://github.com/RDunkley/meta-dotnet-core.git
git -C meta-dotnet-core checkout 1ae36889cf

Modify bblayers.conf file located at /home/rte/build_test/sources_x64/poky/build/conf and add new yocto layers.
BBLAYERS variable value should look like:
BBLAYERS ?= " \
/home/rte/build_test/sources_x64/poky/meta \
/home/rte/build_test/sources_x64/poky/meta-poky \
/home/rte/build_test/sources_x64/poky/meta-yocto-bsp \
/home/rte/build_test/sources_x64/meta-openembedded/meta-oe \
/home/rte/build_test/sources_x64/meta-openembedded/meta-networking \
/home/rte/build_test/sources_x64/meta-openembedded/meta-perl \
/home/rte/build_test/sources_x64/meta-openembedded/meta-python \
/home/rte/build_test/sources_x64/meta-security \
/home/rte/build_test/sources_x64/meta-dotnet-core \
/home/rte/build_test/sources_x64/sources/Source/yocto \
"

Create new file /home/rte/build_test/sources_x64/sources/Source/yocto/recipes-runtime/dotnet-core/dotnet-core_3.0.0.bbappend and corresponding directories.

Add the following lines to the dotnet-core_3.0.0.bbappend file:
DOTNET_RUNTIME_ARCH_vmf64 = "x64"
INSANE_SKIP_${PN} += "ldflags"
INSANE_SKIP_${PN}-dev += "ldflags"
RDEPENDS_${PN} += "libgssapi-krb5"
require recipes-runtime/dotnet-core/dotnet-core_3.0.0_${DOTNET_RUNTIME_ARCH}.inc

In file /home/rte/build_test/sources_x64/sources/Source/yocto/recipes-core/images/rtlinux-image-initramfs.bb add "dotnet-core" to the PACKAGE_INSTALL variable.

In file /home/rte/build_test/sources_x64/sources/Source/yocto/conf/layer.conf change value of variable INITRAMFS_MAXSIZE to "400000"

Start build again with the command:
./build.sh x64

The compiled image is located at /home/rte/build_test/sources_x64/delivery/Bin/ directory. The new image is bigger as default one and you should increase memory size used by LxWin.

Last update on 2022-03-11 by Realtime Support Team.

FAQ1204: How to add new user to rtlinux

By default, acontis deploys images with a root user only. To add a new user, you should change the file sources/Source/yocto/conf/layer.conf and add the following lines:

EXTRA_USERS_PARAMS += "useradd -p 'KQTFYntUHrfzA' myuser"

where myuser is a user name, and 'KQTFYntUHrfzA' is a result of the encrypted password "vmf".

To create encrypted password "vmf", you can run the command in bash: openssl passwd vmf

Last update on 2022-02-21 by Realtime Support Team.

FAQ1203: How to change host name

When the rtlinux is started you can see a welcome string with the name of the host:

LxWin (acontis distro based on poky) 1.0 vmf64 /dev/console

vmf64 login: root

where "vmf64" is the host name, equal of MACHINE name in yocto.

 

To change the hostname you should edit sources/Source/yocto/conf/machine/vmf64.conf file (or vmf.conf for 32-bit rtlinux) and add the following line:

hostname_pn-base-files = "your_hostname"

Last update on 2022-02-21 by Realtime Support Team.

FAQ1202: How can I automatically start an application with command line parameters

Open the user configuration file and add 2 keys "Executable" and "Parameter".
"Executable" defines the path to the application that shall be started, "Parameter" will be used a the application's commandline parameter.
Here is an example of how to start the command "find / -iname rtos*" when Linux is booted,
[Rtos\Autostart\1]
"Executable"="find"
"Parameter"="/ -iname rtos*"

Last update on 2021-02-17 by Realtime Support Team.

FAQ1201: How can I achieve better real-time performance

  1. Starting with LxWin 7.1.1 you can use rtos_nanosleep to introduce a guard band around the timer interrupt. Within this guard band no additional timer interrupts will be generated.
    Example Code Snippet here.
  2. Change the communication mechansim from interrupt mode to polling mode. This will avoid critical code being interrupted by Windows/Linux communication activities. Caveat: Windows/Linux communication performance may be reduced.
    Add the following configuration settings:
    [Rtos\Comm]
        "CommInterruptMode"=dword:0         ; Mode: 0=polling, 1=interrupt
    [Rtos\Vnet]
        "PollingPeriodMs"=dword:1                  ; Mode: 0=interrupt, 1 and more for polling

     

Last update on 2021-02-17 by Realtime Support Team.

FAQ1200: LxWin: How to start a script automatically

Please follow these steps to run a script that is started along with Linux.

  1. Create a script file inside workspace\RtFiles folder.
  2. The script can contain Linux shell commands or call applications.. You can also call other scripts.
  3. Add a new [Rtos\Autostart\1] key into the configuration and assign the script name to the "Executable" parameter.
    Example:
    [Rtos\Autostart\1]
    "Executable"="/mnt/rtfiles/cifs_mnt.sh"

See also the chapter “5.5 Access Windows file system using Samba” in the “LxWin Product Manuel”, here you can find an example of how to start a script.

Last update on 2021-02-16 by Realtime Support Team.

Back to top