Log In
Register
Forum
Topic RSS
10:12, EEST
February 9, 2016
Offline
Hi, now I have already developed a Android OPC UA Client, at the end I want to test the delivery delay: data is to be transfered from Server to Client, how much time it will takes? More specifically, the client program monitor a DataChange, if the DataChange happens in the Server, this data should be sent to the Client immediately, but this process will take some time, and how can I this delivery-time measure? Could you tell me a method to do this? Thanks in advance.
13:37, EEST
April 17, 2013
Offline
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.
17:00, EEST
February 9, 2016
Offline
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 (System.out.println(“———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());
System.out.println(“———Print the Diff———->>” + diff);
return true;
}
19:12, EEST
February 9, 2016
Offline
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.
14:52, EEST
April 17, 2013
Offline
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?
20:21, EEST
February 9, 2016
Offline
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.
9:01, EEST
April 17, 2013
Offline
Hi,
Round-trip times of 4 to 7 milliseconds are normal. If you test round-trip times with no network effect (server and client on the same host computer), you should see round-trip times of about 1 millisecond. Using real network of course introduces delays and in your case with wifi network, the round-trip times of 4 to 7 milliseconds are normal.
You can also try to ping the server machine from the client machine to estimate the fastest possible round-trip time that could be achieved in the given network.
However, the subscription delay of 300 to 1200 milliseconds seem high compared to the read service round-trip times. In principle, the subscription delay should be smaller than read-service round-trip time because only one message is being transmitted. It’s hard to give any definite reason for this. Maybe the system clocks of the computers are still a little bit out of sync which introduces differences of a few hundred milliseconds?
Most Users Ever Online: 1919
Currently Online:
39 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 726
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1529
Posts: 6471
Newest Members:
gabriellabachus, Deakin, KTP25Zof, Wojciech Kubala, efrennowell431, wilfredostuart, caitlynfajardo, jeromechubb7, franciscagrimwad, adult_galleryModerators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1032, Jimmy Ni: 26, Matti Siponen: 349, Lusetti: 0
Administrators: admin: 1
