sbRIO Shared Variables deployment very slow

[patufet_99]

We have an application where we communicate to a sbRIO target through Shared Variables. When the host/target are both on the local network all works fine (both are configured with a Static IP address). When both are connected directly with an ethernet cable, the deployement of the Shared Variables on the sbRIO target is extremely slow (5-10 seconds). This behaviour happens only if a DNS server address is defined. As the Shared Variables are deployed locally on the sbRIO, why the DNS server (if there is none) should have any effect on the deployment? Any hints?

[JKSH]

On 9/16/2018 at 9:40 PM, patufet_99 said:

As the Shared Variables are deployed locally on the sbRIO, why the DNS server (if there is none) should have any effect on the deployment? Any hints?

Here is my guess:

1. Your PC tries to contact the DNS server at the defined address.
2. The PC waits for a response from the DNS server. However, since the DNS server is not reachable, there is no response. So, the PC waits 5-10 s until the timeout is reached.
3. After the DNS server connection times out, the PC proceeds to do its next task: Deploy shared variables.

When both devices are on the network, step #2 is very fast so you reach step #3 very quickly.

[smithd]

section 2.2 here may apply: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P6vdSAC

Edited September 19, 2018 by smithd

[patufet_99]

Thank you for your comments. This seems to be as you mention and due to DNS timeouts as explained in the 2.2 of the upper link.

JKSH: This is on the RT side, not the PC: if a non valid DNS server is defined in the PC there is no problem.

As you say, section 2.2:

Quote

2. Check the DNS IP on the RT target.  If this IP is set to something that is not a valid DNS server, the shared variables will update slowly due to DNS timeouts that occur.  By changing this entry to 0.0.0.0, the shared variables should update at the appropriate rate.

So this is clearly the expected behaviour.

I just wondered of the reason: the call to shared variables on the RT side are all Target Relative to the local target. It's on the PC side that the PC are accessed through direct IP by programmatic Access.

 

[JKSH]

20 hours ago, patufet_99 said:

Thank you for your comments. This seems to be as you mention and due to DNS timeouts as explained in the 2.2 of the upper link.

JKSH: This is on the RT side, not the PC: if a non valid DNS server is defined in the PC there is no problem.

Here is my updated guess:

1. The sbRIO first tries to contact the DNS server at the defined address.
2. The sbRIO waits for a response from the DNS server. However, since the DNS server is not reachable, there is no response. So, the sbRIO waits 5-10 s until the timeout is reached.
3. After the DNS server connection times out, the sbRIO proceeds to do its next task: Accept a shared variable deployment from the PC.

In a nutshell, it looks like networking and the Shared Variable Engine are synchronous. While the sbRIO is waiting for a response from a remote device, it cannot process any other network requests related to Shared Variables.

I've seen similar symptoms in another case: My CompactRIO was trying to read a Shared Variable hosted on a PC. However, my PC's firewall was not configured properly so the cRIO was not allowed to read the SV. As a result, all other Target-Relative variables hosted on the cRIO froze for long periods of time