This question was created in reference to: [NDisplay: low FPS / [Content removed]
Unfortunately, we cannot extract traces from the site but in a nutshell, we are seeing massive (150 ms - 200 ms) delay in network receive calls from cluster events / sync packets. The spike could be seen within any of the node.
Based on our previous experience, we installed pcap and wireshark on the system to get a closer understanding and try to isolate the problem. Once this was done, the delays could not be seen anymore.
Are you aware of any requirement for networking / behavior that would be solved by a pcap installation on windows 11. Network driver and settings were not modified from our hand when installing the tool.
Thanks for any inputs,
Basile
[Attachment Removed]
Steps to Reproduce
Hi,
This is a followup question to the other thread we opened a while back.
Getting on end user site for the deployment, we observed much frame drops failing to achieve stable 60 Hz.
Patterns were similar to those observed / resolved earlier in the year.
Questions in the description panel.
Thanks,
[Attachment Removed]
Hi,
For reference and hopefully helping other users, …
We were able to reproduce the patterns on a simplified systems which did not receive the pcap installation. Within the network driver (intel in our case), there is a setting to select whether moderation should be applied.
Microsft is sharing some details here :
https://learn.microsoft.com/en\-us/windows\-hardware/drivers/network/interrupt\-moderation
[Attachment Removed]
Hey Basile,
Sorry for answering so late. It took some time before this case came to my hands.
Could you try the following registry settings? There was feedback from a licensee about similar, if not the same, issue.
KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile
“NetworkThrottlingIndex”=dword:ffffffff
“SystemResponsiveness”=dword:00000000
[Attachment Removed]
Hi Andrey,
I was the one providinig the registry entries when I investigated the issue on our reference platform back in January.
In the present case, we applied, on the end user site, the settings prior to the visit and we saw similar (unexpected network latency) but different (magnitude order, …) and we started another round of investigation.
As I mentioned, installing pcap did resolve the problem and we asked your opinion as why it could do this. While this worked in the moment, this is not acceptable for the (restricted) network hosting the system and we kept investigating.
According to the latest tests, disabling interrupt moderation resolved the problem in a “better” way and this is why I shared the feedback.
We are still facing some networking anomalies at the moment but they are pointing to switch rules / policies rather than nDisplay. I hope this will be resolved soon !
Thanks,
Basile
[Attachment Removed]
Hi,
I am receiving feedback from the site. It seems that the udp messaging plugin is triggering the failure that we are seeing :
https://dev.epicgames.com/documentation/unreal\-engine/udp\-messaging\-settings\-in\-the\-unreal\-engine\-project\-settings
For a complete background, we have a cluster of 6 computers with multiple Network Interfaces Controller (NIC) each. The nodes are receiving a simulation feed using multicast on a dedicated NIC and the UDP messaging plugin is enabled on the nDisplay NIC:
- When we start the cluster with UDP messaging enabled, the simulation is *no more* received on the nodes.
- When we start the cluster with UDP messaging *disabled*, the simulation is not affected and all nodes are properly seeing the messages.
Can you elaborate on the plugin utility and what features / capabilities it provides ?
The documentation I shared above highlights its configuration but not really its purpose.
Thanks,
Basile
[Attachment Removed]
Hi Basile,
Can you provide more details? UDP Messaging is a plugin that is used to communicate with other Unreal Engines via Unreal’s message bus framework. It does join a multicast group to announce itself to other editors and maybe that is causing the conflict. You can adjust the multicast group settings on launch such that it doesn’t try to listen to other editors / engines that may be on you network. This can be controlled in Switchboard. In versions 5.7 there were issues where it would try to talk to other editors on the network because (by default) it would bind to all adapters and join to the multicast group for each adapter. You can narrow the scope of this by selecting a different adapter that is not shared with your cluster.
Jason
[Attachment Removed]
Hi Jason,
The information I got from the site and the network administrators is the following :
When the cluster is starting, it is opening / sending information to the multicast socket. While the address is indeed different, there is a binding between the group and the MAC address within the switch. That association is breaking the previous binding done by the simulation as the address is in the same “broadcast / multicast” range.
In our present case, we are using a 6 node cluster synchronized by ndisplay and we are managing the processes (no switchboard involved).
Can you confirm :
- We can safely disable the UDP messaging (i.e. ndisplay does not rely on it)
- Which services would be lost by disabling it (remote traces ? … )
- Which command line argument allow the adapter selection (UDPMESSAGING_TRANSPORT_UNICAST) as you mention ? In the restricted environment, this will be desired.
Thanks,
Basile
[Attachment Removed]