OpenCPN Beta test 4.1.1108 Release

[Gilletarom]

dave,

Originally Posted by bdbcat

Gilletarom...
...
The font size of the AIS Target List is controlled by text element "Dialog", in the Settings->User Interface panel.
...
Dave

Ok, it run.

There is 3 lines :
- Dialog,
- Dialogue,
- Boite de dialogue.

What difference betwen these 3 lines ?

[wdkester]

I haven't exported WP from this machine for a while; but when I tried I get a hang. Reinstall with same settings and I still get a hang trying to export 1 WP.

Does anybody have an idea before I do a clean install?

[Hakan]

David
Win10, VS2013 built, recent Git fetch.
I exported one WP to desktop wo problem, or was your goal to export to GPS or similar?
Håkan

[bdbcat]

Gilletarom...

re:
There is 3 lines :
- Dialog,
- Dialogue,
- Boite de dialogue.

What difference betwen these 3 lines ?

There should be only one line, in your language. This error was introduced in a recent change. I will correct it.

@jongough...
I think this is why we need "Scrubbing" of the fonts.
see discussion.
https://github.com/jongough/OpenCPN/commit/862d81ba896c1a9cd47352612762b377e5323ab0


Meanwhile, select "Dialogue", for French. I think. If no work, try the other French entry.

Sorry for the fault.
Dave

[bdbcat]

@Sean...

re AIS COG line:
"Thanks for now, but eventually we should rework it to make the improved display efficient. "

I tried a bunch of different combinations, across all my available platforms. Different GL implementations do different things with single pixel lines. After all, the DC draw looks best, and I think it is worth the cycles to make it look nice. The table lookup on the circle draw and spherical coordinate math probably give us the most time saving, anyhow.

Thanks
Dave

[jongough]

I think the link should have been:
https://github.com/OpenCPN/OpenCPN/pull/469

This is where the discussion happened.

It looks like there may be an issue with fonts and different languages. There seems to be American English (Dialog), European English (Dialogue). The static list in FontMgr uses _T("Dialog") for its entries, but in the rest of the code _("Dialog") is used. Is this going to cause issues with different languages?

The third entry is for "Dialog Box" (American spelling) which is not in the static list of fonts. So, something must be using this and requesting FontMgr for a suitable font. As we have only just introduced the PlugIn API call to use this facility it looks like something in the mainline is asking for it. I just cannot find it at the moment. Or, perhaps, there is an issue with the 'translations' that is introducing this this.

I think this needs investigation to fix the issue rather than re-introduce the 'sledgehammer' to keep the list clean.

Jon

Originally Posted by bdbcat

Gilletarom...

re:
There is 3 lines :
- Dialog,
- Dialogue,
- Boite de dialogue.

What difference betwen these 3 lines ?

There should be only one line, in your language. This error was introduced in a recent change. I will correct it.

@jongough...
I think this is why we need "Scrubbing" of the fonts.
see discussion.
https://github.com/jongough/OpenCPN/commit/862d81ba896c1a9cd47352612762b377e5323ab0


Meanwhile, select "Dialogue", for French. I think. If no work, try the other French entry.

Sorry for the fault.
Dave

[transmitterdan]

Originally Posted by CarCode

You should be able to check the max limit of AIS messages when calculating the baudrate 38400 for AIS and the max possible AIS message length.

I am not sure what the "max possible message length" would turn out to be but in the big test file the "average message length" is 52 characters. So assuming a 38400 baud connection can send 3840 characters per second that comes out to about 70-75 AIS messages per second. We have been running a lot faster than that (more than 10X) over Ethernet to stress the AIS system.

Using Dave's optimization the performance is acceptable at up to 100 records per second which is about 50kbps. That's more than a 38400 serial port can produce. Based on testing today the latest git results in reasonable performance on Win 10 with slow AMD A8. It maxes out the main core which suggests a thread would help. So the system can comfortably handle as much data as a 38400 baud device can generate. To handle high number of records per second via Ethernet will require a faster CPU and/or more optimization.

[LeaseOnLife]

Originally Posted by transmitterdan

...

Using Dave's optimization the performance is acceptable at up to 100 records per second which is about 50kbps. That's more than a 38400 serial port can produce. Based on testing today the latest git results in reasonable performance on Win 10 with slow AMD A8. It maxes out the main core which suggests a thread would help. So the system can comfortably handle as much data as a 38400 baud device can generate. To handle high number of records per second via Ethernet will require a faster CPU and/or more optimization.

