Skip navigation
All Places > PI Developers Club > Blog > 2009 > November



The PI Software Development Kit (PI SDK) is a programming library providing access to PI Servers. The product is primarily middleware in that it provides an interface between the PI Server back-end and end-user applications.


PI-SDK communications


PI SDK communicates to the PI Server through the local PI-Network Manager (pinetmgr) which in turn opens a TCP\IP connection to the pinetmgr on the PI Server. The protocol that is used at the application layer is referred as PINET3.




One of the known inefficiencies in PI SDK, more specifically PINET3 put data in 4kb message blocks and  an ACK message is sent for every 4kb message. This causes additional overhead, and causing PI SDK to perform badly especially in high-latency network.


Improvement in 3.4.380 PI Network Manager


The improvement of the PI Network Manager in 3.4.380 is mainly targeted at eliminate the known inefficiency. This makes the PI SDK client perform better with PI 3.4.380 compared to PI 3.4.375 and earlier versions. This can be tested by measuring the time taken for an SDK client to complete a call for data from the servers. For convenience in the rest of the blog post, I shall refer to the 3.4.380 PI Network Manager as "PINET380" whereas the older version shall be referred as "PINET375"


For testing, I created a very simple PI SDK program in Visual C# 2008 with PI-SDK The program is only intended to read archived data from a PI tag for a period of time. The specific SDK call is PISDK.PIPoint.PIData.RecordedValues().


A way to measure the time taken for the call is to measure the time before the call and after the call. Alternatively, we can perform PI SDK tracing to log the PI SDK connection and operations (see the "Troubleshooting" article in the PI SDK Programming Reference, available on the OSIsoft vCampus Library). We can set the debug level to "Wire Calls" or "Verbose" to see the time spend TCP/IP communicates for the call.


The parameters that are varied include

  • Latency
    In terms of latency, I have simply varied it changing my connection setup, 1st by connecting to the servers through wireless LAN and also connecting to an external network and connecting to the servers via VPN, which drastically increases latency because traffic is routed to OSIsoft's San Leandro HQ before coming back to OSIsoft Singapore.
  • Number of Events
    This is pretty straight-forward, the start and end time of the PI SDK call is adjusted to retrieve different amounts of data.

Running the test for a couple of times to get an average of response time, and here's the results that I have


When running test on a client in the same wireless network as the servers


When the network condition is good, with high bandwidth and low latency, we can see that reading from PINET380 has slight improvements in comparison to PINET375 but generally it is not significant to affect user's experiences.

When running test on a client connecting to the servers via VPN through wide area network


However if we look at the results in a situation where network has high latency (about 400 to 500 ms measure with PING), the results generally still shows that PINET380 performs better than PINET375. The difference would show if you are grabbing large amounts of data out at one shot. 




When running test on client connects to servers through wide area network with high retransmission


Another situation that I managed to get is a case where the network is bad enough that a lot of retransmission traffic is observed using Wireshark. In this case, this is really where significant difference in performance is observed. Because of the overhead, PINET375 performs significantly slower compared to PINET380.




The results do show that there is a significant increase in the performance when we are in a situation with high latency. If you have a lot of users reading data from the PI Server via a high latency network, you probably find it helpful to upgrade the PI server for the performance improvement.


In closing, I still like to highlight the fact that we are still subjected to other factors that can cause performance to degrade, like server performance, client machine's load. Upgrading to the new PI Server should not be regarded as a move that guarantees improvement in performance in all cases.


One last thing to note is that even the latest PI SDK release is packaged with PINET375. This means that any API node without PI server installed will only have PINET375. Any connection from a PINET375 node to PINET380 server will only enjoy the performance improvement when reading data from the server but not the other way round, until PINET380 is released with PI SDK.

I've been traveling quite a bit last month, visiting customers and presenting at our Regional Seminars in Atlanta and Raleigh. I'm also preparing for talks at OSIsoft vCampus Live!, so things have been busy toward the end of this year...


With all this going on, I wanted to take a moment to share our plans on AF support in PI Data Access Tools. As you know, we already have a couple ways to read/write AF data - AF SDK and PI OLEDB 4.0 (beta announcement is here).


It turns out, due to our JDBC-OLEDB bridge architecture, that PI JDBC will also support AF. In fact, the current PI JDBC Driver 1.0 can connect to PI OLEDB 4.0 Beta to access AF. All you need to do is specify "Provider=PISysOLEDB" in the connection string. (Note, this provider name may change in the PI OLEDB 4.0 release version).


Using PI JDBC 1.0 with PI OLEDB 4.0 provides same AF functionality as using PI OLEDB directly. This means vCampus folks can use PI JDBC now to access PI data, and be assured there is a path forward to access AF data as well.


UPDATE 11/6/09: For non-beta or non-dev systems, the recommended solution is to wait for PI JDBC 1.1 to use with PI OLEDB 4.0.  We plan to document, test, and support this combination of products.

Filter Blog

By date: By tag: