Raspberry Pi node red flow editor very slow when using Modbus

[danieljame...@gmail.com]

Hello.

I have dropped this issue in the node red group with no resolution.
Hoping someone has had the same issue and can maybe help?

I have a RPI 3 freshly setup with all the most recent updates.
Installed most recent Node red. nodejs and Npm/

On the Node red platform im polling 24 modbus addresses from a power meter.
Potentially i would like to poll 4 x the 24 values, this would be 4 power meters.

The issue i have is the Chromium browser on the RPI 3 i use to edit the node red flow becomes very slow and sometimes unresponsive when i deploy the flow.

If i was to access the node red browser from another computer via the network address "IP Address :1880" it is fine, runs like a dream very fast and responsive.

This issue is the same across 7 RPI3 devices. Im using Raspian with desktop.
I have tried raspian with no desktop and built up the system from scratch.
I have tried using USB rs485 dongle and it still has not change.
I have tried many other browsers compatible with the RPI3, no change.

Even if it crashes on the raspberry PI, i can still access and edit from a remote computer with no issues.

Teamviewing and VNC makes no difference as essentially im still opeing the same browser server page.

Any help would be great. PLEASE.


Dan

[bob prohaska]

danieljame...@gmail.com wrote:
>
> The issue i have is the Chromium browser on the RPI 3 i use to edit the node red flow becomes very slow and sometimes unresponsive when i deploy the flow.
>

Have you tried setting up some hardware swap on a usb flash drive?
Chromium is a slug on my Pi3 also, but adding a fast(ish) usb flash
drive configured with a swap partition speeds things up hugely.

The write speed of the flash device is critical; I've been using
SanDisk Extreme with good success, there are probably faster devices
out there now.

hth,

bob prohaska

[bob prohaska]

Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
>
> If it is a matter of swap space, I'd recommend using a USB powered
> hard-drive. The rewriting of heavy swap usage will rapidly wear out flash
> memory.
>

That seems to be less of an issue than feared. I've been using USB flash
swap on a Pi2 for the last two years, working much harder than a typical
desktop machine, though by no means 100% 24-7. So far, no problems at all.
It may yet develop problems, but I'm starting to suspect obsolescence will
ends its usefulness first.

bob prohaska

[Kiwi User]

But does this workload swap much? 'top' shows whether swap is being used
or, more drastically, turning swap off and seeing what happens will give
a rather positive indication.

Same question to the OP: when you're running the combo of red flow editor
and Chromium browser does 'top' show that swap space is being used?

Swap usage details are on the 5th line (last line of the header).

--
Martin | martin at
Gregorie | gregorie dot org

[danieljame...@gmail.com]

Sorry for the late reply.

In terms of SSD cards. i'm using the new Samsung EVO Platinum.
No other apps installed. I have tried loading Raspibian Bare bones and only putting pixel and node red back, nothing else. Didn't make a difference.
And as per above, if i edit the flow over the network from the anoterh computer there is no limit what i wish to do.

Ill Check "Top" in the command and copy the report and send to you ?
Hope you can help guys.

Kind regards

[Kiwi User]

On Sun, 14 Jan 2018 04:59:30 -0800, danieljamessmith1979 wrote:

> Ill Check "Top" in the command and copy the report and send to you ?
> Hope you can help guys.
>

You'll find that hard to do because it doesn't produce a static report:
the screen refreshes every second or two.

The swap space line doesn't change that frequently, so you may be able to
get it via screen capture, but its generally good enough to note
approximately what you see and post that. The important number is the
'used' figure, which will be zero if everything that is running fits into
RAM.

The watch points for system performance are:

(1) if the buff/cache figure is small almost all data i/o is going to
require physical disk/hdd access which is always noticeably slower
than if the required files are in the cache.

Cache size = total - (used + free) - from the KiB Mem line

(2) if a program is swapping, this adds to the physical i/o load because
its continually having the transfer chunks of its memory between RAM
and the swap space.

You can work out which program is swapping because its SHR value
tends to exceed its RES value.

[Kiwi User]

On Sun, 14 Jan 2018 10:32:05 -0500, Dennis Lee Bieber wrote:

> I'm still of the opinion that the problem is in the CPU usage of
> the monitoring program
>
You may well be right. I know nothing about Node-red except for a quick
look at its Wikipedia entry, which says that it is written in node.js, is
single threaded and uses async i/o.

I wasn't trying to solve the OPs problem directly. He doesn't seem all
that familiar with the 'top' utility, so I thought a micro-tutorial on it
might be in order, especially since its manpage is quite long.

