FreeBSD Shortening Its Boot Time, ASLR By Default & Better Intel WiFi Support

[brad0]

-current has initial AC support.

https://marc.info/?l=openbsd-cvs&m=164727045605542&w=2
https://marc.info/?l=openbsd-cvs&m=164727054105578&w=2

Starting out with the Intel Wifi 6 adapters and now the Wifi 5 adapters..

https://marc.info/?l=openbsd-cvs&m=164768562118583&w=2

[brad0]

Still no Intel 802.11n support, let alone AC or AX.

Rough.

At least N on OpenBSD gets things by for now.

-current has initial AC support.

https://marc.info/?l=openbsd-cvs&m=164727045605542&w=2
https://marc.info/?l=openbsd-cvs&m=164727054105578&w=2

[kylew77]

Both with 14. 14 is next year.

Thank you, feels like a forever wait for 14 though with it not coming out till 2023.

[brad0]

Anyone know if the ASLR and boot time improvements are coming to 13.1 or if we have to wait years for 14.0 to come out?

Both with 14. 14 is next year.

[hotaru]

Still no Intel 802.11n support,

???

https://wiki.freebsd.org/WiFi/80211n

Some of the wireless drivers support 802.11n. The following is an incomplete list.

• iwn (Intel) NICs - 4965, perhaps others; STA mode only
• ath 11n series NICs (AR5416, AR9130, AR9160, AR9280, AR9285, AR9287, AR94xx, AR95xx) - STA/AP mode, TX and RX aggregation
• mwl NICs (88W8363 802.11n NIC)
• rsu (RTL8188SU / RTL81892SU)
• urtwn (RTL8188CU / RTL8188RU / RTL8188EU / RTL8192CU)

[Ranguvar]

Still no Intel 802.11n support, let alone AC or AX.

Rough.

At least N on OpenBSD gets things by for now.

[sinepgib]

LZ4 is the goto codec on ZFS when you want compression but don't want to be bottle-necked during codec operations. You usually need very high speed disks (expensive NVMe) to outperform LZ4 in compression or decompression.

I'd need to check because my memory is not as good as it used to, I know I'm using either lz4 or zstd in my old Atom laptop (with a regular SSD to saturate its SATA bus), I tried and timed all of the codecs recent kernels support and picked the fastest one. I think it was zstd, but you may be right. Of course, this is an anecdotal note only.

My kernels are between 9-10MB and the initramfs between 21-22MB (Dolphin) and they only contain a minimal amount of modules. That's the uncompressed size. Give me a while and I'll get around to compressing them and see what I get.

Mine are both kernel and initramfs about 7MiB, but the one computer I paid the most attention to wrt boot is the netbook and that's 32 bits, so maybe the smaller kernel is due to that. The initramfs I doubt, being about a third the size is not likely based on that alone. If you remind me tomorrow I can share the exact numbers and my config if you want.

I can't right now because I'm using my employer's Mac to post this.

[skeevy420]

AFAIR lz4 is optimized for compression speed, not size or decompression speed. Size may not seem at all relevant, but it does mean you have a smaller input to your decompressor and less data to read from disk.
I'm certainly surprised cat beat any of the compressed versions, precisely for the data size argument.

I never had a kernel+initramfs take that long on non-behemoth initramfs, even on rotating disks. My netbook currently does the kernel stage in about 1.5". Are you telling mkinitcpio to only pick modules you use and all that? How big is the initramfs?

AFAIK LZ4 is used when you want speed for both. LZ4HC is where you sacrifice compression speed for more data compression, but both have high speed decompression (which Zstd inherited since it's based on LZ4 and by the same author).

LZ4 is the goto codec on ZFS when you want compression but don't want to be bottle-necked during codec operations. You usually need very high speed disks (expensive NVMe) to outperform LZ4 in compression or decompression.

My kernels are between 9-10MB and the initramfs between 21-22MB (Dolphin) and they only contain a minimal amount of modules. That's the uncompressed size. Give me a while and I'll get around to compressing them and see what I get.

[sinepgib]

I was surprised at those results. While not much different, I expected lz4 to be one of the better performers.

AFAIR lz4 is optimized for compression speed, not size or decompression speed. Size may not seem at all relevant, but it does mean you have a smaller input to your decompressor and less data to read from disk.
I'm certainly surprised cat beat any of the compressed versions, precisely for the data size argument.

I never had a kernel+initramfs take that long on non-behemoth initramfs, even on rotating disks. My netbook currently does the kernel stage in about 1.5". Are you telling mkinitcpio to only pick modules you use and all that? How big is the initramfs?

[skeevy420]

My advice: try to trim your initramfs and use zstd rather than lz4.

Without changing from mkinitcpio to something else or trimming it manually, it's as trimmed as possible. I tested lz4, zstd, gzip, and uncompressed.

1. cat 5.6
2. zstd 5.71
3. gzip 5.73
4. lz4 5.75

I was surprised at those results. While not much different, I expected lz4 to be one of the better performers.

Cat is dead on the 5.6 line, the rest are about where they finished between 5.7 and 5.8.

Ext4 root and Fat32 EFI on an SSD. Nothing esoteric or complex; no other compression layer to account for. I'm not sure how to infer these results outside of compressing the kernel adds a hair over a second to boot time.