OpenBSD: Hibernate Time Reduced | Hacker News Reader

OpenBSD: Hibernate Time Reduced

undeadly.org

68 pointsrodrigo97529 comments

The code change on GitHub: https://github.com/openbsd/src/commit/56bc0efbd80da2ff595e44...

Not identical but related: do compilers tune with the OS to get code and data into L1 cache? I believe so, I want to believe you can compile to avoid mem fetch, let alone disc. E.g. if I know my AES needs a 20k table, does the compiler know how to make this apparent to the CPU farm so its never out of L1?

I continue to believe a 2cpu 1mb L1 cache is faster than 2 cpu, 2HT, 512k L1 cache. 4x fake CPUs and less L1 doesn't beat true cpu and lots of cache on die. But, I might be wrong!

Profile guided optimization can help compilers put data in the right place, but in general compilers are not very good at that.

A Friend was writing a tester (UDP dns, preformed packets) and said he was able to code it so the entire test program fitted in L1.

He then did some work on cpu affinity, for this code and for the IP stack. IP fits in amazingly small space, 25k in pdp11 pre-risc architecture. I think he said he was saturating multi gigabit links.

Lot of hand coding going on however. Probably asm.

Great to hear that; Getting closer to running it as a bare-metal desktop OS by the day.

Look being a great fan of BSD (especially FreeBSD), i have one big problem with all of them on my laptop....and it is Wireless! A max speed of ~650kb/s is just not a usable one today.

Well and on the workstation that you cannot change fanspeed on a AMD-GPU, those are my 2 big-points.

> A max speed of ~650kb/s is just not a usable one today

What card model, how do you have it configured, and how far from the router are you? 650kb/s is not an inherent limit on any BSD, and much higher speeds are easily possible if you have supported hardware.

OpenBSD is well known to have a weak 802.11 stack that only supports a/b/g/sorta n modes on the most common drivers (Intel).

This is not because OpenBSD somehow sucks, it's because there's approximately two people doing all the wireless development in their spare time. But it's very understandable that someone would find it to be an issue.

FreeBSD probably doesn't have this issue, but it's not exactly trivial to port a device driver.

As a user, I'm well aware of the state of OpenBSD's wireless stack. It's slower than the competition, but it's not 650kb/s slow.

Its a Intel Dual Band Wireless-AC 7265NGW (ThinkPad x250) running with 802.11/g (the maximum), with the right driver and firmware. Sitting about 5m from the hotspot.

BTW: The hardware is supported:

https://www.freebsd.org/cgi/man.cgi?iwm(4)

>device iwm7265fw

>Currently, iwm only supports 802.11b and 802.11g modes.

https://www.freebsd.org/cgi/man.cgi?query=iwmfw&sektion=4&ap...

>iwm7265Dfw_load="YES" -> This one works

>iwm7265fw_load="YES" -> This one is not working

I would say OpenBSD is as behind as every single BSD is...from the Wireless standpoint.

I've been on cat-v when devs were discussing developing wireless drivers for 9front (plan 9 fork) and most of these problems are due to lack of documentation. These cards are software driven so the driver isn't interacting with hardware registers or memory like an ethernet card but a protocol between the running firmware blob and the kernel. And you are responsible for loading that proprietary firmware into the card as well. You're essentially interacting with a black box. Its almost voodoo.

Some cards work perfectly by copying OpenBSD drivers or have some documentation. Though many cards require cargo culting by copying undocumented behavior from undocumented Linux drivers in order to get the cards working. The big problem with that approach are issues which arise cant be debuged. Best they can do is poke around and guess.

This whole thing is the fault of hardware manufactures.

OpenBSD gets hit the hardest because the devs are the most hardline about never signing an NDA or otherwise impairing the freeness of the drivers.

I agree with never signing an NDA because it leads to code which can not be reliably maintained as the only person who can maintain it is the person who signed the NDA. How do you perform code audits on those drivers?

I have to assume most Linux WiFi drivers are written by people working for companies who get to see documentation via NDA as part of a company project OR the driver was written by the manufacturer who already knows how to talk to the card.

So everyone else has to cargo cult those drivers by blindly copying the voodoo code and hope it initializes the card the same way it does in Linux. Someone suggested adding a driver compatibility layer to allow using FreeBSD drivers in 9front but the devs shot it down with "that layer would be bigger than the kernel itself" So now you're now responsible for maintaining that HUGE mess plus you're still dealing with black box drivers you hope someone else fixes when they don't work. No one wins.

Again, the damn hardware manufactures have to give us proper hardware documentation. Until then they can go suck an egg.

>Until then they can go suck an egg.

No, we suck an egg...that's the problem.

It is really easy to just purchase a better supported wifi card.

It is supported as you can read for yourself:

https://www.freebsd.org/cgi/man.cgi?iwm(4)

>Intel Dual Band Wireless AC 7265

Yeah please tell me what is "better" supported?

I don't know much about the current state of freebsd wifi drivers or drivers for modern cards but I can say for certain the OpenBSD has excellent support particularly for the Atheros cards, under the ath and athn drivers for 802.11a/b/g/n.

