Just for amusement I've been trying to run the chromium browser
on a Pi2. Obviously, it's slow, but it looks like the cpu isn't
busy at all, mostly idle with a few percent for system processes.

Right now it's stuck loading a page from the New York Times
website. The Pi2 itself is responsive, but the chromium window
seems totally stuck.

Anybody else seeing this? I expected it to perform badly, but
not this badly.

I'm using the "universal" image of bookworm. Is an older image
likely to be better?

Thanks for reading,

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bp@www.zefox.net wrote:

Just for amusement I've been trying to run the chromium browser
on a Pi2. Obviously, it's slow, but it looks like the cpu isn't
busy at all, mostly idle with a few percent for system processes.

Right now it's stuck loading a page from the New York Times
website. The Pi2 itself is responsive, but the chromium window
seems totally stuck.

How much RAM do you have? Is it massively swapping to slow SD card?

If you're using htop, it won't show kernel threads unless you're press F2
for setup and then unselect Display options -> Hide kernel threads.

Theo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bp@www.zefox.net wrote:

Just for amusement I've been trying to run the chromium browser
on a Pi2. Obviously, it's slow, but it looks like the cpu isn't
busy at all, mostly idle with a few percent for system processes.

Right now it's stuck loading a page from the New York Times
website. The Pi2 itself is responsive, but the chromium window
seems totally stuck.

How much RAM? It sounds just like what happened when I recently
tried to run one of the new AARCH64 Firefox binaries now offered
by Mozilla on my Pi Zero 2 (512MB RAM). I could get as far as
starting to load a page (even a small, plain, webpage), but then
regardless of the settings it would always bog down and get stuck,
though other programs would still run (eg. 'top' showing only a
handful of MB of free RAM left).

The odd thing is that I ran Firefox on x86 with 512MB RAM a
couple of years ago and it wasn't nearly as bad.

I haven't run Chrom(ium) on anything for many years, but it sounds
like you've run into the same RAM barrier. One thing I didn't try
is making a swap partition on the SD card, because the I/O speed
through that will likely be even worse than swap on a HDD. But for
"amusement" it might get you a little further along (while wearing
your SD card out).

--
__ __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10 Jul 2025 09:02:41 +1000, Computer Nerd Kev wrote:

I haven't run Chrom(ium) on anything for many years, but it sounds like you've run into the same RAM barrier.

If the system runs low on RAM, Linux wakes up its dreaded “OOM Killer” kernel thread to free up RAM by killing the most memory-hogging processes.
You will see evidence of this happening in the logs. If Chromium loses a process or two, that might indeed bring operation to a screeching halt
(though I would expect to see it display error messages as well).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On 10 Jul 2025 09:02:41 +1000, Computer Nerd Kev wrote:

I haven't run Chrom(ium) on anything for many years, but it sounds like
you've run into the same RAM barrier.

If the system runs low on RAM, Linux wakes up its dreaded “OOM Killer” kernel thread to free up RAM by killing the most memory-hogging processes. You will see evidence of this happening in the logs. If Chromium loses a process or two, that might indeed bring operation to a screeching halt (though I would expect to see it display error messages as well).

This is a Pi2, so 1 gig RAM. I've not messed with the CPU/GPU memory allocation, it's default AFAIK.

A quick look at Task Manager suggests less than half a gig of RAM in use,
htop reports the same with 100M of swap in use out of 500M available.
This is on a somewhat elderly microSD in a default image as distributed
from the Raspberry Pi website.

The task manager is also reporting 0% cpu for all the chromium processes. That's rather odd. At the moment chromium is trying to re-open its window
after being iconified and it's making no progress. After a couple of tries
the "close window" (top right x) got rid of the window.

There are also two "chrome_crashpad_handler" processes, 0% cpu.
Might that be a hint chromium has crashed, and the handler that
generates the "aw snap" dialog crashed too?

thanks for reading!

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jezbon <bonnet.jerome@gmail.com> wrote:

chromium --disable-gpu

Then everything will run only on CPU and HTOP will tell the real story, you'll likely have heaps of threads spawn, and some idea what it's doing (less hidden then when GPU is processing).

