cRIO 9012 using SNTP, incorrect system time

[swenp]

Hi all,

we habe some problems synchronizing a cRIO 9012 via sntp.
The controller is configured according to this KB, so the ni-rt.ini is as follows:

[TIME SYNC]
source.rtc.enable= True
source.sntp.address= 10.251.18.201
source.sntp.enable= True
source.sntp.interval= 10
source.sntp.log= False
source.sntp.port= 123
source.sntp.verbose= True
source_priority= sntp;rtc;

LabVIEW RT 8.6.1 (full) is installed.
Watching the console we can see that the controller starts synchronizing upon startup,
however the system time differs 60s from the time the controller should
have retrieved. No errors shown on the console. In verbose mode, should the controller prompt

each synchronisation to the console or only once?

We tried to set 

source.sntp.log=True

but could not find the log file for further investigations.
Anybody knows were it should be located?

We tried to set up another cRIO controller, 9002 with LabVIEW RT 8.6.1 (full) installed. But this one
prompts "could not load sntp driver" upon start up to the console? Why that?

Any hints?

Best regards,

Swen

Message Edited by swenp on 10-21-2009 08:34 AM

Message Edited by swenp on 10-21-2009 08:34 AM

[swenp]

In addition to my last post: The correct error message that appears on the console of the controller that does not even start synchronizing is:

Unable to load time sync source: sntp (Unable to load time source driver.)

 

[swenp]

The controller that synchronizes but incorrectly is not always exactly 60s off time, but mostly 60s +/- a few seconds. Sometimes it gets closer

to the correct server time (~10s-20s).

Swen

[speleato]

Hello Swenp,

Just curious, what sort of network is there between the server and the cRIO?  Is it possible to try them on a private network?

Thanks,

Sebastian

[swenp]

Hi Sebastian,

thanks for your reply.

The cRIO and the time server are on the same subnet connected by a switch.

The controller is running standalone as a data aquisition device and is distributing the data by TCP/IP, maybe the load on the TCP/IP stack is interfering with the timesynch process?

It is difficult to debug because it is already running in the field and I can not get the controllers available (9002) to do sntp as I mentioned before

I am trying to get a network trace of the synch process, maybe that can help.

Regards,

Swen

Message Edited by swenp on 10-22-2009 09:26 AM

[speleato]

Swen,

I can't find a reference now, but I'm think SNTP is only supported on VxWorks controllers.  The 9002 is Pharlap, so that's likely why it is not working.

As for the network,what you are describing sounds reasonable (in that there isn't a lot of networking equipment between the server and the cRIO).  How heavily utilized is this network?

I'm not totally clear on what the effect of high TCP/IP stack load could be.  It certainly seems plausible though that very high utilization of the network device could interfere with SNTP.  Can you determine from the console if in the event of a reboot (assuming you can safely reboot the deployed system) the first SNTP synchronization happens before or after the startup app loads.  How much data are you moving from the cRIO?  Along the same vein what does the CPU utilization look like on the controller?

Also would you be able to ping the controller from the server just to make sure the network latency is reasonable?  Similarly the results of tracert to the controller would be interesting.

Sebastian

[speleato]

Just another question, what are you using as an SNTP server?

Sebastian

[swenp]

Sebastian,

the server is the meinberg server running on a windows machine. According to te console the startup application starts  after the first sntp sync, so there shouldn't be any traffic on the controllers TCP/IP stack at this moment. It is sending aprox. 300Bytes data with 20Hz to the network, about the total utilization of the network I can't tell.

Getting a trace it not easy as we can not install new software on the server machine or plug a hub into the network. But I finally managed to get a sbRIO9612 with VxWorks running in my office and it is synchronizing to my office box. So it seems as if PharLap is not supported when using sntp.

I traced the connection between this sbRIO and my (meinberg) ntp server and found, that the controller does not fill the "Transmit Timestam" field in the request packet as it should according to RFC4330. Thus, the server responses with the "OriginateTimestamp" field and value NULL. I wonder how the controller calculates the roundtrip delay and system clock offset without this value? Or is it just adapting the transmit time from the server without further calculations? However, the synchronizations seems to be working, I will evaluate this tomorrow.

Thanks,

Swen