Navico RADAR Plugin Optimization

[NahanniV]

Tried shader version on a laptop with linux:

-In RADAR only mode it just rendered a red circle with radius = range ?

-It worked in RADAR overlay mode!

-CPU usage was dramatically decreased !!!

-Transparency setting is backwards to the non shader setting.

-When you change the transparency some spokes stay at the old level till eventually they are re-drawn at the new transparency level.

-Turning on the Multi Sweep Filter blanks the RADAR display.

-Multi-color display setting displays Monocolor.

Great Job.

JM.

[seandepagnier]

In the end someone gave me a usb->ethernet adaptor

Originally Posted by 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 ?

I think we need to make glshim use openglesv2 instead of v1. This should allow us to use the FBO (I believe it's not working right?) and also possibly shaders but I'm not entirely sure without trying it. This is not so simple as just changing the number though.

In any case, I did make it stop crashing.

Originally Posted by NahanniV

Tried shader version on a laptop with linux:

-In RADAR only mode it just rendered a red circle with radius = range ?

Ok, I fixed for now, but there are two ways to do it so...

-It worked in RADAR overlay mode!

-CPU usage was dramatically decreased !!!

It also should be decreased from before without using the shader if you uncheck the box, but much more so with the shader. The shader also looks slightly nicer.

-Transparency setting is backwards to the non shader setting.

Ok, I was at the default 50% transparency so didn't notice. Fixed now.

-When you change the transparency some spokes stay at the old level till eventually they are re-drawn at the new transparency level.

Is this bad? It was also already a problem when zooming with the same effect. It would be easy to make it work either way.

-Turning on the Multi Sweep Filter blanks the RADAR display.

How do you turn it on? I can't find this... Does it break without the shader too?

-Multi-color display setting displays Monocolor.

I didn't implement multicolor because it requires pushing 4x the data to the gpu which would be slower although still much faster than using triangles. So to implement multicolor, I think an additional shader program should be added to support a 4 channel texture, while keeping the current logic for single color for minimum cpu. This would be trivial to do.

Great Job.

JM.

Future features:

Is there a reason why we don't render the trails like in other radars?

Also, for smaller resolution displays we could probably automatically downsample the 2048x512 input to 1024x256 or less whenever the difference is impossible to notice. This would reduce memory and cpu requirements if implemented correctly.

Forwarding the other data to other computers.

Rendering the guard zones using the shader (should be really easy and faster too)

My issues:
I cannot receive data from the radar unless I assign an IP address to the eth0... ok. But for some reason I don't understand, I must run wireshark and capture on eth0 or else no data is received. It must get packets from 236.6.7.8 which is not on the same subnet so I think this may be the reason. This is a very annoying thing to have.

To send data to the radar I must also set my gateway to the ip of the radar or the "sendto" call for the udp packet fails.

Once I got it working I didn't play with it much, but if there is a better way to configure it, and a way to not use wireshark I would like to know about it. Maybe we should add support to set the device into promiscuous mode on linux?

I never got data replay to work. This is even with the ethernet adaptor etc. The boat I was testing on has left, so I cannot really continue development unless I get data replay working, but I am hoping my work now is simple enough to be continued by others.

[muttnik]

Originally Posted by boat_alexandra

My issues:
I cannot receive data from the radar unless I assign an IP address to the eth0... ok. But for some reason I don't understand, I must run wireshark and capture on eth0 or else no data is received. It must get packets from 236.6.7.8 which is not on the same subnet so I think this may be the reason. This is a very annoying thing to have.

To send data to the radar I must also set my gateway to the ip of the radar or the "sendto" call for the udp packet fails.

Quick reply as I need to dash out...

236.6.7.8 is a multicast address, so "subnet" isn't relevant (if the radar is physically on the same link). To receive multicast you need to tell your network card to receive packets for that group. From the sound of it eth0 is not your computer's default gateway (presumably because it's an add-on usb adapter). This explains both of the above issues. If the code (which I haven't looked at for a year) simply adds that multicast group to the default multicast interface rather than offering the user a choice and that interface isn't eth0, the only time you'll see those packets there is when you put the interface into promiscuous mode. Likewise multicast you send out won't be going out through that interface.

Short term fix would be to set a route for all multicast traffic out of eth0 before you start (I think). Longer term might be to give the user the option of specifying the interface to use

[muttnik]

[Returns after having missed a literal rather than metaphorical boat]

I'm guessing that boat_alexandra's setting of routing was done *after* starting the plugin which got outbound multicast going out the right interface, but the IP_ADD_MEMBERSHIP setsockopt() had already been done on the previous default interface.

So to slightly expand the options...

In an ideal world you could give the user the option of specifying a "radar interface", explicitly join the radar's multicast group on that interface and set the interface for outgoing multicast packets using IP_MULTICAST_IF (which I just checked is supported on windows as well as OSX and Linux (that latter two being more within the realms of what I know :-)).

However I don't think it's that bad to ignore this. I strongly suspect that a very large number of applications using multicast have the same issue and overlook it because it's not a problem for the common case and can be fixed with routing in the edge cases. on Linux:
ip route add 224.0.0.0/4 dev eth0
(before starting OpenCPN...)

To answer an earlier question, do I think this multicast radar malarkey is a good design? Yes. For ethernet which garmin/navico/raymarine designed it to run on. Unfortunately it's generally unworkable over wireless.

[merrimac]

I created a branch 'shader' using Sean's work, and made it compile on my Windows and OSX build machines as well.


Sean, my branch is currently fully merged with all work from Douwe, so you may want to merge back up. I just merged all your work up to commit 71a79f57f40b660ef3907021e05a2be026e10709, so your latest as of now.

[merrimac]

@muttnik,

Have you checked how the plugin handles (multiple) ethernet devices? It keeps joining multicast networks using each card in turn until it receives data from a radar, then 'sticks' to that network for the duration of the session. This has been done in a way that works on all three platforms. That isn't easy as all platforms have different ways of specifying which device/IP you want to multicast on.

I can see how this code might have an issue with a fake radar as it picks up data from 236.6.7.9 (or 236.6.7.15 for radar B) so make sure those are in your tcpdump replay file.

[merrimac]

Originally Posted by boat_alexandra

I didn't implement multicolor because it requires pushing 4x the data to the gpu which would be slower although still much faster than using triangles. So to implement multicolor, I think an additional shader program should be added to support a 4 channel texture, while keeping the current logic for single color for minimum cpu. This would be trivial to do.

The value of the radar display showing multiple colors is really much higher in situations where you actually need the radar, like bad weather in complicated situations.

Originally Posted by boat_alexandra

Is there a reason why we don't render the trails like in other radars?

You mean, as in real radars? Or have you seen other open source that does this?

This would be a good feature to add.

Originally Posted by boat_alexandra

Also, for smaller resolution displays we could probably automatically downsample the 2048x512 input to 1024x256 or less whenever the difference is impossible to notice. This would reduce memory and cpu requirements if implemented correctly.

But also increase complexity (again) and if CPU usage is already low then why bother? Also, screen resolution is generally going up, especially on phones and tablets!

Originally Posted by boat_alexandra

Forwarding the other data to other computers.

Great principle, but what is the use case? Why would I want to share radar data off the boat?

Originally Posted by boat_alexandra

Rendering the guard zones using the shader (should be really easy and faster too)

Shaders are really not my cup of tea, would be nice if you could help us out.

Originally Posted by boat_alexandra

I cannot receive data from the radar unless I assign an IP address to the eth0... ok. But for some reason I don't understand, I must run wireshark and capture on eth0 or else no data is received. It must get packets from 236.6.7.8 which is not on the same subnet so I think this may be the reason. This is a very annoying thing to have.

To send data to the radar I must also set my gateway to the ip of the radar or the "sendto" call for the udp packet fails.

I guess this is a restriction of Linux wrt how multicast is implemented. On Windows you can just use 0.0.0.0 and it will ask all ethernet cards to listen for the multicasts.

[muttnik]

Originally Posted by merrimac

@muttnik,

Have you checked how the plugin handles (multiple) ethernet devices?

I confess no. I have a very old copy of the br24 code but my response was based on a possible cause for the symptoms without having seen the up to date code (sorry). I'm on a GSM link but will endeavour to update my sources when I can.

Originally Posted by merrimac

I guess this is a restriction of Linux wrt how multicast is implemented. On Windows you can just use 0.0.0.0 and it will ask all ethernet cards to listen for the multicasts.

All *nixy platforms that I'm familiar with (my Windows-specific knowledge is limited) will use the interface which multicast is routed out of (only) for IP_ADD_MEMBERSHIP unless another interface is explicitly specified.

[NahanniV]

Originally Posted by boat_alexandra

...
I think we need to make glshim use openglesv2 instead of v1. This should allow us to use the FBO (I believe it's not working right?) and also possibly shaders but I'm not entirely sure without trying it. This is not so simple as just changing the number though.

The systems using GLSHIM are the ones that need this the most, like cubietruck or RPi2.

Originally Posted by boat_alexandra

....
How do you turn it on? I can't find this... Does it break without the shader too?

It's under Gain, also broken without shader.

Originally Posted by boat_alexandra

....
I didn't implement multicolor because it requires pushing 4x the data to the gpu which would be slower although still much faster than using triangles. So to implement multicolor, I think an additional shader program should be added to support a 4 channel texture, while keeping the current logic for single color for minimum cpu. This would be trivial to do.

Trivial for you perhaps

Originally Posted by boat_alexandra

....
Forwarding the other data to other computers.

This has been discussed before, the broadcast UDP is a problem for wireless networks, so some kind of server would be great. UDPXY is an example of a server made to get around this problem.

Originally Posted by boat_alexandra

....
Rendering the guard zones using the shader (should be really easy and faster too)

I did not test them, they need to work in all modes.

Originally Posted by boat_alexandra

....
My issues:
I cannot receive data from the radar unless I assign an IP address to the eth0... ok. But for some reason I don't understand, I must run wireshark and capture on eth0 or else no data is received. It must get packets from 236.6.7.8 which is not on the same subnet so I think this may be the reason. This is a very annoying thing to have.

To send data to the radar I must also set my gateway to the ip of the radar or the "sendto" call for the udp packet fails.

Once I got it working I didn't play with it much, but if there is a better way to configure it, and a way to not use wireshark I would like to know about it. Maybe we should add support to set the device into promiscuous mode on linux?

I never got data replay to work. This is even with the ethernet adaptor etc.

The problem may be due to your USB adapter. Not sure if this is relevant or not, but I use a GUI in Ubuntu to configure the network and under IPv4 Settings there is a setting called "Method" that I have to set to "Link-Local Only" if I am not using a router.

Originally Posted by boat_alexandra

....
The boat I was testing on has left, so I cannot really continue development unless I get data replay working, but I am hoping my work now is simple enough to be continued by others.

Hopefully someone will pick this up, but whatever you can do now while it is fresh in your mind is greatly appreciated.

Cheers,
JM.

[rgleason]

Why not donate to Sean so perhaps he can get a b&g radar?
- Maybe he doesn't want one due to power requirements, but he certainly has helped the development here...

[NahanniV]

Originally Posted by rgleason

Why not donate to Sean so perhaps he can get a b&g radar?
- Maybe he doesn't want one due to power requirements, but he certainly has helped the development here...

Don't forget that many very competent programmers have made this possible.

Sean's profile on sourceforge is an interesting read, and makes it very easy for anyone to encourage his efforts with monetary or equipment donations (there is a wishlist).

LINK TO SEAN'S PROFILE-> About

Cheers,
JM.

[seandepagnier]

Originally Posted by merrimac

I created a branch 'shader' using Sean's work, and made it compile on my Windows and OSX build machines as well.

Sean, my branch is currently fully merged with all work from Douwe, so you may want to merge back up. I just merged all your work up to commit 71a79f57f40b660ef3907021e05a2be026e10709, so your latest as of now.

Great I have merged now. Thank you for make it work on the other OS. I put in my branch support now for colors in the shader, so the shader support should be complete now.

My commit to change the refresh type from true to false makes a huge difference in cpu usage when overlaying on vector charts with a fast radar refresh rate. This works both with and without the shader (needs FBO support though) I think it's worth re-making the release to include these changes.

Originally Posted by muttnik

[Returns after having missed a literal rather than metaphorical boat]

I'm guessing that boat_alexandra's setting of routing was done *after* starting the plugin which got outbound multicast going out the right interface, but the IP_ADD_MEMBERSHIP setsockopt() had already been done on the previous default interface.

No. I can run "sudo route add default gw 169.254.109.59" which is the ip of the radar just once, and restart opencpn many times

So to slightly expand the options...

In an ideal world you could give the user the option of specifying a "radar interface", explicitly join the radar's multicast group on that interface and set the interface for outgoing multicast packets using IP_MULTICAST_IF (which I just checked is supported on windows as well as OSX and Linux (that latter two being more within the realms of what I know :-)).

Some sort of debugging here would be nice, but yes, perhaps the interface could be specified, or it could detect the interface based on incoming packets.

However I don't think it's that bad to ignore this. I strongly suspect that a very large number of applications using multicast have the same issue and overlook it because it's not a problem for the common case and can be fixed with routing in the edge cases. on Linux:
ip route add 224.0.0.0/4 dev eth0
(before starting OpenCPN...)

Although it is very confusing for a lot of users...

To answer an earlier question, do I think this multicast radar malarkey is a good design? Yes. For ethernet which garmin/navico/raymarine designed it to run on. Unfortunately it's generally unworkable over wireless.

If it's generally unworkable over wireless then it is not a good design.

Originally Posted by muttnik

Quick reply as I need to dash out...

236.6.7.8 is a multicast address, so "subnet" isn't relevant (if the radar is physically on the same link). To receive multicast you need to tell your network card to receive packets for that group. From the sound of it eth0 is not your computer's default gateway (presumably because it's an add-on usb adapter). This explains both of the above issues. If the code (which I haven't looked at for a year) simply adds that multicast group to the default multicast interface rather than offering the user a choice and that interface isn't eth0, the only time you'll see those packets there is when you put the interface into promiscuous mode. Likewise multicast you send out won't be going out through that interface.

Short term fix would be to set a route for all multicast traffic out of eth0 before you start (I think). Longer term might be to give the user the option of specifying the interface to use

So it is possible then to fix this in code? Set each device to promiscuous mode in turn and find the one connected to the radar?

I don't think I will be the last user to have this problem.

Originally Posted by NahanniV

The systems using GLSHIM are the ones that need this the most, like cubietruck or RPi2.

Yes, I agree. I plan to get to this soon.

It's under Gain, also broken without shader.

Should be fixed now.

This has been discussed before, the broadcast UDP is a problem for wireless networks, so some kind of server would be great. UDPXY is an example of a server made to get around this problem.


I did not test them, they need to work in all modes.



The problem may be due to your USB adapter. Not sure if this is relevant or not, but I use a GUI in Ubuntu to configure the network and under IPv4 Settings there is a setting called "Method" that I have to set to "Link-Local Only" if I am not using a router.

I did that, and still had to use wireshark to set promiscuous mode and also manually specify a gateway through it.

Hopefully someone will pick this up, but whatever you can do now while it is fresh in your mind is greatly appreciated.

Cheers,
JM.

I have implemented color support, please verify because I no longer have a radar to play with.

[seandepagnier]

Originally Posted by rgleason

Why not donate to Sean so perhaps he can get a b&g radar?
- Maybe he doesn't want one due to power requirements, but he certainly has helped the development here...

I don't think it's a power problem, but for me I don't really need this equipment. I am working on the development here because I know some people who use it, and I found a way to make it much more efficient. I think I am more or less finished already.

[merrimac]

A good way to try this kind of stuff out is to install a virtual machine and run the tcp replay in that, onto the "host only" network that the VM software usually generates. This way you only need software, not hardware.

If you run Linux, try KVM or VirtualBox. KVM is great if you like fiddling, VBox is the easy option.

[muttnik]

Originally Posted by boat_alexandra

If it's generally unworkable over wireless then it is not a good design.

It's a good design *for the purposes for which navico/garmin designed it*, i.e. operating over 100baseTX. It's good design if we lived in an ideal world where we could divorce ourselves from the mucky pragmatics of the link layer. You are spot on though that it's not such a good plan given the practicalities of 802.11 with commodity hardware.

Originally Posted by boat_alexandra

So it is possible then to fix this in code? Set each device to promiscuous mode in turn and find the one connected to the radar?

merrimac was saying that something like this is done though it'll be adding group membership to each interface in turn rather than setting promiscuous mode (which would require root). I should probably shut up until I've downloaded the latest code :-)