Disabling the GPU leads to broadly the same behavior, but I'll have to
watch for a while to be sure. I don't think it's an improvement 8-(

Have you tried falkon (lighter weight QTWebEngine based Chromium - KDE project work) or iridium (stripped out Google BS code version of
chromium)? Do they load the page you're trying to get?

Looks like neither is available for 32-bit RaspiOS. There does seem
to be a 64-bit version of Falkon available, I'll try that on my Pi5:

At the moment the "loading" icon is spinning with a tab label saying data:text/html;charset=U and falcon:start in the URL bar...nothing more. Doesn't look very promising....

Thanks for writing!

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/07/2025 14:19, bp@www.zefox.net wrote:

Just for amusement I've been trying to run the chromium browser
on a Pi2. Obviously, it's slow, but it looks like the cpu isn't
busy at all, mostly idle with a few percent for system processes.

When the Pi 2 came out I did do a little web browsing on it. It wasn't
fast then, but it did work. However that was 10 years ago, and web pages
have got far bigger and browsers fatter and slower, which very much
conspires against the meagre 1GHz and 1GB of the Pi 2.

The Pi 3B/3B+ is a tiny bit quicker at 1.2GHz and 1.4GHz, but still
limited to 1GB of memory, so web browsing isn't appreciably better. Even
with a just few simple google chart based status pages, it is very slow
to update.

The Pi 4B with at least of 4GB is the minimum practical spec for web
browsing. The Pi 5B with 8GB is pretty nippy, and comparable to my 10
year old Intel laptop running Mint.

--druck

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/07/2025 21:17, druck wrote:

On 10/07/2025 00:02, Computer Nerd Kev wrote:

The odd thing is that I ran Firefox on x86 with 512MB RAM a
couple of years ago and it wasn't nearly as bad.

Have a look at the size of the executable "then" (which is more likely
to be 20 to 25 years ago) and now, and you'll see why a 512M Zero 2
doesn't stand a chance.

---druck

webkit webprocess is over 1GB on this machine now. Firefox process
another 800MB

Thunderbird another GB or so.
I buckled and now have 24G RAM.

--
The theory of Communism may be summed up in one sentence: Abolish all
private property.

Karl Marx

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/07/2025 00:02, Computer Nerd Kev wrote:

The odd thing is that I ran Firefox on x86 with 512MB RAM a
couple of years ago and it wasn't nearly as bad.

Have a look at the size of the executable "then" (which is more likely
to be 20 to 25 years ago) and now, and you'll see why a 512M Zero 2
doesn't stand a chance.

---druck

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/07/2025 00:29, Computer Nerd Kev wrote:

druck <news@druck.org.uk> wrote:

On 10/07/2025 00:02, Computer Nerd Kev wrote:

The odd thing is that I ran Firefox on x86 with 512MB RAM a
couple of years ago and it wasn't nearly as bad.

Have a look at the size of the executable "then" (which is more likely
to be 20 to 25 years ago)

No it really was only two or maybe three years ago and Firefox
wasn't that much bigger then.

and now, and you'll see why a 512M Zero 2 doesn't stand a chance.

The Executable still fits easily in 512MB RAM, for some reason it
tries to allocate lots more RAM after starting and displaying the
browser window (which seems to work fine for a few seconds before
it stalls).

It seems the RAM usage increased when they started using multiple
processes:

https://erahm.org/2016/02/11/memory-usage-of-firefox-with-e10s-enabled/

Maybe on the single-core x86 PC it creates fewer processes and
therefore uses less RAM than the quad-core Pi Zero 2? The methods
of turning off Firefox's multi-process mode don't seem to work
anymore. That also shows how the 64bit builds use significantly
more RAM, which will hurt the 64bit RPi Zero 2 but not the 32bit
RPi 2.

There is also the issue that many modern websites are running memory
gobbling Javascript implementations

--
Religion is regarded by the common people as true, by the wise as
foolish, and by the rulers as useful.

(Seneca the Younger, 65 AD)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

druck <news@druck.org.uk> wrote:

On 10/07/2025 00:02, Computer Nerd Kev wrote:

The odd thing is that I ran Firefox on x86 with 512MB RAM a
couple of years ago and it wasn't nearly as bad.

Have a look at the size of the executable "then" (which is more likely
to be 20 to 25 years ago)

No it really was only two or maybe three years ago and Firefox
wasn't that much bigger then.

and now, and you'll see why a 512M Zero 2 doesn't stand a chance.

The Executable still fits easily in 512MB RAM, for some reason it
tries to allocate lots more RAM after starting and displaying the
browser window (which seems to work fine for a few seconds before
it stalls).

It seems the RAM usage increased when they started using multiple
processes:

https://erahm.org/2016/02/11/memory-usage-of-firefox-with-e10s-enabled/

Maybe on the single-core x86 PC it creates fewer processes and
therefore uses less RAM than the quad-core Pi Zero 2? The methods
of turning off Firefox's multi-process mode don't seem to work
anymore. That also shows how the 64bit builds use significantly
more RAM, which will hurt the 64bit RPi Zero 2 but not the 32bit
RPi 2.

--
__ __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 16 Jul 2025 00:37:57 +0100, The Natural Philosopher wrote:

There is also the issue that many modern websites are running memory
gobbling Javascript implementations

Blame that on Google, for pioneering the “V8” JavaScript implementation that greatly sped up its execution speed. Prior to that, JavaScript was
only good for adding limited interactivity to web pages. But suddenly, it became feasible to add enough code to approach the full complexity of a locally-running app -- and all entirely in the browser.

That massive leap in performance also led to JavaScript becoming usable
for back-end development, with nothing to do with browsers at all. Hence
the inception of NodeJS.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16 Jul 2025 09:29:38 +1000, Computer Nerd Kev wrote:

It seems the RAM usage increased when they started using multiple
processes ...

That idea was pioneered by Chrome/Chromium, I believe, as a way to improve
both security and robustness.

Other browser developers eventually realized that, in spite of the
increased resource usage, it was the right thing to do.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Computer Nerd Kev <not@telling.you.invalid> wrote:

druck <news@druck.org.uk> wrote:

and now, and you'll see why a 512M Zero 2 doesn't stand a chance.

The Executable still fits easily in 512MB RAM, for some reason it
tries to allocate lots more RAM after starting and displaying the
browser window (which seems to work fine for a few seconds before
it stalls).

Upgraded from Firefox 140 to 141 on the Pi Zero 2 and it's working
much better. Loads old-fashioned sites fine (though very slowly)
and some modern ones if their Javascript is blocked. With JS or
just big webpages it often gets stuck though.

Weirdly the User-Agent header it sends out says x86_64 though it
says AARCH64 within the browser. Seems it's unwise to be honest
about using ARM when talking to some web servers:

https://www.tomshardware.com/software/youtube-uses-lower-quality-options-on-browsers-with-aarch64-arm-based-systems-reporting-x86_64-appears-to-be-a-widespread-browser-fix

--
__ __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 23 Jul 2025 23:13:33 +1000, Computer Nerd Kev wrote:

Weirdly the User-Agent header it sends out says x86_64 though it says
AARCH64 within the browser. Seems it's unwise to be honest about using
ARM when talking to some web servers ...

If you want to determine the capabilities of the client system, checking
the user-agent seems a pretty naïve, not to say dumb, way of doing it.

It would be better to do a more directly functional check.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)