Kenneth Barber

My feedback

  1. 3 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  myOSIsoft » Product Downloads  ·  Flag idea as inappropriate…  ·  Admin →
    Kenneth Barber supported this idea  · 
  2. 3 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  myOSIsoft » Services  ·  Flag idea as inappropriate…  ·  Admin →
    Kenneth Barber supported this idea  · 
  3. 1 vote
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  NOC Services » General  ·  Flag idea as inappropriate…  ·  Admin →
    Kenneth Barber shared this idea  · 
  4. 1 vote
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  NOC Services » General  ·  Flag idea as inappropriate…  ·  Admin →
    Kenneth Barber shared this idea  · 
  5. 63 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    9 comments  ·  PI Connectors » New PI Connector request  ·  Flag idea as inappropriate…  ·  Admin →

    From this item description it looks like the major pain point with existing RDBMS interface is providing configuration information (to the tags and interface). I would like to understand more if the request behind the connector is to solely minimize providing configuration information to the existing interface and tags?

    An error occurred while saving the comment
    Kenneth Barber commented  · 

    I know that the PI Connector For RDBMS is my own suggestion, but I feel like the one linked below makes this obsolete. The suggestion is for a PI Connector For Power BI Desktop. Power BI Desktop can handle relational database sources and much, much more, and its query language (Power Query) is much easier to learn, read, and write than SQL.
    https://feedback.osisoft.com/forums/555139-pi-connectors/suggestions/40518250-pi-connector-for-power-bi-desktop-the-swiss-army

    An error occurred while saving the comment
    Kenneth Barber commented  · 

    In response to Abbas, the request is not solely for the purpose of minimizing the entry of configuration information. OSIsoft is moving away from PI Interfaces and towards PI Connectors, so it would make sense to make a PI Connector based on one of the most used PI Interfaces. As I demonstrated in my original post, this is also OSIsoft's chance to redesign and improve how RDBMS data gets into PI.

    A PI Connector for RDBMS would give us the usual benefits of PI Connectors: remote configuration, configuration in a resizable window, self-buffering, higher performance, and increased security.

    A PI Connector for RDBMS would also help quicken the deaths of the PI Buffer Subsystem, PI ICU, and the PI Module Database, which is still used to store the PI ICU information of PI Interfaces. Those are 3 less things for PI administrators to worry about.

    Kenneth Barber shared this idea  · 
  6. 83 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    RESEARCHING / EVALUATING  ·  4 comments  ·  PI Connectors » UFL  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Kenneth Barber commented  · 

    It's interesting that you mention Power Query in Power BI as being a good example. I don't see any reason why we can't just use Power Query in Power BI as the method of extracting data from text files, or any non-real-time data sources for that matter. Then we wouldn't need the INI file language at all.
    https://feedback.osisoft.com/forums/555139-pi-connectors/suggestions/40518250-pi-connector-for-power-bi-desktop-the-swiss-army

    Kenneth Barber supported this idea  · 
  7. 1 vote
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PI Connectors » New PI Connector request  ·  Flag idea as inappropriate…  ·  Admin →
    Kenneth Barber shared this idea  · 
  8. 1 vote
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  myOSIsoft » General  ·  Flag idea as inappropriate…  ·  Admin →
    Kenneth Barber shared this idea  · 
  9. 4 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  myOSIsoft » General  ·  Flag idea as inappropriate…  ·  Admin →
    Kenneth Barber supported this idea  · 
  10. 24 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  myOSIsoft » Customer Portal Overall  ·  Flag idea as inappropriate…  ·  Admin →
    Kenneth Barber supported this idea  · 
  11. 1 vote
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  NOC Services » General  ·  Flag idea as inappropriate…  ·  Admin →
    Kenneth Barber shared this idea  · 
  12. 2 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  NOC Services » Security  ·  Flag idea as inappropriate…  ·  Admin →
    Kenneth Barber shared this idea  · 
  13. 1 vote
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    7 comments  ·  PI Server » Data Archive  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Kenneth Barber commented  · 

    As it turns out, the archives that I've been testing compress well mostly because of a high number of unused records:
    https://feedback.osisoft.com/forums/555148-pi-server/suggestions/33078940-reduce-archive-file-size-by-eliminating-unused-rec

    An error occurred while saving the comment
    Kenneth Barber commented  · 

    Hi Stephen,

    I actually already reprocessed all of our archive files in an attempt to save space. The % Full decreased by a few %, but since they are fixed-size archives, the size on disk didn't change. However, when I use disk compression on the files, most of the archives shrink to less than half of their original size. As I mentioned, our tags use an excmax of 18 hours, which should lead to pretty decent lossy compression, and yet even with that in place, the archives still compress very well losslessly.

    I'll take your advice and contact tech support. Right now I'm pointing the finger at digital tags with little evidence.

    An error occurred while saving the comment
    Kenneth Barber commented  · 

    Hi Stephen,

    Can you elaborate on what you mean by "configuring the compression setting properly"? I know that you can get great compression if you set excmax and compmax to be extremely high so then a value is recorded only when it changes, but a user might not want to do that so then they have events confirming that the value did indeed stay constant and that the PI Interface/PI Connector wasn't just turned off. When there are no events for a long time, you can't tell if they were dropped by exception and compression or not read at all.

    I was thinking that digital values could perhaps be stored as a list of timestamps for each possible value rather than storing events as pairs of timestamp and value, or something similar. Nothing too hardcore.

    If digital tags are already well optimized for storage, then why do you suspect that disk compression shrinks the archive files so much? The digital tags in the archives that I used use an excmax of 18 hours and have compression turned off.

    An error occurred while saving the comment
    Kenneth Barber shared this idea  · 
  14. 7 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  PI Server » Data Archive  ·  Flag idea as inappropriate…  ·  Admin →
    Kenneth Barber supported this idea  · 
  15. 1 vote
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  PI Server » Data Archive  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Kenneth Barber commented  · 

    Why do you need to use a digital state set? Why not an integer type?

  16. 2 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  PI Server » Data Archive  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Kenneth Barber commented  · 

    In what case would this be better than using annotations or a separate tag?

  17. 4 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  PI Server » Data Archive  ·  Flag idea as inappropriate…  ·  Admin →
    Kenneth Barber supported this idea  · 
  18. 3 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  PI Server » Data Archive  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Kenneth Barber commented  · 

    These days, adding support for anything 64-bit is probably more important than keeping support for anything 32-bit.

    Kenneth Barber supported this idea  · 
  19. 2 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  PI Server » Data Archive  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Kenneth Barber commented  · 

    Hi Stephen,

    I am aware that there are tradeoffs, but I also feel that OSIsoft has not found the sweet spot within those tradeoffs.

    On one hand, a compressed archive means that additional work must be done to decompress data being read and compress data being written. On the other hand, compressed data would be faster to read from the disk because there is less data to read. I'm not sure which one has a greater effect on read speed. It probably depends on the chosen compression algorithm.

    I understand the concern with out-of-order data, but I'd like to think that this wouldn't happen often enough for it to be a concern. I did forget to consider the effect on clients trying to read data while a non-primary archive is being written to.

    Backwards compatibility is something that you may need to ditch soon for a different reason. In my previous comment, I linked a suggestion for the use of 64-bit Unix time, which will need to be implemented eventually to make PI usable in 2038 and beyond. If this change requires breaking backwards compatibility, it would be the perfect opportunity to implement other changes to the archive files that would also break backwards compatibility. OSIsoft can always release a utility that converts old archives to the new format.

    For the non-primary archives being compressed, I don't mean zipping or gzipping the whole file. The compression could be local within the file for chunks of time or tags. Something to make non-primary archives much smaller without too much of a penalty on read speed. Disk compression is a good example of this (at least, on small files).

    Also, it doesn't necessarily have to be that all archives except for the primary are compressed. There could be a tuning parameter to control when this compression occurs (e.g. based on the number of archive shifts since the archive was the primary or based on the age of the data that the archive holds). Then you can precisely choose when to take the performance hit while conserving disk space. The older an archive is, the less likely it is to be read from or written to, and the more disk space matters.

    An error occurred while saving the comment
    Kenneth Barber commented  · 
    An error occurred while saving the comment
    Kenneth Barber commented  · 

    When I use disk compression on an archive file, the size of the archive decreases significantly, which shows that the archive files are not well compressed. I find it strange that OSIsoft pushes for the use of exception and compression, which are forms of lossy compression, without worrying about lossless compression first.

    Kenneth Barber shared this idea  · 
  20. 16 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  PI Server » Data Archive  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Kenneth Barber commented  · 
    An error occurred while saving the comment
    Kenneth Barber commented  · 

    This website below counts down the time until the Year 2038 problem:
    https://www.tickcounter.com/countdown/2147483647000/utc/yowdhms/080000E91313E91313FBF0F0/Year_2038_Problem

    As of right now, it is 17.5 years. However, OSIsoft has much less time to fix the issue. As I mentioned, we probably want at least 1 year of leeway. Development might stretch out to, say, 2 years. It might take 5 years before almost all customers are migrated to a version of the PI Data Archive that uses 64-bit time. If we ignore utility companies (which we shouldn't!), most companies probably have future data going at most 1 year into the future.

    This means that OSIsoft should start working on this in late 2028 at the absolute latest, which is only 8 years away, to avoid the Year 2038 problem. Of course, if OSIsoft cares about the 20-year forecasts of companies that do them, they should start working on this as soon as possible.

    Kenneth Barber shared this idea  · 

Feedback and Knowledge Base

Posted ideas will have one of the following statuses.
Full definition of these statuses can be found on the Home Page.
No status
NEEDS MORE DISCUSSION
RESEARCHING/EVALUATING
DECLINED
PLANNED
STARTED/IN DEVELOPMENT
IN BETA/PREVIEW
COMPLETED