> So -- I'd consider noting the %CPU column and the associated
> process/command... A partial grab (from a Debian install running in
> VirtualBox -- USE FIXED PITCH FONT TO VIEW):
>
Good point, though it seems as though the node.js runtime should be at
least as efficient as the Java jvm, provided that V8 generates code of
similar efficiency to javac + the jvm's JIT compiler.

[Andrew Gabriel]

In article <p3g12i$45m$1...@news.albasani.net>,

Kiwi User <mar...@mydomain.invalid> writes:
> On Sun, 14 Jan 2018 10:32:05 -0500, Dennis Lee Bieber wrote:
>
>> I'm still of the opinion that the problem is in the CPU usage of
>> the monitoring program
>>
> You may well be right. I know nothing about Node-red except for a quick
> look at its Wikipedia entry, which says that it is written in node.js, is
> single threaded and uses async i/o.

If it's single threaded, it can't use more than one of the four CPU
cores. It may be that only being able to use 25% of a Pi is just not
enough CPU for acceptible response.

> I wasn't trying to solve the OPs problem directly. He doesn't seem all
> that familiar with the 'top' utility, so I thought a micro-tutorial on it
> might be in order, especially since its manpage is quite long.
>
>> So -- I'd consider noting the %CPU column and the associated
>> process/command... A partial grab (from a Debian install running in
>> VirtualBox -- USE FIXED PITCH FONT TO VIEW):
>>
> Good point, though it seems as though the node.js runtime should be at
> least as efficient as the Java jvm, provided that V8 generates code of
> similar efficiency to javac + the jvm's JIT compiler.

To see if you are swapping because system needs more memory than the Pi
has, use:
vmstat 1
and look at the si column. This is the rate of bringing stuff back in
from swap, and indicates the system needs stuff it's previously swapped
out. If this rate is high and little progress is being made by
applications, this would indicate the system is thrashing because the
working set size of the kernel and processes is larger than system
memory. If this is the case, and since you can't add more memory to
the Pi, you would have to find a way to reduce memory usage.

(Looking at the amount swapped out by itself isn't useful, because
swapping out stuff that isn't needed again is harmless.)

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

[Kees Nuyt]

On Sun, 14 Jan 2018 13:52:31 +0000 (UTC), Kiwi User
<mar...@mydomain.invalid> wrote:

> The watch points for system performance are:
>
> (1) if the buff/cache figure is small almost all data i/o is going to
> require physical disk/hdd access which is always noticeably slower
> than if the required files are in the cache.
>
> Cache size = total - (used + free) - from the KiB Mem line

Indeed, that's why it is important to have a swap partition or a
swap file, to free up physical memory for use as cache and
buffers.

> (2) if a program is swapping, this adds to the physical i/o load because
> its continually having the transfer chunks of its memory between RAM
> and the swap space.
>
> You can work out which program is swapping because its SHR value
> tends to exceed its RES value.

Programs that are loaded for a longer time, use swap to get rid of
pages that are only seldomly used from physical memory. The OS
decides on that, the program doesn't have to worry about it.

Swap I/O activity can be observed with
vmstat 5
, which takes a snapshot every 5 seconds.
Observe the si (swap-in)) and so (swap-out).
Stop the report with ^C.

On a well-configured server that is not overloaded, si and so are
zero most of the time, and not a high burden for an SD card or USB
memory stick.

vmstat has a lot of useful options, it is a nice tool to pinpoint
performance bottlenecks.

--
Regards,
Kees Nuyt

[bob prohaska]

Kiwi User <mar...@mydomain.invalid> wrote:
> On Sun, 14 Jan 2018 02:26:24 +0000, bob prohaska wrote:
>
>> Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
>>>
>>> If it is a matter of swap space, I'd recommend using a USB
>>> powered
>>> hard-drive. The rewriting of heavy swap usage will rapidly wear out
>>> flash memory.
>>>
>>>
>> That seems to be less of an issue than feared. I've been using USB flash
>> swap on a Pi2 for the last two years, working much harder than a typical
>> desktop machine, though by no means 100% 24-7. So far, no problems at
>> all.
>> It may yet develop problems, but I'm starting to suspect obsolescence
>> will ends its usefulness first.
>>
> But does this workload swap much? 'top' shows whether swap is being used
> or, more drastically, turning swap off and seeing what happens will give
> a rather positive indication.
>