Never had an issue with link speed in the past 10 years.

In my experience on OpenBSD at least Intel cards are not as well supported as Atheros.

For example the iwn driver for some intel cards seems buggy / flawed at times.

As I said I have not used FreeBSD recently but might be worth trying an Atheros card.

As far as I know FreeBSD does not offer many advantages over OpenBSD besides ZFS support abd maybe linux comparibility if that still exists. I started with FreeBSD but switched to OpenBSD about a decade ago and found that the hardware support for Thinkpads was excellent. I heard at one time not sure if this is true anymore but I heard that many FreeBSD developers are MacOS users while OpenBSD developers actually develop from OpenBSD on thinkpads thus Thinkpad hardware support is usually excellent.

If your ac card is slower than a/b/g/n then downgrade obviously.

Yeah, tell me what card is good, and not that others have a problem...you know that would be some real help.

>As I said I have not used FreeBSD recently but might be worth trying an Atheros card.

Yeah NO, i don't buy a card just to try out.

>As far as I know FreeBSD does not offer many advantages over OpenBSD besides ZFS support abd maybe linux comparibility if that still exists

Stop with that, i used FreeBSD since over 5 years, i know why i use FreeBSD and not Net or Open-BSD

Chances are you don't need an ac card.

see

https://www.freebsd.org/cgi/man.cgi?query=ath&apropos=0&sekt...

Man you can get an atheros card off of ebay probably for less than $15 shipping included. If your OS does not support your card you could try using a card that is supported, a different OS, or a wired link. What I don't get is somebody complaining about wifi speed in 2021 when a replacement card is $15. Anyway only trying to be helpful.

If you are doing almost anything over the internet there is no advantage of ac over abgn. The wifi lan is not the bottleneck. If you are doing something local that requires superfast data transfer then just run gigabit ethernet or whatever the the cool kids are doing these days.

what's in your way?

Compatibility. Linux binaries need to be recompiled on BSD. BSD and Docker or Podman is probably not a thing. Working with containers and Kubernetes means I need to compile about 100 Go projects. Uhh.. just no. I have better things to do with my time.

>Linux binaries need to be recompiled on BSD

Ehhm NO:

https://docs.freebsd.org/en/books/handbook/linuxemu/

>BSD and Docker or Podman is probably not a thing.

True but you can try:

https://bastillebsd.org/

>Working with containers and Kubernetes means I need to compile about 100 Go projects

Ehhm NO:

pkg install kubectl

It really sound's you dont even read the FreeBSD Handbook.

> >Linux binaries need to be recompiled on BSD

> Ehhm NO:

> https://docs.freebsd.org/en/books/handbook/linuxemu/

Keyword in that link is most binaries. I don't want to worry about if binary x won't run and be stuck compiling it for BSD.

> >BSD and Docker or Podman is probably not a thing.

> True but you can try:

> https://bastillebsd.org/

That is not the same thing compared to Docker or Podman at all. If your looking to build Docker images locally to test in a kubernetes cluster good luck with bastille.

> >Working with containers and Kubernetes means I need to compile about 100 Go projects

> Ehhm NO:

> pkg install kubectl

What about stern, kubie, and the hundred other cli tools that makes managing a cluster much easier?

I get BSD is not for the faint hearted like me who just wants things to work. I'd rather spend my time elsewhere than worrying or running into issues using a esoteric operating system.

>I don't want to worry about if binary x won't run and be stuck compiling it for BSD.

Again you did not read, it's a Emulation-Layer you can run the binary (compiled on linux) on freebsd.

>If your looking to build Docker images locally to test in a kubernetes cluster

Why build them locally if you have a cluster in the first place? It's like saying No to Linux because i cannot test my Jails on it.

>What about stern, kubie, and the hundred other cli tools that makes managing a cluster much easier?

I don't know, but i use normally a management station with all the tools and connect with mosh to it. This way i have the freedom to use whatever OS or Device i want.

> I'd rather spend my time elsewhere than worrying or running into issues using a esoteric operating system.

No problem with that, some people love operating-systems and explore them as a hobby like me, and others just want to work.

To echo another commenter - What's stopping you?

OpenBSD is super easy to install and set up, provided you do a little homework and make sure your hardware is supported.

I have it running on an old think pad and it's a great daily driver. The only thing that gets in your way is that you're going to be missing a handful of applications you might want to run, particularly anything using electron. But there are enough application out there, that you should be able to find suitable alternatives.

The main problem for me is the Widevine incompatibility. While many people see this as an advantage, I actually do enjoy the convenience of using Netflix/Spotify instead of Torrents/alternative clients.

Out of interest what does similar numbers look like on Windows, Linux, etc?

My personal laptop takes what, ~8s (at 16GB ram)? My work laptop (32GB) is around ~25s I think, but I'm not using the hibernation there since in-kernel amdgpu driver does not survive the restore from it.

If you want to make hibernation happen on you work laptop, you might want to try bundling the AMDGPU driver in the kernel (as opposite of building it as a module).

It was the only way I managed to make hibernation work on a Intel NUC.

Reply on news.ycombinator.com