Navico RADAR Plugin Optimization

[seandepagnier]

Originally Posted by NahanniV

Some suggestions:

-First make sure it works with the inbuilt emulator (may not load the system like the real RADAR).

The emulator works

-Use your CubieTruck.

I am not so eager to plug my hardware in other boats now

-Use TcpReplay to replay captured RADAR data;
Either get a pre-captured file or make your own with WireShark.

I will try this.

-Try it with WiFi, apparently some routers will pass the traffic OK.

Maybe can try too.

Hopefully your HDMI monitor wasn't damaged ?

Well luckily is is not my hdmi monitor. Anyway, it appears the monitor is ok, but only tested in vga mode as this guy doesn't use it in hdmi anyway.


Anyway, I fixed the problem with dropouts and put all the heavy lifting in the receiver thread, then switched to vbo model so it should be much faster. I also implemented support without opengl, and was considering using gradual colors rather than fixed ones.

[seandepagnier]

How do I invoke tcpreplay?

I have

sudo tcpreplay -i wlan0 dump.pcapng

I can see the packets in wireshark but nothing in opencpn.

[NahanniV]

Originally Posted by boat_alexandra

How do I invoke tcpreplay?

I have

sudo tcpreplay -i wlan0 dump.pcapng

I can see the packets in wireshark but nothing in opencpn.

I think you have it correct, I'm using:
sudo tcpreplay --loop=0 --intf1=eth0 XXXX.pcapng

Perhaps it's a problem using wlan ?

From: FAQ – Tcpreplay

Can tcpreplay send packets over WiFi?

This turns out to be very OS/hardware dependent, but in many cases, the answer is yes. In order for things to work, you generally must do the following:

Put the WiFi card in managed mode
Your pcap files need to be DLT_EN10MB (Ethernet) and have a valid 803.2 header
The source MAC of the packets need to match the MAC of your WiFi card

[seandepagnier]

Originally Posted by NahanniV

I think you have it correct, I'm using:
sudo tcpreplay --loop=0 --intf1=eth0 XXXX.pcapng

Perhaps it's a problem using wlan ?

From: FAQ – Tcpreplay

Well I have tried with both wlan and lo. I don't physically have an ethernet port. Who designed this radar anyway? It is nearly impossible to configure over a network properly when it is broadcasting udp packets from several ip addresses.

I don't understand why the radar doesn't run a small web server which hosts an image of the radar automatically refreshing. Next, I should connect to the radar using tcp and be able to configure it and receive data this way.

A udp mode could be allowed but it really isn't needed. Maybe it is theoretically better for this but in practice it just isn't easier to use. At least the control socket should be tcp, then it can transmit udp packets for data or something.

[Douwe Fokkema]

The Lowrance 4G radar only has one IP address. When you use a DHCP server it will get an IP address from that server in the assigned range. However for the UDP broadcasts it uses broadcast addresses, each broadcast address is connected to a specific port number. The client (user) can subscribe to one or more of these addresses and listen on the specific ports. I have no opinion if this is a good design, we only have to work with it. Douwe Fokkema

[Douwe Fokkema]

Regarding performance of the radar_pi, this is more complicated than it seems.

To start with, there is the load of OCPN. But all loads are very much system dependent.
Say on a given machine the basic OCPN CPU load is 1 %. Running full refresh speed (30 refresh / second), this will increase to 30%. If load of the radar_pi is 10%, total would be 40%. So we can only influence the last 10% of the 40%.

Real example: Fast I7 Windows 10 machine with Geforce video card.
OCPN CPU load incl. radar_pi (according to Resource Monitor) 15%. Running maximal refresh, actual 30 refresh / second. For the number of refreshes I included a counter.
Then I modified the radar_pi to use OpenGL Vertex Array Buffers, filling the buffer with vertices directly from the receive thread. Result: CPU load and number of refreshes exactly the same.

Then I tried cutting out DrawRadarImage to eliminate all load of the display process.
Result: OCPN CPU load goes up to 24%. Still running 30 refresh cycles / second. So please understand I am puzzled.

Same experiment on small laptop, Intel Atom, integrated Intel video, Win7. Running the version with Vertex Array Buffers.
CPU load 43%, running 10 refresh / second. Good radar image.

