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

[conachair]

Originally Posted by Andreas29

Hi,

@conachair:

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

Regards

Opencpn now running with logbook timer

Rebooted yesterday after some changes loading mpc to play web radio streams without having to run chrome. Works great

[NahanniV]

Originally Posted by Andreas29

Hi,

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

........

@NahanniV:

What kernel are you using?

Regards

Andreas

[/FONT][/FONT]

I have an HDMI monitor permanently attached but mostly turned off (standby ?) 1024 * 768.

The Kernel version is:
4.19.30-v7+
The latest I think.

[verkerkbr]

Originally Posted by NahanniV

I have an HDMI monitor permanently attached but mostly turned off (standby ?) 1024 * 768.

The Kernel version is:
4.19.30-v7+
The latest I think.

I had some problems with a lot of fast keystrokes to reduce or enlarge the screen.

Now with the latest kernel 4.19.32-V7+ it works without any problem.

Ais reception on with the RTL-DSR dongle. GPS mouse. Wifi on via dongle and wifi access point (AP) on. DVI monitor via adapter to HDMI.

VC4 driver full is on. OpenGL in OpenCPN is on. Texture cache switched off.

Regards,


Bram

[conachair]

Originally Posted by NahanniV

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.

Just did an rpi-update >

pi@openplotter:~ $ uname -a
Linux openplotter 4.19.32-v7+ #1210 SMP Tue Apr 2 14:07:04 BST 2019 armv7l GNU/Linux

Opencpn running,I'll do some zooming and panning over vnc once in a while. See if I can break it. Anyone used telegraf to record memory usage to influxdb? It's on there but turned off, I've not really got into it, might find something useful though regarding your crash?

[NahanniV]

Originally Posted by verkerkbr

I had some problems with a lot of fast keystrokes to reduce or enlarge the screen.

Now with the latest kernel 4.19.32-V7+ it works without any problem.

Ais reception on with the RTL-DSR dongle. GPS mouse. Wifi on via dongle and wifi access point (AP) on. DVI monitor via adapter to HDMI.

VC4 driver full is on. OpenGL in OpenCPN is on. Texture cache switched off.

Regards,


Bram

Thanks, I updated mine.

I often use the mouse-wheel to zoom in and out, not really a mouse wheel, but a two finger gesture on a touch pad.

[bdbcat]

Andreas29...
Simple inspection shows that the two versions are not using the same GL drivers. I am not following the various updates made in rPI systems and drivers, but maybe that difference is to be expected?


Fast: Gallium 0.4 on VC4
Slow:Gallium 0.4 on llvmpipe


According to
https://www.mesa3d.org/llvmpipe.html
llvmpipe is a software rasterizer. That would indeed be slow....


Dave

[Andreas29]

Originally Posted by bdbcat

Andreas29...
Simple inspection shows that the two versions are not using the same GL drivers. I am not following the various updates made in rPI systems and drivers, but maybe that difference is to be expected?


Fast: Gallium 0.4 on VC4
Slow:Gallium 0.4 on llvmpipe


According to
https://www.mesa3d.org/llvmpipe.html
llvmpipe is a software rasterizer. That would indeed be slow....


Dave

Hi,

Dave, this explains indeed why the one way ends in a slow pi.
The way to update a Jessie to Stretch and then update a oc 4.8.8 to a oc5.0 Ends (for me) in this slow pi. It doesn´t matter witch option in raspi-config I choose, always the same.
The way to update the Jessie was the "officel" way from the raspi Website. I found out that in some threats in the rpi Forum some guys have the same problem: after updating the jessie they got a broken OpenGL Driver Ends in flickering and discolered gears (when running glxgears) and lower fps rates.

Don´t know why this happens, but I have no problem with it. After using a new fresh Stretch-Image and install oc5.0 from the ppa it runs now fast enough for me and I found it useful. Before my pi2 with jessie and oc 4.8.8 wasn´t faster so now for me all is ok.

After I had a ok-running System now I didn´t spend more time to deeper investigate the differences, sorry.

What I want to show is that it´s possible to run into speed problems when using the "update-way" and how they shows on the screen. And when you have this problem than don´t be panic. Do the work and Setup your pi with a fresh clean Stretch and reinstall OC5.0 and the world is very much better

Regards

Andreas

[verkerkbr]

Originally Posted by NahanniV

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:~ $

Hi JM,


the memory setting made some difference for me. Setting 64 works best. Higher or lower gives no improvement in the performence.


16 seems to be too low.


Regards,




Bram

[conachair]

Going back to the memory thing, telegraf seems to turn itself on after an apt-get upgrade so not sure what this actually means but this is what it's coming back with, looking at mem-used percent. Think those 2 spikes could have been installing signalk updates and restarting signalk. All the time with opencpn running and listening to streaming web radio>

[Andreas29]

Originally Posted by bdbcat

Andreas29...
Simple inspection shows that the two versions are not using the same GL drivers. I am not following the various updates made in rPI systems and drivers, but maybe that difference is to be expected?


Fast: Gallium 0.4 on VC4
Slow:Gallium 0.4 on llvmpipe


According to
https://www.mesa3d.org/llvmpipe.html
llvmpipe is a software rasterizer. That would indeed be slow....


