Tactics Plugin

[rgleason]

Canne, I've been thinking about this problem, how to isolate it.


"..disconnect the computer from the instruments and restart ov50. Sluggish behavior and high CPU load as reported above. I reconnect the instrument USB cable. After a few minutes ov50 catches up and so does Tactics_pi, CPU load goes down to 2 - 4%."


Can you isolate exactly which Tactics instrument/instruments have high CPU use when there is "no data" or "no physical data connection"? Is the corresponding Dashboard Instrument (if it exists) the same?



Then perhaps we have a chance of figuring out where the problem is.


Thanks!

[Canne]

Started from earlier session with Tactics having five windows: Tactics (instruments), Tactics Perf and three history windows. Confirm the high (~30%) CPU load. Closing, in this order: Tactics Polar performance history, Tactics Average Wind, Tactics Wind History. After each closing of the aforementioned history window, closed OV5.0.0+9065270 window which exits gracefully. Restart OV50 with one less history windows now. Confirm the high (~30%) CPU load and sluggish start of OV50. Repeat until all three history windows are closed. Restart OV50. Now the start is normal and the CPU load goes rapidly down to 2-3% for OV50 thread.


Conclusion: any of the history windows of Tactics make the start sluggish in OV5.0.0+9065270 on Win10 if no NMEA data is coming in.


Downgraded appveyor version http://www.cruisersforum.com/forums/...ml#post2883042 with 1.0008 ov50 from http://opencpn.navnux.org/O5Plugins/...ov50-win32.exe and repeated the test. As expected, at startup the behavior is similar with the three history windows opening, but in addition to the CPU load, application is "not responding" according to Win20 Task manager and it takes ages to load the charts (as before). But surprise: I managed to close (armed with patience) Tactics Polar performance history and Tactics Wind History. At this moment, the CPU load went down, <2%! Remains Tactics (instruments), Tactics Perf and Tactics Average Wind history window. With only these three windows, the restart of OV50 is instantaneous, the fastest one with all tests I've done until now. The chart (oeSENC) loads immediately and the CPU load goes down right after.


Some head scratching ahead! (I have no boat and no NMEA others but recordings available this week.)


Canne


BTW: as I've asked before, why not make available for me (and for other interested) the latest ov50 compatible opencpn.lib from windows build as it was provided for earlier versions in this (outdated) page https://opencpn.org/wiki/dokuwiki/do...essed_download ? I don't have time to compile the entirely ov50 just for Tactics_pi, my Linux box being slow as hell. I have contributed a few times to Tactics this way, see the history.

[RonSouthworth]

Hi Rick and Dan thanks for the efforts,

I have tonight loaded (compiled etc) up the latest commit from git on my mac mini.
No performance degradation because of the trending of data on the tactic's plugin thus far. I don't have any barometric NMEA value

Will test the recent commit on my linux box here and see if the CPU load increases ....

I have found that OpenCPN5 is performing very well with a low latency kernel even on my fairly old Linux laptop BTW.

/Ron

[transmitterdan]

Originally Posted by Canne

Started from earlier session with Tactics having five windows: Tactics (instruments), Tactics Perf and three history windows. Confirm the high (~30%) CPU load. Closing, in this order: Tactics Polar performance history, Tactics Average Wind, Tactics Wind History. After each closing of the aforementioned history window, closed OV5.0.0+9065270 window which exits gracefully. Restart OV50 with one less history windows now. Confirm the high (~30%) CPU load and sluggish start of OV50. Repeat until all three history windows are closed. Restart OV50. Now the start is normal and the CPU load goes rapidly down to 2-3% for OV50 thread.


Conclusion: any of the history windows of Tactics make the start sluggish in OV5.0.0+9065270 on Win10 if no NMEA data is coming in.


Downgraded appveyor version http://www.cruisersforum.com/forums/...ml#post2883042 with 1.0008 ov50 from http://opencpn.navnux.org/O5Plugins/...ov50-win32.exe and repeated the test. As expected, at startup the behavior is similar with the three history windows opening, but in addition to the CPU load, application is "not responding" according to Win20 Task manager and it takes ages to load the charts (as before). But surprise: I managed to close (armed with patience) Tactics Polar performance history and Tactics Wind History. At this moment, the CPU load went down, <2%! Remains Tactics (instruments), Tactics Perf and Tactics Average Wind history window. With only these three windows, the restart of OV50 is instantaneous, the fastest one with all tests I've done until now. The chart (oeSENC) loads immediately and the CPU load goes down right after.


Some head scratching ahead! (I have no boat and no NMEA others but recordings available this week.)


Canne


