ICU startup on high latency networks

Thank you for sharing your idea! We've reviewed it, and determined it's not something we plan to implement right now, as we are focusing our efforts on other high priority areas in our data collection suite of products. However, this idea has been added to our backlog for future consideration.

This is also a problem on faster networks in large systems. Could ICU search the database more efficiently so it only reads the interface configurations for the local machine? We have hundreds of interfaces that are spread over approximately 100 machines which connect to the same collective. Even on the collective's local network it can take a few minutes for ICU to finish reading all of the configurations.

Same boat. They need a better solution here. 10 minuets is short! Ours can take over 45 min.

For PI monitoring purpose we install on several PI Interface Nodes and PI/AF Servers some monitoring Pi-interfaces (PerfMon, TCP-Response and SNMP) and all of this interface write tags on a centralize PI Server. When you open the ICU on a monitored PI machine, it scans all the interfaces on the target servers, also the ones installed on others monitored machines: for example, if there is a PerfMon installed on “HOST1” and another on “HOST2” where both are collecting data of the hosting machine and both are pointing to the centralized monitoring PI server, when I start the ICU on “HOST1” it try to loading both interfaces (“HOST1” and “HOST2”). This is a very big problem in term of ICU loading time in case of several interfaces installed each one on different “HOST” that pointing to the same centralized PI server (this is the monitoring scenario, but we have the same problem also for loading PI2PI that are pointing to a centralized PI concentrator). I thought that the ICU loads the data from the ModuleDB (MDB) of the target PI server: right now all the monitoring interface are connected to monitoring PI server with the same user that has Read access to all MDB items. I tried to manage the Trust/Mapping in order to use different PI Indentity and give to a determinate PI Identity the access only to the related Machine/Interfaces on MDB. I did the following steps as a first test: 1) Create a new Pi-Identity “ID1” on the monitoring PI server (destiantion of the interfaces) 2) Modify the Mapping/Trust on the monitoring Pi server in order to use “ID1” only for Perfom/TCP-Response/SNMP Interfaces installed on “HOST1” 3) Edit the MDB access rights as below: %OSI → removed R access for PiWord + added R/W access for “ID1” Interfaces → added R/W access for “ID1” “HOST1” → added R/W access for “ID1” “PIPerfMon_HOST1” → added R/W access for “ID1” “PISNMPTrap_HOST1”→ added R/W access for “ID1” “TCPResp_HOST1”→ added R/W access for “ID1” After that, I tried to start again the ICU on “HOST1” but the attached error appeared. Then, I did the following additional activities: 1) add the R/W access for “ID1” identity on “PIModules” table of database security on the centralized monitoring PI server 2) Edit the MDB access rights as below (in addiction of rights edited before): %OSI → added R access for PiWord After that I tried to start again the ICU on “HOST1” but it starts to “searching for ISU instances for..” each machine on the target MDB tree (see “SearchingForISU.PNG” attached). To recap, this is the same issue saw before start the activity described here. So as far as I understood the problem seems: ICU searchs ISU (Iterface Status Utility - that seems a legacy utility: https://techsupport.osisoft.com/Products/Interfaces/PI-Interface-Status-Utility/Overview) on each interface on the MDB of the PI servers (or colledtive) selected to be loaded on ICU.

I agree, it is a killer. I have had to revert to old-style sometimes, where I do not use ICU but write the interface files in notepad, not the best solution, but functional. Maybe it is time this is written into AF instead of mdb.

This is really a bad situation. The "workaround" I have is to open the ICU in the morning and schedule my activities for the afternoon

PI ICU takes a considerable amount of time time to load when multiple interfaces are used with the same data archive collective. This would be a very useful improvement to the product if the time is reduced and will help PI system admins a lot.

The most significant delay we experience is during the "Checking for ISU instances" part of the loading process. A simple checkbox to disable checking for ISU instances would be a huge improvement

This is a big problem for me. I am setting up 21 PI-to-PI interfaces for UniInt failover. The souce PI DA Server and the interface machine are both on-prem and the target PI DA Server is in the cloud. Ping times from the interface machine to the cloud are around 85ms. The ICU takes several minutes to load an interface, several minutes to gather the failover details, several minutes to save an interface, several minutes to start an interface and several minutes to load the next interface. What should take me an hour is taking an extremely stressful day.