keshang said

Heikki Tahvanainen said

Hello,

In the context of subscriptions, the delay can be measured in a number of ways: 1) based on the timestamp field of response header in publish responses, 2) from the publish time field of notification message (there is one notification message per publish response) or 3) from individual data value’s server or source timestamp.

The most correct way would be to use the timestamp of each individual data value. The specification states that the server timestamp is used to reflect the time that the server received a variable value or knew it to be accurate.

In Prosys OPC UA Java SDK example applications, this delay measurement could be implemented for example in MyUaClientListener.validatePublishResponse method. The logic is to take the timestamp from data values and compare it to current time at the client application. Notice that if the server and client applications are hosted on different machines, there might be big differences in the clocks of these machines.

Let us know how your measurements go.

Hi, thanks, I use the MyUaClientListener.validatePublishResponse method under your recommendation. I am not so sure whether I do it properly. My situation is: OPC UA Server is hosted on a Window 7 Computer, Client is hosted on a real Android Tablet（communicate through wifi router), the client monitor 40 DataItems. Then I wrote a line of Codes (Log.i(“———Print the Diff———->>”, diff);) in the validatePublishTime() method, see below. In Logcat of Android Studio, this “diff” number changes from 53500 to 54200 (millisecond). Is this right and normal?

private boolean validatePublishTime(DateTime publishTime) {
long diff = Math.abs(DateTime.currentTime().getTimeInMillis() – publishTime.getTimeInMillis());
Log.i(“———Print the Diff———->>”, diff);
return true;
}

Hi, after I synchronize the System Clock, the results ranges from 300 mllisecond to 1200 millisecond.

Heikki Tahvanainen said

Hello,

Good to know that your measurements are going fine.

Indeed, synchronizing the clocks on both systems is very important as this can cause huge differences in measurements.

The measurements of 300 milliseconds to 1200 milliseconds sound more realistic, even though I would say that these are still pretty big delays.

By the way, have you tried recording round-trip times of read service calls?

Hi, thanks. it is much better by round-trip test, the times range from 4 to 7 milliseconds. Is this normal? I think it’s too short and too quick.