BTW: as I've asked before, why not make available for me (and for other interested) the latest ov50 compatible opencpn.lib from windows build as it was provided for earlier versions in this (outdated) page https://opencpn.org/wiki/dokuwiki/do...essed_download ? I don't have time to compile the entirely ov50 just for Tactics_pi, my Linux box being slow as hell. I have contributed a few times to Tactics this way, see the history.

I can not duplicate any of this behavior, on any machine I have there is not more than 3% CPU usage and there is no growth in memory usage over time. I have tried all 4 of the history gadgets and a variety of other non-history instruments. I have tried with wind barbs, current arrow and lay lines in all combinations. No combination is slow even with a non-optimized debug build of O and Tactics_pi.

The fact that charts are slow points to something else such as slow hard drive or possibly old graphics driver. If it is Win 7 have you let it update with latest OS updates?

[rgleason]

Canne, regarding a version 5.0 opencpn.lib they are always available in appveyor now.
There have been no changes to v5.0 plugin api that I am aware of, so they should all be the same. First go to github opencpn/opencpn. The click on commits. Pick a commit with a green check, you will see .travis and appveyor selections ( continuous-integration/appveyor/pr-) Pick appveyor "Details" Which opens in the Console tab. Now pick the Artifacts tab. There are 3 files, the compile, and opencpn.lib and the wxformbuilder file pbd.


It sounds to me like you have driver/computer issues from TDan and Ron's posts.

Thank you for your testing. Keep us posted on your progress with this please.

[rgleason]

Originally Posted by RonSouthworth

Hi Rick and Dan thanks for the efforts,

I have tonight loaded (compiled etc) up the latest commit from git on my mac mini.
No performance degradation because of the trending of data on the tactic's plugin thus far. I don't have any barometric NMEA value

Will test the recent commit on my linux box here and see if the CPU load increases ....

I have found that OpenCPN5 is performing very well with a low latency kernel even on my fairly old Linux laptop BTW.

/Ron

Ron, there are MAC users who would like to try/use some of these plugins.
Would it be possible for you to get a github account (free to opensource) an use it to fork the plugins and then create "Releases" for Mac that Opencpn Downloads page can link to?


Please see my note to another Mac user here

http://www.cruisersforum.com/forums/...ns-217854.html


Mac Users need to get together on this I think, as the downloads page does not have many v5.0 plugins, and Ptulp is very busy now and can't do it as much.
https://opencpn.org/OpenCPN/info/downloadplugins.html


The OpenCPN programming team is stretched as it is and does not have time for compiling plugins! Plus it takes them away from more important work!

[RonSouthworth]

Hi Rick

Re helping out,

It is on the to do list (to set up a github repository etc).
Packaging for the team is a distraction for certain.

I am more than happy to put 64 bit packages up for others to test / use... Making a version that will run on 32 bit machines will need to be tested.

I will advise when my repository is up and running.


Re tactic's plugin.

Me and serious coding, been in management far too long so I am rusty, re-learning different things that were once on the top of the head.

Something simple, the derived figures on the gauge are represented as prd.SOG:~. The ~ Looks like a minus sign on my screen especially in bright sunlight.

To replace tilde' ~ with approximately equal to ≈ can be expressed in C code as \u2245

e.g.

_T("prd.SOG:~%.1f") _T("prd.SOG:\u2245%.1f")

for bearingcompass.cpp and polarcompass.cpp

The gauge text then is prd.SOG:≈

/Ron

[rgleason]

This is a super big help! Thank you.

I am more than happy to put 64 bit packages up for others to test / use... Making a version that will run on 32 bit machines will need to be tested.

I will advise when my repository is up and running.

When you're ready, I'll send you information to get the plugins listed in the downloads page.


Would it be best to replace with C code as \u2245 ? I have those problems too now.

[RonSouthworth]

Hi Rick

The version of tactic's plugin package for 64 bit macOS is uploaded at https://github.com/scadaperspective/OpenCPN5

It has the previous thread changes mentioned actioned.

Plugins that compile and run ok and don't overtly appear to crash I will package up and put up using the same file format. I have not altered the version number. Let me know if that is preferred or any other changes before the url is linked.


The tilde' is more apparent on my Linux box Font's and sizing are always a balance with cross platform stuff. I think the intent was to have something to indicate the value is a derived "approximation" ? so getting the c code to play nice sounds like a change to commit.

Ship Driver is mostly cosmetic changes. Some very clever code in it.

[rgleason]

Ron, this is just a super huge help. I've made you a "Star" and "Watch" you in my git profile, so I can stay current with your activity.

I have just one suggestion, since Pavel and Git would prefer to keep binaries out of your code section, it is best to use the "Release" Tab to create an actual release and then upload the file to the release. Your release tab for Opencpn5 is here
https://github.com/scadaperspective/OpenCPN5/releases