Cutting away the DrawRadarImage:
CPU load 34%, running 30 refresh cycles / second. So yes, on small machines the display process might be improved. So may be using VBO will improve things. I tried to implement. But I could not add the glGenBuffersARB call, as the libraries to be loaded are dependent on the manufacturer of the video card. This is not practical for a distributed program. Is there a better solution?

Douwe Fokkema

[NahanniV]

Originally Posted by boat_alexandra

Well I have tried with both wlan and lo. I don't physically have an ethernet port.

"lo." do you mean local ? If so: From the TcpRelay FAQ:

Can I send packets on the same computer running tcpreplay?

Generally speaking no. When tcpreplay sends packets, it injects them between the TCP/IP stack of the system and the device driver of the network card. The result is the TCP/IP stack system running tcpreplay never sees the packets.

Originally Posted by boat_alexandra

Who designed this radar anyway? It is nearly impossible to configure over a network properly when it is broadcasting udp packets from several ip addresses.

I don't understand why the radar doesn't run a small web server which hosts an image of the radar automatically refreshing. Next, I should connect to the radar using tcp and be able to configure it and receive data this way.

A udp mode could be allowed but it really isn't needed. Maybe it is theoretically better for this but in practice it just isn't easier to use. At least the control socket should be tcp, then it can transmit udp packets for data or something.

Frustrating, but no hope of changing it, they will not even consider releasing an interface document.

Cheers,
JM.

[seandepagnier]

Originally Posted by Douwe Fokkema

Regarding performance of the radar_pi, this is more complicated than it seems.

To start with, there is the load of OCPN. But all loads are very much system dependent.
Say on a given machine the basic OCPN CPU load is 1 %. Running full refresh speed (30 refresh / second), this will increase to 30%. If load of the radar_pi is 10%, total would be 40%. So we can only influence the last 10% of the 40%.

With fbo support the load to opencpn should be minimal even at 30 frames a second. Perhaps with additional plugins it could be a problem.

Real example: Fast I7 Windows 10 machine with Geforce video card.
OCPN CPU load incl. radar_pi (according to Resource Monitor) 15%. Running maximal refresh, actual 30 refresh / second. For the number of refreshes I included a counter.
Then I modified the radar_pi to use OpenGL Vertex Array Buffers, filling the buffer with vertices directly from the receive thread. Result: CPU load and number of refreshes exactly the same.

Then I tried cutting out DrawRadarImage to eliminate all load of the display process.
Result: OCPN CPU load goes up to 24%. Still running 30 refresh cycles / second. So please understand I am puzzled.

Same experiment on small laptop, Intel Atom, integrated Intel video, Win7. Running the version with Vertex Array Buffers.
CPU load 43%, running 10 refresh / second. Good radar image.

Cutting away the DrawRadarImage:
CPU load 34%, running 30 refresh cycles / second. So yes, on small machines the display process might be improved. So may be using VBO will improve things. I tried to implement. But I could not add the glGenBuffersARB call, as the libraries to be loaded are dependent on the manufacturer of the video card. This is not practical for a distributed program. Is there a better solution?

Douwe Fokkema

First of all, where is your code? I want to play with it.

Simply glDrawArrays can be used. The idea is the small slower computers have multiple cores, so they can assemble the geometry in ram in a background thread. Even if the cpu percentage isn't reduced, it improves things by freeing up the main thread.

Now, it may be possible to push only the pieces of the vbo that actually updated with incoming scans, and this may or may not be faster depending on implementation and driver.

Finally, I still believe the ultimate solution is to just stick the raw data into a single channel (luminance or alpha) texture and upload it. This is going to be relatively fast. Then render a quad to cover the entire radar area and write a fragment shader to convert the texture coordinates from rectangular to polar. This method also would improve image quality, but would require shader support.

[rgleason]

Sean try

https://github.com/douwefokkema/BR24radar_pi

[merrimac]

I have just pushed Douwe's optimizations to the main branch and released v1.3 based on this.

See the main BR24 thread for the rest of the cool features that are in this release.

[seandepagnier]

I just reduced the cpu usage by a factor of 6 by programming a shader in the gpu so it doesn't need triangles anymore. Now the cpu is 4% refreshing 20 frames a second from the radar.

github.com/seandepagnier/BR24radar_pi -b shader

[merrimac]

Note that those changes make the code use vertex buffers, not shaders. So we're still eagerly awaiting your code, Sean!

[seandepagnier]

I just posted a link to it in the last post. Please give me feedback because I am getting 6% cpu with my shader vs 35% cpu from the vbo work which was already a great improvement from the last release.