Something is still wrong here, with/including the latest from Dave. To me, there is no reason the CPU load keeps climbing while the AIS targets increase only slightly. Something is still happening with time. I have AIS target tracks turned off, so that shouldn't be it. See attached graph.

PS: For the guys replaying the big file, I think any of the replay methods (VDR / python) are too slow. To double check, the file was recorded over 30 min, how long does it need to play?


Dirk

[transmitterdan]

Dirk,

The "big" file isn't realistic, It has AIS targets from all over the world. No single AIS receiver could ever generate that many messages that fast. So don't get hung up on the play speed.

Try changing the timeout settings under options->ships->AIS. I think they default to 8 and 10 minutes. Set the longer one to 90 minutes. Does your CPU still slow down after 10 minutes?

Try not to play the file too fast. If you overload the message parser then it isn't a realistic test. In my testing if you see 20K targets you are playing the file too fast. About 18K max targets is what I get when playing at 100 messages per second (50 kilobits per second).

[LeaseOnLife]

Dan

I am using the live stream, not the VDR file, my mentioning of the VDR file was for others, using the VDR file. I tried the VDR file, and it plays way too slow.

Sure, any stress test can be called unrealistic. And yes, I will try to lower the timeouts (currently 8/10) min, but please, explain, why the CPU load is ever increasing while the amount of targets doesn't change much after ~10min.

Dirk

[transmitterdan]

Dirk,

Hard to speculate on what is slowing down your machine over time. Mine does not do that. Maybe the experiment with timeout values will give a hint.

OpenCPN's speed of processing AIS messages cannot handle a data rate of megabytes per second. I think it can handle about 100 kilobits per second on slower machines. So don't expect O to be a tool for observing every AIS target in the world in real time. That's not what it was designed to do.

[LeaseOnLife]

Originally Posted by transmitterdan

Dirk,

Hard to speculate on what is slowing down your machine over time. Mine does not do that. Maybe the experiment with timeout values will give a hint.

OK, so I adjusted the AIS timeouts to 2 and 4 min. With that, my live stream is showing 20k targets +/- 500. CPU kept climbing from 30 to 60% over an hour, the increase has tapered off, but is still climbing, ever so slowly at 0.1% per minute now. I will keep it running and will observe. If there is no CPU "leak" I would expect the CPU load stabilize, which I haven't seen yet.

Thanks!

Dirk

[bdbcat]

Dirk...

A replay test with thousands of targets is not a simulation of real life, though still a good stress test.

During a VDR playback, what is happening is this:

1. Hundreds of targets are captured within a one second interval. Note that these targets all have the exact same acquisition timestamp, +/- 1 second.

2. The OCPN logic will remove a target when it has not been heard from in 3 times the "Target Remove" figure specified in Settings. We use this hysterysis to avoid discarding a target on temporary loss of signal.

3. In the playback scenario, many targets are heard only once.

4. So, in the event, many hundreds of targets are discarded each second, starting after the 3X time interval expires. This is relatively expensive, and could be optimized. But really, there is no point....

This scenario would not very likely happen in real life. That is, hundreds of targets coming online at the same second, and then never being heard from again.

This is why you see CPU activity persisting until all the targets have be deleted, even after the playback stops.

Hope this helps
Dave

[rgleason]

Compiled master 118ab6d Merge pull request #484 from seandepagnier/grib_concatenation

Tried running Python VDRserver with VDR-AIS file at 0.0003 speed.
c:\python27\python c:\python27\VDRServer1.py C:\Data-Dart\Nmea\vdr-ais-cpuload-reaching-100percent.log 192.168.1.255 10110 0.0003 UDP

It seemed pretty stable and used about 10% to 15% cpu for 21000 targets.

The double Options Icon does occur as reported earlier.

Sean how should I test grib concatination? --Thanks!

[LeaseOnLife]

Originally Posted by bdbcat

Dirk...

A replay test with thousands of targets is not a simulation of real life, though still a good stress test.

...snip...

Hope this helps
Dave

Yes it does! I am running with AIS timeouts 1min / 3 min now and seem stable now. Sean's optimization help to keep O responding nicely with 20k targets.

This gives me a chance to test other AIS functions:

• I like rooiedirk's AIS target prioritization, but this needs some finetuning. Heavy traffic areas like Singapore help to point out real life situations
• the xx NM limit (in the target list) doesn't seem to work right, needs more testing, expect more next days.
• etc..

Thanks!

Dirk