It is pretty self explanatory, you can title the release and provide a description and even upload the pkg and provide a screenshot if you would like.
Your version numbers may have to have some designation for the plugin itself like "vX.XX.X-wxfax" to avoid duplicates version numbers.

You are doing this from an OpenCPN repository which is a little different than I am used to, since I compile the plugins in their own repository as standalone., but I think what you are doing will work.

I would just suggest moving those binary packages into "Releases" making a separate release for each package and versioning and titling it appropriately.

I am going to send you a private message with my email so that you can give me yours as I want to send some info to you about getting these linked to the opencpn.org downloads page.

This is a great help. MAC Users can rejoice. Thank you.

[Canne]

Originally Posted by rgleason

<snip>It sounds to me like you have driver/computer issues...</snip>

Hi Rick,
That would have been a nice solution but logically the uninstall of O v4.8.0 and installation of v5.0.0 and its plugins would not suddenly cause such a havoc...

Now, when I finally found the standalone linking library (thanks, I would have never found it without your instructions!), I synced my repository and my local copy from upstream with TDans pull request #30 sync.

I quickly spotted the CPU time was spent on each history module's <class> * History * DrawForeground(wxGCDC* dc) - method, in the end where it is supposed to draw a vertical marker every 5 minutes. If one looks the dashboard plugin's wind_history.cpp code in ov50 distribution, that part of it is considerably different. But there is much more.

I will not go into details, but as TDan mentioned, the issue is that the dashboard's code base was copied in Tactics_pi and it is now largely outdated or at least not compatible with ov50. Long story short, I took the pain to ediff every single file in dashboard plugin to port their changes in Tactics_pi equivalent. The performance modules (the core business) I modified using the dashboard plugin's wind_history.cpp as a model.

Needless to say, the so compiled Tactics_pi works like charm for me now with or without NMEA data - record playback, I will check this weekend with instruments (USB and TCP).

You can review the considerable amount of mods I made in this branch - I don't plan to make a pull request unless you and/or tom-r ask me to do so - changes are so numerous that perhaps tom-r prefers to keep his code base clean. Maybe you want to discuss with him. I don't mind to have my own copy. Anyway, more testers would be needed and on other platforms, too. (Did I mention that my Linux box is too old?)

IMO, and after this experience, I would say that it would be totally possible to combine and share 70 - 80% of the code base of dashboard and Tactics_pi plugins. But one needs a dedicated maintainer, and there may be other issues that I am not aware for why the code merge would not be done.

Best regards,

Canne

[rgleason]

Canne,
This is great that you found the problems. We obviously have some programmers/problem solvers here, and I don't consider myself one (pascal years ago).

Do you think it will build and run in Windows? If so, I'll make a branch and try it.

.. quickly spotted the CPU time was spent on each history module's <class> * History * DrawForeground(wxGCDC* dc) - method, in the end where it is supposed to draw a vertical marker every 5 minutes. If one looks the dashboard plugin's wind_history.cpp code in ov50 distribution, that part of it is considerably different. But there is much more.

I would be interested in what TDan thinks about applying these changes and also about merging the plugins. The Dashboard is included with Opencpn, so bdbcat would have to approve too.

I looked at the code changes and it looks like std:isnan and a bunch of other timer changes to me, but I have not looked carefully enough probably. -- You're pretty sure Tactics will run much better?

I belive Thomas the Original programmer will merge anything that works with windows. He is quite responsive.

Thanks!
added star & watch to my repos

[Canne]

Rick,


Thanks to my past Pascal studies, I was able to work in a structured manner and I created this branch https://github.com/canne/tactics_pi/tree/noNMEA , which works fine on Windows, with all Tactics_pi bells and whistles (screenshot).


At this point, one has again the two code bases as close to each other as they can get (don't get fooled by NaN and pen style Replace Alls), I let you decide how to use my porting work (1 full day), if at all; I am happy like this, works for me!

[rgleason]

Canne, I made a new local branch "canne-perf-improvements' and pushed it to my repository. Then made a PR & merged from your branch noNmea. Appveyor is now building it, but the version of appveyor is for ov42 (on my Master branch) so I am not so sure it's going to work. We'll see.


It built for ov42, the appveyor Artifact Tab is here
https://ci.appveyor.com/project/rgle...5934/artifacts


Next to try it with Opencpn v4.8.8

[rgleason]

It works. I think it runs much smoother after the initial loading. O is always under 3.5% after the startup. Nice improvement.

Are you able to meld Tactics and Dashboard? (Don't do it until we get an ok from the main programmers, pavel and dave and Tdan too.)

Why don't you make a PR to Thomas with these improvements?


I wonder if I can make a PR to myself between branches master > ov50, to get the ov50 version running?