FreeBSD generally doesn't swap much, a few tens of megs active most of
the time. However, while recompiling the OS swap usage peaks around 1 GB,
which in my case happens a few times per week. That makes _having_ swap
mandatory, though it's little used.

On Raspbian, right now, Chromium is open with three tabs, one of which
is a live graphic animation, the swap line from top is
KiB Swap: 61374632 total, 31308 used, 61343324 free. 314760 cached Mem

With YouTube running a 720p video, the swap usage is slightly higher:
KiB Swap: 61374632 total, 42736 used, 61331896 free. 354428 cached Mem
and creeping up. A few minutes in it's up to
KiB Swap: 61374632 total, 62212 used, 61312420 free. 305156 cached Mem

Without a swap partition Chromium is essentially useless. With swap, the
browswer works quite decently.

bob prohaska

[danieljame...@gmail.com]

Hi People.

I have disabled the swap on the PI.
I have attached a screen shot if this is any help.

Thanks for your efforts to help me.

Dan

On Friday, 12 January 2018 18:06:19 UTC+8, danieljame...@gmail.com wrote:

[danieljame...@gmail.com]

I cannot attached a picture ???

[danieljame...@gmail.com]

On Monday, 15 January 2018 11:19:03 UTC+8, danieljame...@gmail.com wrote:

I cannot actually attach a picture for some reason im not familiar with ?

[Dannaz Perth]

Screen Shot

https://pasteboard.co/H2YODwi.png

[The Natural Philosopher]

On 15/01/18 03:29, danieljame...@gmail.com wrote:
> I cannot attached a picture ???
>
>

Not on usenet text only gropups, no.

Post it somewhere and link to it.


--
The biggest threat to humanity comes from socialism, which has utterly
diverted our attention away from what really matters to our existential
survival, to indulging in navel gazing and faux moral investigations
into what the world ought to be, whilst we fail utterly to deal with
what it actually is.

[jack...@gmail.com]

A much better idea is to use zram.

Bye Jack

[Kees Nuyt]

On Sun, 14 Jan 2018 19:19:01 -0800 (PST),
danieljame...@gmail.com wrote:

>
> Hi People.
>
> I have disabled the swap on the PI.

That may not be a good idea.

This page explains why:
https://chrisdown.name/2018/01/02/in-defence-of-swap.html

> I have attached a screen shot if this is any help.

--
Kees Nuyt

[Kiwi User]

On Mon, 15 Jan 2018 17:58:09 +0100, Kees Nuyt wrote:

> On Sun, 14 Jan 2018 19:19:01 -0800 (PST), danieljame...@gmail.com
> wrote:
>
>
>> Hi People.
>>
>> I have disabled the swap on the PI.
>
> That may not be a good idea.
>
> This page explains why:
> https://chrisdown.name/2018/01/02/in-defence-of-swap.html
>
>

Good description. Thanks for posting the link.

FWIW, when my T440 laptop (8GB RAM, 16GB swapspace, 64 bit Fedora 27) is
doing the sort of stuff it usually does, its memory usage must be nearly
the opposite of an RPi in terms od RAM occupied by programs vs cache
space. If I'm compiling C programs the system seems to stabilise with 1GB
of code in memory (compiler, linker, make and editor) and the remaining
7GB used as cache space. Its noticeable that the first compile of the day
is quite slow, the second is somewhat faster, and the 3rd and following
compiles are faster still and all about the same speed.

Assuming that RPi binaries for the same set of programs are about the
same size as as the X-64 ones, that implies that very much less file
caching is available in the RPi, especially in mine, an oldish 512MB
model B and compilation performance tends to support that: the second and
subsequent compiles of the day are a bit faster than the first, but the
significant speed-up shown by the T440 is never seen on the RPi.

[Robert Riches]

On 2018-01-14, Kiwi User <mar...@mydomain.invalid> wrote:
> On Sun, 14 Jan 2018 04:59:30 -0800, danieljamessmith1979 wrote:
>
>> Ill Check "Top" in the command and copy the report and send to you ?
>> Hope you can help guys.
>>
> You'll find that hard to do because it doesn't produce a static report:
> the screen refreshes every second or two.
>

> ...

Try this:

top -b -n 5 > $somefile

HTH

--
Robert Riches
spamt...@jacob21819.net
(Yes, that is one of my email addresses.)

