Videos comparing speed on a rpi 3b+ with differnt installing routines

[Andreas29]

Hi,

I found the time to make two videos.

When you follw the links you´ll find them.

Video 1 shows panning and zooming on a rpi 3b+ when using a brand new Stretch Image and then install the oc5.0 packets from the repository (the xenial packs).
OpenGL is switched on.
Using hardwareacceleration with fake kms

It looks good and fast enough for using.

Video1:

https://youtu.be/6b8dcUMsa2M

Video 2 shows panning and zooming an a rpi 3b+ when using Jessie updated to Stretch and then updated the old oc 4.8.8 to oc 5.0 when using the packets from the repository (the xenial packs).
OpenGL is switched on.
Using hardwareacceleration with fake kms.

Badly slow!

Video2:

https://youtu.be/Ekr-twRydcA

What happens when using jessie and updating the oc 4.8.8 packets to oc 5.0 using the trusty packs I didn´t test.

As you see in the Video1 oc is now fast enough (or is it possible to get more faster on a rpi?).

In the Moment my rpi2b (with oc 4.8.8) is on the boat. Next time when I go sailing, I´ll bring the rpi3b+ on the boat and test it in the real world (with NMEA, AIS and Radar )

Regards

Andreas

[conachair]

Speed looks not too much different to a Pi3B. Amazing just what a little board costing so little can do, signalk is just great now, if only the big players would add a wifi chip and transmit from their instruments. .

[verkerkbr]

Originally Posted by Andreas29

Hi,

I found the time to make two videos.

When you follw the links you´ll find them.

Video 1 shows panning and zooming on a rpi 3b+ when using a brand new Stretch Image and then install the oc5.0 packets from the repository (the xenial packs).
OpenGL is switched on.
Using hardwareacceleration with fake kms

It looks good and fast enough for using.

Video1:

https://youtu.be/6b8dcUMsa2M

Video 2 shows panning and zooming an a rpi 3b+ when using Jessie updated to Stretch and then updated the old oc 4.8.8 to oc 5.0 when using the packets from the repository (the xenial packs).
OpenGL is switched on.
Using hardwareacceleration with fake kms.

Badly slow!

Video2:

https://youtu.be/Ekr-twRydcA

What happens when using jessie and updating the oc 4.8.8 packets to oc 5.0 using the trusty packs I didn´t test.

As you see in the Video1 oc is now fast enough (or is it possible to get more faster on a rpi?).

In the Moment my rpi2b (with oc 4.8.8) is on the boat. Next time when I go sailing, I´ll bring the rpi3b+ on the boat and test it in the real world (with NMEA, AIS and Radar )

Regards

Andreas

Re:Andreas,


why are you using fake kms ? The full VC4 driver works very well and is very fast with the latest kernel version 4.19.32.


Re: Conachair.



Via SignalK Nmea2K can be converted to NMEA183 for using in OpenCPN.



There a a lot of equipment using only NMEA2K.



The otherway around NMEA183 to NMEA2K is also possible.


Regards,


Bram

[conachair]

Originally Posted by verkerkbr

Re: Conachair.



Via SignalK Nmea2K can be converted to NMEA183 for using in OpenCPN.



There a a lot of equipment using only NMEA2K.

This I know If the main equipment players would join in adding a chip to send sigK over wifi then sensors would just need a bit of power and all the data would be available to the sigK server. So far advanced to NMEA 0183 or N2K. Seems unlikely though..

[Andreas29]

Hi,

Bram I use the fake kms driver cause full kms ends in Problems with the Resolution in vnc.