Dave

Hi,

Dave I now investigate what happens. I play my backups on a SD-Card and looked when the driver chanched from the VC4 to the llvmpipe.

I can now say with the update from Jessie to Stretch this results in the "slow" driver. I didn´t recognize this when updated from Jessie to Stretch and using the OC 4.8.8 Version cause the slow down effect isn´t so dramatic as when using OC 5.0

In the next few days I´ll test the "old" Jessie with update the OC 4.8.8 to OC 5.0 when using the trusty ppa.

When you want to change from Jessie to Stretch use a clean fresh Stretch-Image downloaded from the rpi-site.
Updating a Jessie to Stretch (on the recommended -by the rpi foundation- way) Ends in the wrong video driver wich slows down the system.

Bram, I tested the pi here at home on my living-room tv (great experience to watch OC 5.0 on a 55" ). This is a hdmi connection and yes then I can use the full-kms-vc4 driver. But this doesn´t have viewable speed effects.

Regards

Andreas

[Andreas29]

Hi,

just playing around....

The rpi3b+ with the Stretch get from the fresh clean Stretch-Image and fkms-vc4 Driver is on.

When running glxgears I´ll always get framerates synced to the Monitor refresh rate (this I had when using the "old" fast Jessie).

Now I found a tip:

code: vblank_mode=0 glxgears
gives me fps round about 700 fps

So when running "vblank_mode=0 opencpn" from the bash it Looks like OC runs a little bit "smoother".
So I right-click the desktop icon->prefernces (in English I hope it´s right, just the german Version here)->right Folder (.desktop...) and there under command I type: "vblank_mode=0 opencpn".

So when now opening opencpn over the Desktop Icon it runs "smoother" then before.

Regards

Andreas

[Andreas29]

Hi,

and here https://www.raspberrypi.org/forums/v...9ef2e&start=75
at hte end on the last side from this Topic there is a solution for the slow mesa-driver under Stretch.

Regards

Andreas

[NahanniV]

Originally Posted by verkerkbr

Hi JM,


the memory setting made some difference for me. Setting 64 works best. Higher or lower gives no improvement in the performence.


16 seems to be too low.


Regards,




Bram

As far as I understand that setting is not relevant when using the new VC4 driver. It uses CMA (Contiguous Memory Allocation) and in the case of the Kernel in OpenPlotter it is set at 256M when the Kernel is compiled.

I asked Eric Arnholdt how to increase it and he said it would require Kernel re-compile and that it probably would not help.

> Hi Eric,
>
> I am getting an error message from your VC4 code.
> It happens infrequently but approximately once a day if the system is in
> use.
> The distribution is specific for marine navigation: OpenPlotter
> Sailing with free hardware | Sailoog
> The application that I think is causing the problem is a marine charting
> program called OpenCPN.
> It displays a moving map display and other information, sometimes quilting
> together several charts to create the display. There is also rotation for
> course up modes and display of other information such as routes and tracks.
>
> The error that I see is:
>
>> 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:~ $
>
> I am not suggesting that this is an error in your code, I may simply be
> running out of Graphics memory.
> It appears that the memory is already set at 256M.
>
>>
>>> pi@openplotter:~ $ dmesg | grep cma
>>
>> [ 0.000000] cma: Reserved 256 MiB at 0x1ec00000
>>
>> [ 0.000000] Kernel command line: 8250.nr_uarts=0 cma=256M
>>> bcm2708_fb.fbwidth=1024 bcm2708_fb.fbheight=768 bcm2708_fb.fbswap=1
>>> vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 dwc_otg.lpm_enable=0
>>> console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p7 rootfstype=ext4
>>> elevator=deadline fsck.repair=yes rootwait
>>
>> [ 0.000000] Memory: 685600K/970752K available (8192K kernel code, 612K
>>> rwdata, 2148K rodata, 1024K init, 821K bss, 23008K reserved, 262144K
>>> cma-reserved)
>>
>> [ 3.600272] vc_sm_cma: module is from the staging directory, the
>>> quality is unknown, you have been warned.
>>
>> [ 3.602447] bcm2835_vc_sm_cma_probe: Videocore shared memory driver
>>
>> pi@openplotter:~ $
>>
>>
>>
> I see that you have implemented a patch to allow more than 256M, but I'm
> not sure if that is in the Kernel version I am using ( 4.19.30-v7+) ?

It's already in. You can hack your kernel build to increase the value
in the overlay, but honestly if you're running out at 256, another 128
or so (you can't go too high or linux will just fail) likely isn't going
to help you, and you probably need to work on slimming down your
application.

[Andreas29]

Hi,

when using the old "fast" Jessie Version and just update the oc 4.8.8 to the oc 5.0 via the ppa trusty packages it runs like expected fast and well.

Regards

Andreas

[Moo]

Originally Posted by NahanniV

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.

I reported this before, I think.

At anchor or at home or otherwise stationary the Pi runs and runs. On passage I get a crash (or rather a freeze or slow down to the extent that the device is unusable) around 30 hours or so sometimes less.

I deduced that it was down to the memory consumed by the track so in my case circa 150 NM per day.

Anybody else ruled out track length as an issue? It was the only variable for me.