OpenCPN: "Chart cache purge" in logs

[Strolls]

Trying OpenCPN at home on my laptop, I see regular entries of "Chart cache purge" in the logs.

Sometimes these are every few minutes, sometimes twice a minute.

Is it beneficial to increase the size of the cache?

More to the point: is it possible to do so? And, if so, how?

I'm getting this with with OpenGL and without (I'm not sure which works best on my old 2008 Macbook), so I don't think it's the texture cache settings, which are easy to find documented on the web.

Is it possible the cache is filling (and needing purging) more frequently because I'm sitting at home browsing large areas of the Pacific Ocean, with many charts available, something I might not be doing at sea? Or is this just a routine part of OpenCPN operations I should ignore? Generally speaking I expect more cache to mean better performance, so ideally I think this should be tweakable.

Many thanks in advance for any suggestions or advice.

Stroller.

[cagney]

I'm not exactly sure how O works under Mac, but for Linux there is a default setting of max 20 open charts at any given time. Open the 21st and the, the oldest chart in memory gets purged. I think that this is a sensible limit for actual use under way.
This limit can be adjusted. Have a look at The Configuration File | Official OpenCPN Homepage
and the "Open chart limit." Be careful to follow the instructions on how to change the "ini" file.
Please tweak and test, and report your findings.

Thomas

[Strolls]

Many thanks. Macs do indeed have an opencpn.ini.

$ grep -i cache Library/Preferences/opencpn.ini 
$ grep '\[Settings\]' -A 5 Library/Preferences/opencpn.ini 
[Settings]
ConfigVersionString=Version 4.0.0 Build 2015-01-08
NavMessageShown=1
UIStyle=Journeyman
ChartNotRenderScaleFactor=2
ShowStatusBar=1
$

I'll try adding `NCacheLimit=50` in there shortly and see if I notice any difference.

[joel383]

Any luck?


Sent from my iPhone using Cruisers Sailing Forum

[Strolls]

Originally Posted by joel383

Any luck?

Well, hard to say for sure.

Changing to `NCacheLimit=50` doesn't seem to do any harm.

With a higher cache limit, it does seem a bit smoother to me, but the difference is subtle, and I can't say with certainty that it is smoother or just placebo.

I've just experimented with cache limits of 10, 50 and 150, and with a larger chart cache OpenCPN does seem to pan across large areas and zoom into little harbours more smoothly. I think the watch icon appears more frequently with low numbers (10 and 20).

I would say that a cache limit of 50 is probably better than 20. Even with 150, I don't see any significant memory usage or other negative effects, and my Mac is a 2008 model which is getting slow now.

[Strolls]

Update to this: a higher cache number seems to make a large improvement in the right circumstances.

It seems to me that, on my Mac, vector charts display best with OpenGL enabled, whereas raster charts display better with OpenGL disabled.

With OpenGL disabled and a low NCacheLimit, a set of Netherlands vector charts (I think my source was this .7z archive from the Dutch Fairway Information Services) is a challenge - I suffer the waiting icon that looks like a watch. With OpenGL enabled, a higher cache number allows its performance to shine.

With OpenGL enabled raster charts suffer badly - panning and zooming over a wide area of coast causes spinning beachballs and laggy slowdowns.

With OpenGL disabled raster charts (e.g. NOAA east coast USA, NZMariner Tonga and Samoa) are just far more usable - OpenCPN is smooth and natural and behaves far more as one would expect from a modern app. I'm not really seeing any difference by changing the NCacheLimit setting.

