Linux Browsers - X11 vs Wayland


(Updated June 8th, 2023)

Firefox, on Gnome, runs through the XWayland layer by default. This causes issues if you want to use screen scaling, as everything will look blurred. You can fix it by forcing native Wayland which, by the way, also enables better support for touchscreens. Double win.

I also recommend switching to a Wayland compositor for modesetting drivers, as some experience vertical tearing on Xorg but not on Wayland.

TLDR

To enable native Wayland on Firefox, put the MOZ_ENABLE_WAYLAND=1 flag on the desktop launcher or before "firefox" on the command line.

For Google Chrome, open "chrome://flags" and change "Native Ozone Platform" to Wayland or Auto.

System Setup

Acer Laptop SP111-31. It is a very old, slow system, where there is more variation between browsers.

For 2022, it was the same system running on the Celeron N3350. Starting with 2024, I upgraded to a quad core N3450, which has two more cores and 200MHz less of boost.

Software

The OS used was Mint 20 in 2022, which was updated to 21.2 in 2024. Because of this, there may be kernel and library related changes that have some performance implications for these benchmarks. Nevertheless, I think it is better to have a suite that is more representative of current performance than not.

What has become apparent is that current performance on this machine, in June 2023, has increased substantially at least for Speedometer 2.0.

I have refrained to move to Speedometer 2.1 as it is faster. I may restart the benchmarking at a later time on that version. Speedometer 3.0 is too slow to run on this particular hardware.

I have also changed the CPUFreq scheduler to 'ondemand', as the default 'schedutil' has always been noticeably slower for me, accross a range of hardware.

Browser support

Edge does not support native Wayland at this time, while Chrome does. Edge on Linux is till a work-in-progress.
Firefox supports both and now enables Wayland when running under a compatible compositor.

Speedometer 2.0 tests

With this I also decided to test performance on the new display server protocol, compared to Xorg. The browser benchmark of choice, has been Speedometer.

Results - N3450:

Chrome  130 (X11)      - 48.10 / 48.96 (max)
Chrome  129 (X11)      - 47.39
Firefox 131 (X11)      - 40.75

Results - N3350  (2022):

Chrome 114 (Wayland)   - 40.40 / 1.00%
Chrome 114 (XWayland)  - 41.10 / 0.67%
Chrome  95 (X11/XFCE)  - 33.20 / 1.00%

Chrome  ?? (X11/XFCE)  - 35.30
Chrome  ?? (XWayland)  - 36.80
-----
Edge    95 (XWayland)  - 24.50 / 0.60%
Edge   114 (XWayland)  - 29.00 / 1.20%
-----
Firefox  93            - 23.90
Firefox (XFCE)         - 25.27
Firefox (XWayland)     - 25.13
Firefox (Wayland)      - 27.78

Conclusion

Definitely better performance, even for Chrome running over XWayland. On Firefox only native improves results and, as usual, trails Chrome quite a bit in benchmarks. More recent hardware sometimes is more up to speed with Chrome/Edge and Windows performance is different than Linux. IIRC, Chrome is slower on Windows vs Linux, Firefox is faster.

For this machine, I have been opting to use Firefox because of support for VA-API video acceleration and for some reason Chrome lags a lot while switching tabs or opening new ones.

Have you tried it, what are your thoughts?

AM3 and AM4 Motherboards for Home Servers - MCE, ECC and RAS Features

ASRock AM4 Pro4 Motherboard

A while back I have built ECC platforms based on consumer hardware and found the information on the web is not really accurate.

Specifically, while ASUS AM3 boards support ECC mode and I have been using this for some years now. I have never witnessed any error being reported during this time, but I am located near the sea level which has influence on the number of cosmic rays.

There is also Machine Check Exceptions support on these platforms but the motherboard itself is hit and miss. These are useful to track errors in CPU caches and other parts, that help prevent data corruption and make you aware of damaged hardware (mostly PSU or board VRMs).

Some TLDR for CPUs:

  • AMD Phenom I/II and Athlon 64 X2 chips support error reporting through module "edac_mce_amd". This module works without ECC and reports cache or other errors related to the CPU.
  • Athlon II also works.
  • For AM4 Ryzen, APUs only support ECC if they are from "Pro" line.
TLDR for motherboard support:
  • ASUS AM3 M4A8xx motherboards officially support ECC but you should not rely on it.
  • ASUS AM4 and Ryzen support ECC through RASDaemon but only on up to date BIOS.
  • Older ASUS AM4 BIOS report through kernel methods but only uncorrectable errors(UE) are logged in '/sys' nodes.
  • All ASRock AM4 boards seem to support ECC mode.
  • Gigabyte AM4 B550 boards mention ECC mode support.
  • Only ECC Unbuffered RAM is supported. (PC3/4-xxxxxE JEDEC specs)

On the kernel side:

  • RAM ECC is supported through "amd64_edac" module. 
  • CPU error reporting is handled by "edac_mce_amd".
Tested hardware:
  • ASUS M4A87TD/USB3
  • ASUS M4A88TD-V EVO/USB3
  • ASUS A320M-K
  • ASUS EX320M Gaming
  • ASUS ROG Strix B450-F

