This feature request is a follow-up to HVR support ticket 96421.

Prior to the HVR 5.7.0/20 release, Capture would request a table cache refresh from the hub server in a single network call.  As described to me, "something necessitated a change" where these single calls resulted in more frequent network calls.  Thus, when the customer (NXP) upgraded to 5.7.0/20 and ran Scripts & Jobs, this new code significantly degraded Capture performance in NXP's HVR topology (Capture agent in London, UK and hub server in Phoenix, AZ USA).

The resolution/workaround for this was to implement the HVR_SCAN_SUBCYCLE_MAX parameter to allow the table cache to live longer so that there are fewer cache misses and fewer network roundtrips between the Capture agent and the hub.  This approach has proven to be satisfactory...and HVR performance has been restored.

Since increasing the number of network calls was an intentional code change, we asked what the long-term resolution to this issue would be for customers like NXP.  We've been told that this is considered a "flaw" for customers like NXP and without the use of the HVR_SCAN_SUBCYCLE_MAX parameter, the increase in network calls is not going to work.

We've also been told that development is actively looking into this.  This feature request is for that effort to continue and to please keep us posted on the progress of this new design...and when a new release is available with the implementation.

Thanks.