Mine builds on the work with vertex buffers and falls back to it if it cannot create the shader (or the user can set that option in the preferences)

[NahanniV]

Originally Posted by boat_alexandra

I just reduced the cpu usage by a factor of 6 by programming a shader in the gpu so it doesn't need triangles anymore. Now the cpu is 4% refreshing 20 frames a second from the radar.

github.com/seandepagnier/BR24radar_pi -b shader

Tried your version on my CubieTruck:

Lots of warnings building, mostly unused and uninitialized variables.

RADAR image is rotated +90deg. (only tested non overlay).

OpenCPN aborts as soon as "Use Shader" option is selected.

Here is DBG and Bactrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xad850270 (LWP 5505)]
memset () at ../ports/sysdeps/arm/memset.S:47
47    ../ports/sysdeps/arm/memset.S: No such file or directory.
(gdb) bt
#0  memset () at ../ports/sysdeps/arm/memset.S:47
#1  0xadc8c066 in memset (__len=512, __ch=0, __dest=<optimized out>)
    at /usr/include/arm-linux-gnueabihf/bits/string3.h:84
#2  br24radar_pi::PrepareRadarImage (this=this@entry=0xad851008, 
    angle=angle@entry=1994)
    at /home/aruntu/seans_radar/BR24radar_pi/src/br24radar_pi.cpp:1968
#3  0xadc964ae in RadarDataReceiveThread::process_buffer (
    this=this@entry=0x59ee90, packet=packet@entry=0xad83ffec, 
    len=<optimized out>)
    at /home/aruntu/seans_radar/BR24radar_pi/src/br24radar_pi.cpp:3565
#4  0xadc98438 in RadarDataReceiveThread::Entry (this=0x59ee90)
    at /home/aruntu/seans_radar/BR24radar_pi/src/br24radar_pi.cpp:3387
#5  0xb6f32d16 in wxThread::CallEntry() ()
   from /usr/lib/arm-linux-gnueabihf/libwx_baseu-3.0.so.0
#6  0xb6f33118 in ?? () from /usr/lib/arm-linux-gnueabihf/libwx_baseu-3.0.so.0
#7  0xb6f33118 in ?? () from /usr/lib/arm-linux-gnueabihf/libwx_baseu-3.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

Cheers,
JM.

[NahanniV]

On further investigation:

The log says "shader not supported"

the crash only happens if the RADAR is sending data when the shader option is checked.

Can this be made to work on the cubietruck ?

Originally Posted by NahanniV

Tried your version on my CubieTruck:

Lots of warnings building, mostly unused and uninitialized variables.

RADAR image is rotated +90deg. (only tested non overlay).

OpenCPN aborts as soon as "Use Shader" option is selected.

Here is DBG and Bactrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xad850270 (LWP 5505)]
memset () at ../ports/sysdeps/arm/memset.S:47
47    ../ports/sysdeps/arm/memset.S: No such file or directory.
(gdb) bt
#0  memset () at ../ports/sysdeps/arm/memset.S:47
#1  0xadc8c066 in memset (__len=512, __ch=0, __dest=<optimized out>)
    at /usr/include/arm-linux-gnueabihf/bits/string3.h:84
#2  br24radar_pi::PrepareRadarImage (this=this@entry=0xad851008, 
    angle=angle@entry=1994)
    at /home/aruntu/seans_radar/BR24radar_pi/src/br24radar_pi.cpp:1968
#3  0xadc964ae in RadarDataReceiveThread::process_buffer (
    this=this@entry=0x59ee90, packet=packet@entry=0xad83ffec, 
    len=<optimized out>)
    at /home/aruntu/seans_radar/BR24radar_pi/src/br24radar_pi.cpp:3565
#4  0xadc98438 in RadarDataReceiveThread::Entry (this=0x59ee90)
    at /home/aruntu/seans_radar/BR24radar_pi/src/br24radar_pi.cpp:3387
#5  0xb6f32d16 in wxThread::CallEntry() ()
   from /usr/lib/arm-linux-gnueabihf/libwx_baseu-3.0.so.0
#6  0xb6f33118 in ?? () from /usr/lib/arm-linux-gnueabihf/libwx_baseu-3.0.so.0
#7  0xb6f33118 in ?? () from /usr/lib/arm-linux-gnueabihf/libwx_baseu-3.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

Cheers,
JM.