Testing ECC Support

At this point I've had the ASUS M4A board run with ECC RAM for 3+ years and saw no errors reported. This is not really expected, if studies on servers are comparable to consumer hardware.

The only way I see to rapidly test ECC is working is to set unstable timings with ECC disabled and confirm with Memtest86. Next, set it to on and verify it is reporting errors and/or fixing them.

Most hardware will have different ways to report errors and it will take a very long time to test. I don't think most consumer boards will support ECC Error Injection, which would be the best way to test.

ASUS AM3 Motherboards

ASUS M4A88T

The kernel itself only shows messages with no detail, no matter what kernel parameters are passed to 'mce' boot parameter:

[Hardware error] Machine Check Exception

From testing, these will be corrected errors but I don't know how it will handle uncorrectable errors, as those are harder to reproduce. There is some level of functionality here but it seems the kernel will not be aware of corruption of memory from uncorrectable errors.

The first problem is there is no additional information on what exactly the error is, so the OS will not know if it needs to kill some process to prevent data corruption. There should be additional lines after the [Hardware error] entry but the motherboards is not handling the error further.

Also, the '/sys' nodes for 'mc*' entries in edac module will not be populated with error counts. So you can't really track them over time without custom scripts that monitor the kernel log.
I don't consider ECC to be fully functional on these boards because of this, though some posts seemed to imply ECC was correctly supported.

These boards also don't report any kind of error related to CPU errors. I was first aware of this functionality when a damaged ASRock board started locking up but due to errors reported to the OS. On compatible boards, these show up on the kernel messages in the following format:

[Hardware error] Machine Check Excpetion logged
[Hardware error] ERROR DETAILS
These do not get recorded on MCE Log but are specifically handled by the kernel. ('edac_mce_amd' module) This is useful because uncorrected errors can then discard buffers or kill the process with corrupted data.

Because of ASUS not enabling this functionality, you may get some data corruption if the PSU or motherboard VRM are damaged. I would not rely on this hardware without regularly testing CPU stability with something like Prime95.

ASUS AM4
ASUS EX320M Gaming

On ASUS AM4 boards, older BIOS versions would work as the AM3 boards but memory error reporting was working correctly - you could read /sys and get error counts, or look at the kernel log.

On current BIOS, AMD has updated the error reporting to the modern RAS functionality of the Linux Kernel. You have to install RAS Daemon and use 'ras-mc-ctl' command to read error counts.

The corrected errors (CE) are reported in RAS but are not counted in EDAC 'mc*' nodes, only uncorrected errors. The kernel handles UEs and won't reboot the system if the process is non-critical or hits a page cache, which is discarded.

CPU related MCE/RAS may require some register tweaking, according to AMD's documentation for these CPUs. I have managed to reproduce CPU crashes by undervolting, with no errors reported in the kernel or RAS Daemon.

Other AM4 Brands

From ASRock specifications the boards support ECC. This has been the case from A320 up to X570, all the types of motherboards as even the cheapest HDV models with very reduced sizes and price.

Forum users also report it working [Reddit] but it is unknown to what extent and if other CPU errors are reported.

Gigabyte AM4 based on B550 and X570 chipsets are explicitely listed to support ECC mode with unbuffered DIMMs. Boards with A520 chipsets mention ECC but not explicitely "ECC Mode", which may mean it will work normally with ECC DIMMs but not offer the same advanced functionality.

All series of these boards seem to work as long as you select one of those two chipsets.

Gigabyte A520I AC I managed to also boot with ECC and there are a lot of configuration options related to ECC. Further testing is needed on this brand.

GeForce Now Linux with VAAPI Hardware Acceleration

So, being mostly a Linux user has caused me issues with GeForce Now. It is supported but unless you have hardware that is very capable of software decoding, it is going to be slow or very limited.

Google Chrome supports it well but there is no official VAAPI/LIBVA support, which only works for Chromebook devices. On the other hand, Firefox supports video acceleration out of the box nowadays but GeForce Now is not compatible. So this is mostly focused on GFN but you could use these instructions for other websites.

People seem to have had success with patched versions of Chromium but I have found that this has so many levers to pull that I decided to add some information to the discussion. Here is what worked for me.

Software and Hardware

I am running Linux Mint with an old Intel N3450 "Apollo Lake", with Chromium version 131. Any version higher or lower may not work due to different flags or even distro specific compilation flags.

This hardware is quite slow for software decoding but can decode via hardware for pretty much everything, except for 10bit VP9 and AV1.

On Mint and Debian based Linux, you need to install:
  • intel-media-va-driver-non-free
  • intel-gpu-tools (to use "intel_gpu_top")
  • libva-glx2
  • libva-drm2
  • libva-x11
  • vainfo
For other hardware, I haven't tested yet but I think AMD Radeon will have already enough Mesa plumbing that it just works.

