give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: h1. Executive Summary    Periodically collect "validator info" from each node in a pool and persist it for use by analysis and/or monitoring tools. Data can be immediately fed to or read by monitoring/analysis tools. When faults/failures are experienced, the data will aide in root cause analysis.    The process/tool that performs this operation must be run by a Steward. No other entity is currently (as of July 25, 2018) privileged to obtain validator info. Therefore, tools and processes that access this data must enforce this data sharing authorization requirement for stored validator info. In other words, do NOT re-share data in raw or altered form with anyone else.    It is difficult to know where to start a root cause analysis on large pools (25+ nodes) under heavy load (??? - [~<USER> - what is considered heavy load?) and/or over long periods of time. Tools built on top of this persistent store of data will aide in identifying one or more starting points.    If use of the tool on the STN or Live pool are a concern, the tool will still add value to development and QA teams. QA teams are likely the only group to have resources sufficient to create large, highly transacted systems, but developers will hopefully find value and experience with the tool(s) in their own development environments.  h1. Considerations  h2. Data - Validator Info    Only Stewards are privileged to get validator info. Therefore the tool(s) are not intended for use by any other entity.    (possible future enhancement) [~<USER> offered the following suggestion (not verbatim) that may make validator info interesting/useful to other entities while allowing Stewards to control who sees what data:    Stewards collectively decide (TGB) what baseline validator info will be shared, but ultimately decide what, if any, additional information will be shared with whom.    Use the config ledger to define the baseline, pool-wide set of data/attributes validator-info (script) or indy-cli's `ledger get-validator-info` returns. Perhaps the set of baseline data should be configurable based on who is making the request, such as the public (no nym), Trustees, and Stewards, producing public, protected, and private views.    Enhance Indy Node configuration (i.e. /etc/indy/indy_config.py) to allow each Steward to include additional information beyond the baseline defined in the config ledger. If it is decided that a different set of data will be returned base on who is requesting it, this configuration option could allow Stewards to share data beyond the baseline up to the superset of validator info based on who is requesting the data.  h2. Storage    <USER>suggested the use of a time series database (optimized for time series data) for storage and querying of data. Where the database is hosted is determined by the Steward collecting the data.  h2. Analysis    Validator info contains both "Node_info" and "Pool_info". Node_info will give the tools useful information about each node's internal indy-node process and ledger state such as catchup, replica, and view change status, config, domain, and pool ledger size, and performance metrics. The Pool_info provides useful information about each node's view of the pool such as, blacklisted nodes, quorums, reachable, unreachable, and suspicious nodes, and f value.
Answer: 636159.0