[Ahem A Rivet's Shot]

On Mon, 15 Jan 2018 17:56:14 +0000 (UTC)
Kiwi User <mar...@mydomain.invalid> wrote:

> Assuming that RPi binaries for the same set of programs are about the
> same size as as the X-64 ones, that implies that very much less file

ARM binaries are quite a bit more compact than X86-64 binaries
which is why ARM hardware manages with less memory than PC hardware.

> caching is available in the RPi, especially in mine, an oldish 512MB

But 512MB is a *lot* less than 8GB and won't have any cache space
available to speak of.

> model B and compilation performance tends to support that: the second and
> subsequent compiles of the day are a bit faster than the first, but the
> significant speed-up shown by the T440 is never seen on the RPi.

You wouldn't 512MB is marginal for compiles really and probably
needs swap for some compiles - if you were using a 4GB Rock64 (or perhaps
even a 2GB Odroid C2) you'd expect to see similar speed up behaviour to your
8GB laptop.(

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

[Stefan Enzinger]

On 2018-01-15 19:30, Ahem A Rivet's Shot wrote:
> On Mon, 15 Jan 2018 17:56:14 +0000 (UTC)
> Kiwi User <mar...@mydomain.invalid> wrote:
>
>> Assuming that RPi binaries for the same set of programs are about the
>> same size as as the X-64 ones, that implies that very much less file
>
> ARM binaries are quite a bit more compact than X86-64 binaries
> which is why ARM hardware manages with less memory than PC hardware.

I always have a hard time accepting that.
ARM is RISC, x86 CISC. I would assume one needs more RISC instructions
to achieve the same CISC instructions. So RISC binaries would be bigger.

But I guess single x86 instructions are bigger then ARM instructions.
And large parts of code are not even using the specialized subset of CISC...

always assuming same pointer size (32 bit vs 64 bit)

[Kiwi User]

On Mon, 15 Jan 2018 18:30:58 +0000, Ahem A Rivet's Shot wrote:

> On Mon, 15 Jan 2018 17:56:14 +0000 (UTC)
> Kiwi User <mar...@mydomain.invalid> wrote:
>
>> Assuming that RPi binaries for the same set of programs are about the
>> same size as as the X-64 ones, that implies that very much less file
>
> ARM binaries are quite a bit more compact than X86-64 binaries
> which is why ARM hardware manages with less memory than PC hardware.
>
>> caching is available in the RPi, especially in mine, an oldish 512MB
>
> But 512MB is a *lot* less than 8GB and won't have any cache space
> available to speak of.
>
>> model B and compilation performance tends to support that: the second
>> and subsequent compiles of the day are a bit faster than the first, but
>> the significant speed-up shown by the T440 is never seen on the RPi.
>
> You wouldn't 512MB is marginal for compiles really and probably
> needs swap for some compiles - if you were using a 4GB Rock64 (or
> perhaps even a 2GB Odroid C2) you'd expect to see similar speed up
> behaviour to your 8GB laptop.(

I've just done a few quick comparisons of programs I've compiled on Intel
box running X-64 Fedora and my 512KB model B under Stretch. In all cases
the programs are compiled with gcc and statically linked. Here's what I
found:

Program X_64 RPi
======= ==== ===
hello.c 7376 8216
spd 87520 89884
me 159573 182208

hello.c is a slightly brighter version of the classic that can be told a
name to say hullo to
$ hello
Hello, C world
$ hello Zaphod Beeblebrox
Hello, Zaphod Beeblebrox

spd is a server I wrote some time ago to allow Java programs to access
serial connections and recently ported to the RPi so a C program can more
easily talk to a PICAXE chip via a USB-serial converter. BTW 'porting' it
to the RPi was as simple as extracting it from the CVS repository on my
house server and running 'make' - a zero effort port!

me is my favourite text editor, aka microEmacs 4.0

I'm pleased to see that my guestimate that the executables would be more
or less the same size was pretty good.

The only surprise is that the ARM executables are all a little bigger
than the X_86 binaries by a factor of 3 to 14 percent.

[Kiwi User]

On Mon, 15 Jan 2018 20:53:31 +0000, Kiwi User wrote:

> The only surprise is that the ARM executables are all a little bigger
> than the X_86 binaries by a factor of 3 to 14 percent.
>

PS: forgot to mention that, of course a 512MB Model B doesn't have 512KB
of RAM available for OS + programs - more like 445MB after some has been
grabbed by the GPU and firmware for use as the built-in screen.

[Ahem A Rivet's Shot]

On Mon, 15 Jan 2018 20:54:58 +0100
Stefan Enzinger <min...@aon.at> wrote:

> On 2018-01-15 19:30, Ahem A Rivet's Shot wrote:
> > On Mon, 15 Jan 2018 17:56:14 +0000 (UTC)
> > Kiwi User <mar...@mydomain.invalid> wrote:
> >
> >> Assuming that RPi binaries for the same set of programs are about the
> >> same size as as the X-64 ones, that implies that very much less file
> >
> > ARM binaries are quite a bit more compact than X86-64 binaries
> > which is why ARM hardware manages with less memory than PC hardware.
>
>
> I always have a hard time accepting that.
> ARM is RISC, x86 CISC. I would assume one needs more RISC instructions
> to achieve the same CISC instructions. So RISC binaries would be bigger.
> But I guess single x86 instructions are bigger then ARM instructions.

Yes ARM instructions are all 32 bit, apart from the 16 bit thumb
instruction set supported on most ARMs. Most ARM instructions are
conditional which eliminates some branching and there's a barrel shifter
which can be applied as part of just about any instruction (so something
like a shift and add is a single instruction executed in one cycle).

The combination is very effective at producing compact efficient
code (especially when thumb is used).

> And large parts of code are not even using the specialized subset of
> CISC...

That was always the weak point of CISC, do the extra instructions
get enough use to justify the silicon.

> always assuming same pointer size (32 bit vs 64 bit)

Indeed.

[druck]

On 14/01/2018 13:52, Kiwi User wrote:
> On Sun, 14 Jan 2018 04:59:30 -0800, danieljamessmith1979 wrote:
>
>> Ill Check "Top" in the command and copy the report and send to you ?
>> Hope you can help guys.
>>
> You'll find that hard to do because it doesn't produce a static report:
> the screen refreshes every second or two.

Do a free -h

---druck

[gregor herrmann]

On Mon, 15 Jan 2018 21:15:11 +0000, Ahem A Rivet's Shot wrote:

> Yes ARM instructions are all 32 bit, apart from the 16 bit thumb
> instruction set supported on most ARMs.

don't tell this my raspi3:

% dpkg-architecture
DEB_BUILD_ARCH=arm64
DEB_BUILD_ARCH_ABI=base
DEB_BUILD_ARCH_BITS=64
DEB_BUILD_ARCH_CPU=arm64
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_ARCH_LIBC=gnu
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_GNU_CPU=aarch64
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=aarch64-linux-gnu
DEB_BUILD_MULTIARCH=aarch64-linux-gnu
[…]


gregor

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Grupo Raison: Quitate El Chaqueton

[Dannaz Perth]

Guys.

As much as it is good to chat 70% of the above threads have nothing to do with my problem. We seem to have steered away from my original topical question

appreciate if you can please help.

Kind regards

[Kiwi User]

On Mon, 15 Jan 2018 16:49:00 -0800, Dannaz Perth wrote:

> Guys.
>
> As much as it is good to chat 70% of the above threads have nothing to
> do with my problem. We seem to have steered away from my original
> topical question
>

Well, what you've posted (free output) shows that, at the time you
grabbed those snapshots, memory was not full and swap was unused, which
raises two new questions:

- what was running on the RPi then, i.e. was it Node-Red + Chromium
or was it something else? If something else, what was running?

- how much CPU was being used at that time?

Run TOP as normal and look at the %CPU column to see what process(es) are
eating the most CPU time. If its obvious and a fairly stable set of
figures, try to take a screen shot and post that. Otherwise, use the
command "top -bn5 >toplog.txt" to capture five snapshots in the
"toplog.txt" file and post that - it might be quite large.

Note that, with 4 CPU cores in an RPi3, by default a process that is
shown as using as 25% of CPU is actually using 100% of one of the four
cores.

[Dannaz Perth]

thanks for getting back on track mate.

Here is a post of the latest screen shot.

FYI. the Pi is only ever running Chromium and node-red.
I have no other apps media programs and/or things running.
I have team viewer installed but never actually fully opened.\

https://pasteboard.co/H39bm5R.png

Look forward to your advise

Kind regards

[Kiwi User]

On Mon, 15 Jan 2018 22:03:19 -0800, Dannaz Perth wrote:

> thanks for getting back on track mate.
>

Thats one of the joys of newsgroups: it pays to read what others have to
say. Even if it doesn't answer exactly what you asked, you may well see
something that turns out to be useful or throws a different light on your
problem.

> Here is a post of the latest screen shot.
>
> FYI. the Pi is only ever running Chromium and node-red.
> I have no other apps media programs and/or things running.
> I have team viewer installed but never actually fully opened.\
>
> https://pasteboard.co/H39bm5R.png
>
> Look forward to your advise
>

Simple: get rid of Chromium and use a different browser. One that doesn't
hog CPU cycles the way Chromium is doing. Or, or run it on a separate
host.

This is obvious from the 'top' display: Chromium is using more than one
core all by itself: 29% of the power of the four cores, showing up as two
processes, one eating 110% of a core and the other thread eating 7% of
another core and both consuming 27% of the available RAM. This makes it
look as though you are running two copies of Chromium (1296 and 1999). If
so, WHY? If you're not running two copies, what are you doing to Chromium
to make it run as two processes?

Meanwhile node-red is quietly sitting in a corner, behaving itself and
doing its own thing while using just 5.3% of one core and 6.8% of
available RAM.

So the bottom line: Chromium is unsuited to monitoring node-red on an RPi
because of its excessive CPU usage and its apparent inability to spread
this load across all available cores.

Subsidiary points:

- By now you should know about the 'man' program, which is used to
display manpages. There is a manpage for every program and library
function installed on your RPi: a manpage described what the program/
function does and how to use it. Manpages are a standard feature in every
version of Linux.


- Do you know about the 'apropos' program? It compares a search term with
the summary line of every manpage and outputs a list of matching manpages.
It is very useful for finding programs and library functions that are
related to something you're trying to do. For instance, if you're
interested in handling times or time intervals measured in seconds, you'd
run "apropos seconds":

$ apropos seconds
DateTime::LeapSecond (3pm) - leap seconds table and utilities
sleep (3) - sleep for a specified number of seconds
time (2) - get time in seconds
ualarm (3) - schedule signal after given number of microseconds
usleep (1) - sleep some number of microseconds
$

[Richard Kettlewell]

Kiwi User <mar...@mydomain.invalid> writes:
> This is obvious from the 'top' display: Chromium is using more than one
> core all by itself: 29% of the power of the four cores, showing up as two
> processes, one eating 110% of a core and the other thread eating 7% of
> another core and both consuming 27% of the available RAM. This makes it
> look as though you are running two copies of Chromium (1296 and 1999). If
> so, WHY? If you're not running two copies, what are you doing to Chromium
> to make it run as two processes?

Chromium is inherently multi-process.

https://www.chromium.org/developers/design-documents/multi-process-architecture

--
https://www.greenend.org.uk/rjk/

[Kiwi User]

On Tue, 16 Jan 2018 13:36:22 +0000, Richard Kettlewell wrote:

> Kiwi User <mar...@mydomain.invalid> writes:
>> This is obvious from the 'top' display: Chromium is using more than one
>> core all by itself: 29% of the power of the four cores, showing up as
>> two processes, one eating 110% of a core and the other thread eating 7%
>> of another core and both consuming 27% of the available RAM. This makes
>> it look as though you are running two copies of Chromium (1296 and
>> 1999). If so, WHY? If you're not running two copies, what are you doing
>> to Chromium to make it run as two processes?
>
> Chromium is inherently multi-process.
>

Understood.

> https://www.chromium.org/developers/design-documents/multi-process-
architecture

That's very useful for understanding what top shows. Thanks for posting.

[Stefan Enzinger]

On 2018-01-16 00:09, gregor herrmann wrote:
> On Mon, 15 Jan 2018 21:15:11 +0000, Ahem A Rivet's Shot wrote:
>
>> Yes ARM instructions are all 32 bit, apart from the 16 bit thumb
>> instruction set supported on most ARMs.
>
> don't tell this my raspi3:
>
> % dpkg-architecture
> DEB_BUILD_ARCH=arm64
> DEB_BUILD_ARCH_ABI=base
> DEB_BUILD_ARCH_BITS=64
> DEB_BUILD_ARCH_CPU=arm64
> DEB_BUILD_ARCH_ENDIAN=little
> DEB_BUILD_ARCH_LIBC=gnu
> DEB_BUILD_ARCH_OS=linux
> DEB_BUILD_GNU_CPU=aarch64
> DEB_BUILD_GNU_SYSTEM=linux-gnu
> DEB_BUILD_GNU_TYPE=aarch64-linux-gnu
> DEB_BUILD_MULTIARCH=aarch64-linux-gnu
> […]

https://en.wikipedia.org/wiki/ARM_architecture#AArch64_features

AArch64 features
New instruction set, A64
[...]
Instructions are still 32 bits long and mostly the same as A32
(with LDM/STM instructions and most conditional execution dropped).

[Kiwi User]

On Tue, 16 Jan 2018 12:02:04 -0500, Dennis Lee Bieber wrote:

> Your browser is eating >100% (being a four-core processor, 100% means
> all of one core). Uh, and you seem to have two browser processes running
> and between them they are eating a quarter of your memory (though that
> may just mean Chromium runs a master process and an additional process
> per open tab; I don't have the experience to tell).
>
The URL posted by Richard says that Chromium has a master process
handling the main screen and supervisory functions plus one process per
tab.

That had me scratching my head for exactly the same reasons as you when I
saw two processes, both called Chromium, until he posted that link: I
know that the Java jvm is a multi-threaded single task and always shows
up as a single line in the 'top' process list.

> Node-Red itself is not using much (though it is using a touch
> more than the X-window system task). In truth -- at the time of
> that screen grab, node-red is in a blocked/sleep state, doing nothing.
>
Yesterday I found description of Node-red internals:
https://en.wikipedia.org/wiki/Node.js

The gory details are the the "Technical details" section.

Summarising, this says Node-red is written in Node.js Javascript. This
runs as compiled machine code generated by Google's V8 runtime package.
The control and management code runs as a single thread using non-
blocking i/o. I/O requests are added to an event queue which is serviced
by a thread pool and uses a call-back mechanism to activate the modules
defined via the Node-red flow editor. The non-blocking i/o, event queue
and thread pool components are all part of the libuv library, which also
supports a mechanism for increasing the size of the thread pool from its
default value of one.

> For comparison purposes (since you stated remoting in with the browser
> running on another computer doesn't show the problem): set up the same
> run as captured here, but do not run the browser locally. Use the remote
> browser. Then capture the TOP output on the RPI again. Without the
> browser hog on the RPI, I expect you'll see total CPU% down around
> 5-10%, or even lower.
>
Yes: good advice.

[Dannaz Perth]

Hello Chaps.

Thanks for the feedback. I was also under the conclusion the memory draw was massive when loading Chromium.
The problem i'm having is not just with Chromium. It happens on every browser app i install.
Below is a screen shot using, Vivaldi. FireFox, LuaKit do the exact same.
It is almost like it cannot handle the Graphics or java used to drive the program nodes.
Is there a way of to determine this. I also followed some tuning tips for Chromium. basically using the web settings page and turning things on and off.

https://pasteboard.co/H3hkYDy.png

Surely this can be fixed ?

Thanks for your help

[A. Dumas]

On 16/01/2018 19:16, Dennis Lee Bieber wrote:
> Possibly of more interest https://nodered.org/docs/hardware/raspberrypi
>
> """
> Note: the default browser included in Raspbian, Epiphany, has some quirks

That is no longer the default browser, Chromium is.

[A. Dumas]

On 16/01/2018 19:16, Dennis Lee Bieber wrote:

> More recent build include Chromium - which also works fine but can be
> rather slow on a Pi1 or Zero.
> """

D'oh! Sorry, never mind.

[A. Dumas]

On 17/01/2018 04:07, Dannaz Perth wrote:
> I was also under the conclusion the memory draw was massive when loading Chromium.
> The problem i'm having is not just with Chromium. It happens on every browser app i install.

> [...]

> Surely this can be fixed ?

No :) The Raspberry Pi is a very limited computer, obviously. Any
full-featured, or even not so full-featured, app will test it. E.g.,
modern top spec mobile phones are a lot more powerful.

Next generation Pi4 is definitely in the works (just makes sense that
they would be developing now) but almost certainly not for this year; I
think the Pi3 was supposed to last at least 3 years. So maybe next year?
They do have a birthday comping up and often launch new hardware in
February. Maybe a Zero with Pi3 chip? Although that would draw a lot
more power and may not be the desired direction. From wiki:

Feb17: ZeroW
Jan17: CM3
Oct16: Pi2 B 1.2
May16: Zero 1.3
Feb16: Pi3 B
Nov15: Zero
Feb15: Pi2 B
Nov14: Pi1 A+
Jul14: Pi1 B+
Apr14: CM1
Feb13: Pi1 A
Apr12: Pi1 B

[Kiwi User]

Maybe not. IIRC Node-red uses JSON to communicate with other processes,
which implies that there's quite a large lump of JavaScript running on
the web browser to convert messages from Node-red into a graphical
display. This obviously consumes CPU cycles, reinforcing the idea that
running the browser remotely on a more powerful host is the way to go.

BTW I don't see why you don't like this approach, which works really well
here: I do almost everything from this laptop, connecting via SSH to my
house server or my RPi as needed. All machines have SSH configured for X11
forwarding, so I can sit in front of anything with an attached screen and
run both command line and graphical programs on anything else on my
network, including the ADSL router.

[Dannaz Perth]

Hello ME Kiwi.

I also use remote option and yes it works fine.
My problem is these devices are deployed in remote areas.
I don't have the authority to enable or purchase port forwarding from the affiliated ISP.

I use teamspeak to log in remotely and make changes to the RPI. My work around this whole thing is to turn the Uart serial port off.
Reset the RPI. then make changes to node red. close it . enable Uart serial.
Restart and away it goes.
For de-buggin its good to see the Nodes working in real time.
My only other option is to pair two RPI's together. one as the gate way and the other as the driver for node red.
I would be able to remotely enter the gateway and then view the node red flow via a local network.

I really wish i could keep this whole thing to 1 device and De-bug.

Thanks for your help

[Samanta tanzeem]

✅🔴▶️▶ Really Amazing ️You Can Try This ◀️◀️🔴✅

✅▶️▶️ CLICK HERE Full HD✅720p✅1080p✅4K✅

WATCH ✅💻📺📱👉https://co.fastmovies.org

ᗪOᗯᑎᒪOᗩᗪ ✅📺📱💻👉https://co.fastmovies.org

🔴WATCH>>ᗪOᗯᑎᒪOᗩᗪ>>LINK>👉https://co.fastmovies.org

✅WATCH>>ᗪOᗯᑎᒪOᗩᗪ>>LINK>👉https://co.fastmovies.org

💚WATCH>>ᗪOᗯᑎᒪOᗩᗪ>>LINK>👉https://co.fastmovies.org

🔴💚 Really Amazing ️You Can Try This💚ᗪOᗯᑎᒪOᗩᗪ LINK >👉https://co.fastmovies.org

🔴💚CLICK HERE Full HD✅720p✅1080p✅4K💚WATCH💚ᗪOᗯᑎᒪOᗩᗪ LINK >👉https://co.fastmovies.org

[Marta Wiliams]

✅🔴▶️▶ Really Amazing ️You Can Try This ◀️◀️🔴✅

✅▶️▶️ CLICK HERE Full HD✅720p✅1080p✅4K✅

WATCH ✅💻📺📱👉https://co.fastmovies.org

ᗪOᗯᑎᒪOᗩᗪ ✅📺📱💻👉https://co.fastmovies.org

🔴WATCH>>ᗪOᗯᑎᒪOᗩᗪ>>LINK>👉https://co.fastmovies.org

✅WATCH>>ᗪOᗯᑎᒪOᗩᗪ>>LINK>👉https://co.fastmovies.org

💚WATCH>>ᗪOᗯᑎᒪOᗩᗪ>>LINK>👉https://co.fastmovies.org

💚 Really Amazing ️You Can Try This💚WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>
👉https://co.fastmovies.org

💚CLICK HERE Full HD>720p>1080p>4K💚WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>
👉https://co.fastmovies.org

🔴ALL>VIDEOS>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org

🔴ALL>VIDEOS>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org

🔴ALL>VIDEOS>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org
🔴ALL>VIDEOS>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org

🔴ALL>VIDEOS>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org

🔴ALL>VIDEOS>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org

✅🔴▶️▶ Really Amazing ️You Can Try This ◀️◀️🔴✅

✅▶️▶️ CLICK HERE Full HD✅720p✅1080p✅4K✅

WATCH ✅💻📺📱👉https://co.fastmovies.org

ᗪOᗯᑎᒪOᗩᗪ ✅📺📱💻👉https://co.fastmovies.org

🔴WATCH>>ᗪOᗯᑎᒪOᗩᗪ>>LINK>👉https://co.fastmovies.org

✅WATCH>>ᗪOᗯᑎᒪOᗩᗪ>>LINK>👉https://co.fastmovies.org

💚WATCH>>ᗪOᗯᑎᒪOᗩᗪ>>LINK>👉https://co.fastmovies.org

💚 Really Amazing ️You Can Try This💚WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>
👉https://co.fastmovies.org

💚CLICK HERE Full HD>720p>1080p>4K💚WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>
👉https://co.fastmovies.org

🔴ALL>VIDEOS>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org

🔴ALL>VIDEOS>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org

🔴ALL>VIDEOS>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org
🔴ALL>VIDEOS>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org

🔴ALL>VIDEOS>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org

🔴ALL>VIDEOS>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org