You should then run 'vainfo' to make sure everything is working well:
libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.14 (libva 2.12.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 22.3.1 ()
vainfo: Supported profile and entrypoints
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileNone                   : VAEntrypointStats
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointFEI
      VAProfileH264Main               : VAEntrypointEncSliceLP
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointFEI
      VAProfileH264High               : VAEntrypointEncSliceLP
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointEncPicture
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointFEI
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
      VAProfileVP8Version0_3          : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointFEI
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD

 VAEntryPointVLD means it is decoder, for each line, and EncSlice means there is decoding support.

Chromium

Let's say I have had many issues getting this to work well, since everyone seems to be hanging on older flags that seem rather useless.

Browsing for recent code reviews, it seems the new flag is AcceleratedVideoDecodeLinuxGL, like so:
--enable-features=AcceleratedVideoDecodeLinuxGL

The other requirement is that this only works on X11, so you need to go to the "chrome://flags" URL and set the Ozone platform to force X11.

I will updated this if something changes.

GeForceNow Silliness

I have not managed to get Gnome + Wayland working without this going over XWayland.

For some bizarre reason, GFN reports Chromium as unsupported when running Chromium natively on Gnome/Wayland.

There is no amount of extensions that will fix this, you just need to run it over X11. User agent seems to always report X11, so it is likely the browser is sending other types of hints.

Some years ago, spoofing the user agent would make it work and work well. Now, it doesn't.

I think you can create a profile just for GeForce Now and have that load with X11 Ozone. But Chromium is usually much slower due to a lack of Profile Guided Optimizations (PGO), so you're better off with Chrome for most of the browsing. (especially on a slower machine!).

Encoding Support

I haven't found many reports on the web but you can also enable video encoding for other types of apps.

Just add the new flag, so the command line is:
--enable-features=AcceleratedVideoDecodeLinuxGL,AcceleratedVideoEncoder

The "GPU Internals page" will show decoder information, so you know it is working correctly:


 Let me know what is your experience and if you got it working this way.

Flash Memory Specifications Archive

Last updated - 2018/04/09

Micron

3D NAND - 1st generation

Micron 3D NAND
Micron 3D NAND Datasheet

I found this table interesting enough that I wanted to highlight it. Micron seem to manufacture the chips in a way that the page size remains the standard 16KiB but the erase block is a multiple of three (above should read 24MiB + 2208KiB). The 2208KiB is simply where the error correction information is stored. Unfortunately, there is no information about the number of expected erase cycles.

Anandtech also shares the following details about Micron's 3D NAND

On a smaller scale, the 3D NAND will have a page size of 16kB and erase block sizes of 16MiB for the MLC and 24MiB for the TLC. Because CPUs and file systems are still mostly dealing with 4KiB chunks, Micron has included a partial page read capability that allows for a 4KiB read to be done a bit faster and with about half the power of a full 16KiB page read.
This is an interesting data point, one which we can take a look at with programs like "flashbench". Sometimes one can spot half page reads (8KiB) being faster but optimizing for file system page size is even better.

SK Hynix

I haven't managed to find much information about Hynix chips but they did a presentation in 2022, where they detailed the upcoming 300 layer NAND flash chips.


While most of the information is not really interesting, they do state that page size has now moved up to 16KiB, which has implications for operating system performance. Sadly, there is no information available about block sizes. This is still TLC type NAND.

Hynix QLC 96L NAND was using 24MiB erase blocks in 2020, but this is TLC, still I don't expect to be smaller than that.

Toshiba

BiCS 3 QLC (3D NAND)

Details are very scarce about these chips, except that dies are available in 768Gb capacities and that endurance of this solution is confirmed to be around 1000 erase cycles (Toshiba QLC NAND - Anandtech).

BiCS 4

Not much information is available, except that it features 96 layers.

List of Dangerous ATX Power Suplies

I was debating whether or not to title this post as it did, but after the 3rd non-compliant PSU, either I method is not the best or there is something very wrong with certification.

I am not an electrical engineer but took some courses and have dabbled with hardware for more than two decades now. I have used all the type of bad PSUs one can think of but soon realized that is not the best idea. I have posted my list of good PSUs a while back.

Lexar 16GB Class 10 microSD Review

This is a rather old microSD card, which I had used very little as mobile storage. I expect it to behave as when it was new.

Lexar was a brand of Micron and has produced some flash drives/microSD cards that are not really usable for Raspberry Pi OS installs or even as adoptable storage for Android.
Lexar is now a brand of Longsys, a chinese company. Current microSD cards and USB drives may have no resemblance to the ones manufactured by Micron. I also can't seem to find these on sale on Amazon US.

Find on Amazon UK, in 32 to 512GB sizes: Lexar 633x microSDXC Card

Hertzbleed Simplified - CPU Vulnerabilities

Hertzbleed is a new vulnerability that is present on Intel and AMD CPUs. It allows extracting information from much like Spectre does, though it is more feasible to exploit over a network.
On the whole, after reading the paper, it is not as big of a problem like those vulnerabilities but it is important to understand if you are a sysadmin.

What it can do:
  • Remotely break encryption keys from only SIKE, at this time,
  • Remotely means only local, Ethernet networks, not over the internet (<1ms latency in the paper), [2]
  • Only works on CPUs with very fine-grained clock boosting (Ryzen 2nd+ gen, Intel 9th+) [1]
  • Can weaken kernel defenses against hacks (ASLR).