Have VantageVue fw2.14
Cumulus working through USB Clone Logger via serial.
Already have VP2SleepInterval set to 1500
Was working with low CPU and loop updates around 2.5secs.
Installed and configured VVP Ver1.2.5 on the same Com port that was always used, and configured VVP for Cumulus on IP.
Changed Cumulus from Serial to IP (127.0.0.1 port 5511)
All is working well but Cumulus is now polling VVP at 1 sec intervals shown in the Cumulus status bar and in VVP, and CPU load has increased dramatically.
All my reading and past experience indicates that this should not be happening!
Have restarted Cumulus - no change.
Removed the VPSleepInterval - no change
Changed VPSleepInterval to 0 - system went into overload - VVP activity screen could not keep up with Cumulus requests! Cumulus took ages to shut down!
Changed VPSleepInterval to various values finally settling on 2250 - system now behaving and VVP is reporting loop packets at just over 2 sec intervals and the Cumulus loop requests are now at around 2.5 secs (alternating between 2 and 3 secs in VVP and Cumulus).
So it would appear that since VVP gets the data from the console and stores it in memory, and, with Cumulus getting that data via IP & VVP from memory via IP internal loopback between Cumulus and VVP all in the same PC, there is almost no communication delay. This would explain why a higher VPSleepInterval setting is needed - or else something even more strange is going on!
Also the debug log no longer shows any sensible information about this exchange between Cumulus and VVP. I don't know if this is because it is no longer Serial but IP or if it relates to VVP not returning relevant responses.
Welcome to the Cumulus Support forum.
Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024
Cumulus MX V4 beta test release 4.0.0 (build 4019) - 03 April 2024
Legacy Cumulus 1 release 1.9.4 (build 1099) - 28 November 2014
(a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)
Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki
Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024
Cumulus MX V4 beta test release 4.0.0 (build 4019) - 03 April 2024
Legacy Cumulus 1 release 1.9.4 (build 1099) - 28 November 2014
(a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)
Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki
Cumulus 1069, Davis VVue, VVP 1 sec polling
- steve
- Cumulus Author
- Posts: 26701
- Joined: Mon 02 Jun 2008 6:49 pm
- Weather Station: None
- Operating System: None
- Location: Vienne, France
- Contact:
Re: Cumulus 1069, Davis VVue, VVP 1 sec polling
Yes, that's why VVP users have always needed the sleep interval setting, as otherwise Cumulus is in a tight loop constantly reading and processing data.BCJKiwi wrote:So it would appear that since VVP gets the data from the console and stores it in memory, and, with Cumulus getting that data via IP & VVP from memory via IP internal loopback between Cumulus and VVP all in the same PC, there is almost no communication delay. This would explain why a higher VPSleepInterval setting is needed - or else something even more strange is going on!
I don't understand how you were getting reads at 1 per second with a sleep setting of 1500, because with that value the thread is suspended for 1.5 seconds between reads, and then there's the time taken to process the data. But anyway, if 2250 gives you reasonable results, that's all that matters. The value is configurable so that it can be adjusted to suit each system, after all.
Steve
-
- Posts: 1255
- Joined: Mon 09 Jul 2012 8:40 pm
- Weather Station: Davis VP2 Cabled
- Operating System: Windows 10 Pro
- Location: Auckland, New Zealand
- Contact:
Re: Cumulus 1069, Davis VVue, VVP 1 sec polling
Neither do I which is why I posted - can only assume the processing time is less for some reason - specially as it is via IP rather than serial.steve wrote:I don't understand how you were getting reads at 1 per second with a sleep setting of 1500, because with that value the thread is suspended for 1.5 seconds between reads, and then there's the time taken to process the data. But anyway, if 2250 gives you reasonable results, that's all that matters. The value is configurable so that it can be adjusted to suit each system, after all.