I use a hdmi connection (to a 13" Monitor at the chart table inside) and I use a VNC connection via wlan (wifi) to a 10" tablet witch I use outside in the cockpit.

I wasn´t able since yet to get a "normal" resolution when using full kms and VNC. Then the res. stays at 640x480 or so on the client.

With fake kms I can choose what ever I whant. I use now 1280x720. With 1920x1080 I got crashes in OC when closing the Radar ppi (but this was under 4.8.8 and with the rpi2b).

So when you have a way for me to use full kms with good resolution when using vnc then let me know

I use the latest kernel too (4.19...).

Regards

Andreas

[BlackSea]

@bram
could you post output of this command?

grep -e "gpu_mem" -e "vc4" /boot/config.txt

[NahanniV]

Originally Posted by BlackSea

@bram
could you post output of this command?

grep -e "gpu_mem" -e "vc4" /boot/config.txt

Here's mine from my Open Plotter install.

pi@openplotter:~ $ grep -e "gpu_mem" -e "vc4" /boot/config.txt
#dtoverlay=vc4-kms-v3d
dtoverlay=vc4-fkms-v3d
gpu_mem=16
pi@openplotter:~ $ grep -e "gpu_mem" -e "vc4" /boot/config.txt

It is working quite well, except for the occasional hang-up after long periods of use (days).
I tested with gpu_mem=256 and gpu_mem=16 and it made no difference.

I think the gpu_mem is only used by the legacy code.
I think the new VC4 driver uses CMA memory.
Open Plotter seems to reserve 256M of CMA memory.
I still seem to run out sometimes and that causes the display to hang:

pi@openplotter:~ $ dmesg
[21965.710804] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[21965.710817] [drm]                            V3D: 176852kb BOs (345)
[21965.710821] [drm]                     V3D shader:    412kb BOs (100)
[21965.710824] [drm]                           dumb:   3088kb BOs (2)
[21965.710833] vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory.
pi@openplotter:~ $

[conachair]

Originally Posted by Andreas29

So when you have a way for me to use full kms with good resolution when using vnc then let me know

I'm using dtoverlay=vc4-kms-v3d with VNC and these settings and it seems fine. RPi3b.

framebuffer_width=1366
framebuffer_height=768

[NahanniV]

Originally Posted by conachair

I'm using dtoverlay=vc4-kms-v3d with VNC and these settings and it seems fine. RPi3b.

framebuffer_width=1366
framebuffer_height=768

With the "real" KMS I was having problems with the monitor not displaying anything.

One case was when the Rpi powers up before the monitor is on, then when the monitor is powered on the display is blank.
VNC into the Rpi and I find the resolution is something the monitor can't display.
That scenario worked fine with the "fake"KMS.

[conachair]

Originally Posted by NahanniV

With the "real" KMS I was having problems with the monitor not displaying anything.

One case was when the Rpi powers up before the monitor is on, then when the monitor is powered on the display is blank.
VNC into the Rpi and I find the resolution is something the monitor can't display.
That scenario worked fine with the "fake"KMS.

Never had that problem, monitor is normally turned off. 1280x720 the vnc screen was very small, didn't trace that to the KMS but could well have been. On a RPi B, not plus - maybe some difference there. No memory probs either , Pi goes for weeks without a reboot. Sorry, can't help any more.

[bdbcat]

Hello...
I would like to see the OpenCPN logfile entries for OpenGL configuration under the two scenarios, fast and slow.
Are the GL configs identical in both cases?


Thanks

Dave

[NahanniV]

Originally Posted by conachair

.....Pi goes for weeks without a reboot. Sorry, can't help any more.

My Rpi with OpenPlotter will also run for days (maybe weeks) it seems to fail after a day or so of active navigation, usually at the point of some user action like panning, zooming, changing from coarse up to North up.....

I don't remember it ever failing just sitting at anchor.

[Andreas29]

Hi,

@conachair: Do you always have a hdmi monitor connected?

I spend hours and nights to search the web.
When using a headless vnc connection it seems that the "full kms" driver have a resolution problem.

The only possibility is this: vncserver -randr=800x600 800x600 is the res. you want.
But this opens a virtual Desktop and slow down the system.

Always when disconnecting the hdmi devices the "full-kms" will have a fault.

An other solution I found was to commend out all hdmi settings in the /boot/config.txt

Meantime (since the last season) normaly I use a hdmi monitor too but I didn´t check it in the Moment if then it´s possible to use "full kms" cause here at home I can´t test it with a hdmi monitor.

The other thing is that I found out that my "slow" pi have a problem with the Hardware- and OpenGL driver.
When running glxgears I get discolored and flickering gears and slower framerates.
It doesen´t matter if switching the OpenGL driver in the raspi-config on or off.
When using the "fast" pi I got the "normal" glxgears when using fake kms. With full kms (and a virtual Desktop) I got the "broken" gears too.

When running glxinfo I got no Errors. All is like ecpected.

@bdbcat:

For the two log files, see attachement. The two OC-Versions are not the same cause I made some additions to my now working "fast" System.
The /boot/config.txt are the same.
The raspi-config preferences are the same.

@NahanniV:

What kernel are you using?

Regards

Andreas

[conachair]

Originally Posted by Andreas29

Hi,

@conachair: Do you always have a hdmi monitor connected?

Yes and no, it's a VGA monitor through an adaptor. Usually turned off but still connected. Power draw on the Pi is less with the monitor turned off. Like 150mA with the monitor off compared to more like 300mA with monitor on, @ 13.7v.

Pi is on 24/7 with a hifiberry amp shield and usually streaming internet radio running all day and signalk recording data to a influxdb database quite often with a GPS usb dongle & ais running, just to see if it breaks. Not much need really in a boatyard And various temperature data & barometer data getting sent from an ESP 8266 as signalk. Opencpn usually not running though sometimes for a few days just to check all is well with the logbook recording etc. I'll do an update & turn on Opencpn now , see what happens. Though even at sea Opencpn on the Pi will be running but not used much, passage planning gets done on a laptop & the navobj files transferred over to the Pi & tablet over wifi. Haven't tried that on V5 yet. So maybe not much help....

[Andreas29]

Hi,

@conachair:

Of course. Your informations help me to understand the differences between your setup and mine

Regards