Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    https://marc.info/?l=openbsd-cvs&m=164768562118583&w=2
    Last edited by brad0; 19 March 2022, 05:57 PM.

    Leave a comment:


  • brad0
    replied
    Originally posted by Ranguvar View Post
    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

    Leave a comment:


  • kylew77
    replied
    Originally posted by brad0 View Post

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

    Leave a comment:


  • brad0
    replied
    Originally posted by kylew77 View Post
    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.
    Last edited by brad0; 13 March 2022, 12:07 AM.

    Leave a comment:


  • hotaru
    replied
    Originally posted by Ranguvar View Post
    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)

    Leave a comment:


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

    Rough.

    At least N on OpenBSD gets things by for now.

    Leave a comment:


  • sinepgib
    replied
    Originally posted by skeevy420 View Post

    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.

    Originally posted by skeevy420 View Post

    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.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by sinepgib View Post

    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.

    Leave a comment:


  • sinepgib
    replied
    Originally posted by skeevy420 View Post
    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?

    Leave a comment:


  • skeevy420
    replied
    Originally posted by sinepgib View Post

    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.
    Last edited by skeevy420; 12 March 2022, 09:37 AM.

    Leave a comment:

Working...
X