This is on a 2008 Macbook (13" unibody) which has 4GB ram, an SSD and a NVIDIA GeForce 9400M GPU (256MB).

So I guess the conclusion I'm seeing is that this setting is of far more importance to those who are using vector charts on the regular.

However, what I'm not seeing is any performance loss, anywhere, by increasing the NCacheLimit. I've had that at 50 in the past, and I've been changing it between 20 and 150 today.

My instinct is that the NCacheLimit default should be higher, to allow users of ENC charts to take advantage of it out the box.

These conclusions are tentative, but I wanted to get them written down. I only noticed this morning what a difference OpenGL makes, and I'm not sure how long I've just spent experimenting with OpenCPN since. It feels like about 3 hours - I'm actually feeling a bit drained and need a cuppa.

It seems to me that a grid comparing raster vs vector vs openGL vs without vs high NCacheLimit vs low must have 8 states - I've been through all of them just now. Where I've said above "x is better than y" - those are statements I'm quite confident in.

However it's hard to quantify how much the performance is affected when you make a change, move the cursor to a different part of the world and have to spend several minutes panning and zooming all over the region.

I hope this helps someone else.

[joel383]

Thanks for putting the effort into the follow up!

[nohal]

Strolls...
OpenGL is generally faster for any use case on hardware reasonably supporting it. For raster charts it makes a huge performance difference once your raster chart texture cache is populated.
It of course may feel slower during the creation of the cache, especially if you are torturing it by switching charts fast, which seems to be exactly what you describe you did, as a lot of CPU intensive calculations are performed and by moving away from the currently processed charts you make them "useless" for the new area you want to see - you can get over it by letting OpenCPN generate the texture cache for all your charts at once before making conclusions.
The settings involved are described in Setting Options | Official OpenCPN Homepage

Pavel

[Strolls]

If I'm understanding you right, that's a bit frustrating to hear.

So I need to have "Texture Compression with Caching" enabled?

It would be nice if that was the default OpenGL mode, then, because I'm fairly sure OpenGL is slower on my machine, for raster charts, without it.

I'll maybe enable that tomorrow and run `-rebuild_gl_raster_cache` before having another go.

[nohal]

Strolls...
You do not *need* anything. You should, and certainly can, understand what is what to get the best performance out of your system.

Pavel

[Strolls]

Well, I understand, after several hours testing, that the default OpenGL performance is poor for raster charts.

You don't seem to be adding much to the thread, if you want to contradict observed results, and then change your tune and say "no, you don't need that".

[nohal]

Strolls...
I really don't know how to explain it better. If your system is capable of using texture caching, it's performance will be by orders of magnitude better using it. Once the cache is populated. It's performance will be as you say "poor" during the population of the cache, as "stuff you do not need at the very moment" will be done.
It is not enabled by default simply because there are systems with broken hardware and drivers that don't play well with it and we try to use the safest possible default settings here.
Whether you have to use some settings on your particular system is your decision which should be based on your personal observations, I can't tell you neither whether you will benefit of it nor whether you need to use it, all I can tell you is how it generally works and where your benchmark results could perhaps be improved by actually using the stuff the way for which it was designed.

Pavel

[Strolls]

I've been using it the way it's designed - that's the defaults.

As far as I can ascertain, the default is that the cache does not get populated.

I do appreciate your concerns about buggy drivers, and obviously it's right that the software is shipped in a configuration that is safe.

But, having conceded that, I've not come across the easy-to-use how to optimise OpenCPN for your hardware guide.

Putting things in the advanced-advanced menu is a message to ordinary users that they shouldn't mess around with it.

Free software doesn't owe me anything, but I'm entitled to be peeved if I spend hours getting to grips with some software only to get snarky advice to the effect of "no, you don't need it, you're just supposed to magically understand the software's internals".

[nohal]

Strolls...
You are not "supposed to magically know" it and we are really trying to document it as best as we can. If it sucks as you suggest, you are free to improve the documentation yourself - it is a wiki everybody can edit.
Sorry for the frustration.

Pavel

[seandepagnier]

Originally Posted by Strolls

I've been using it the way it's designed - that's the defaults.

Strolls,

I implemented the raster texture caching a little over a year ago because raster chart performance was very poor on all hardware, and somewhat unusable on single board arm computers.

Now there are too many options for most users to make sense of, and even more if you edit opencpn.conf and add "OpenGLExpert=1"

Basically there are three possible options:

1) no compression -- maybe fastest for initial results, but uses by far the most memory
2) compression -- maybe slower initial results, uses little graphics memory (you must have expert mode enabled for this option)
3) compression with caching -- maybe even slower initial results, but uses the least memory, and gives good performance once the cache is built. It also uses about as much disk space as the normal chart file.

Theoretically, with option 3, it should first upload the chart without compression to get it working for the user with minimal lag (even loading and uploading the off-screen tiles not yet visible but that will probably be needed soon if we are panning in that direction), then build the cache in a lower priority background thread which is not noticeable to the user. Once complete, the uncompressed video memory could be switched for the compressed version to free up graphics memory. This means that it would basically
give the best performance possible to use the cache in all cases.

There is the complication of supporting option 2 as well in this manner, which is nearly the same, except without caching to disk. The only advantage to option 2, should be that you don't need the disk space.

The original option 1 should only be used by people with buggy drivers.

Finally, we should allow building the cache from external storage, and once generated, the actual chart files would not actually need to be available which means the extra disk storage space is not really needed after all.


Everything I just stated is basically theoretical and the current state of affairs doesn't implement it that way. To get maximum performance at this point in time, you should enable texture caching, and manually rebuild the cache.

So now I must ask you (since I don't use macosx) can you possibly enable expert mode, enable FPS, and give some feedback for non-opengl, and options 1, 2, 3, and also option 3 when you have rebuilt the cache manually? You said non-opengl was fast? Is it actually faster option 3 once the cache is complete? Normally in dc-mode the image quality is bad underzoomed, and in course-up mode is terribly slow.