There is sadly no hdmi CEC support on Most GPUs for pcs. So when you want your tv to turn on and off with your pc it is only possible with the tv being reachable from your pc via ip.

I believe LG doesn’t advertise such an api via Bluetooth

You can get USB controlled CEC injectors for HDMI.

https://www.pulse-eight.com/p/104/usb-hdmi-cec-adapter

For a 4K120Hz TV I'd be worried about this adding signal integrity issues - "all versions of HDMI®, including HDMI® 2.0a" doesn't inspire confidence.

My understanding is that CEC can be received on any alive interface, not just the active.

Yes but you will lose 120 FPS/VRR. So for high end TVs not really ideal.

HDMI breakout and a esp32 module flashed with esphome is another option. The tv most likely doesn’t care that the port that sent on/off command is not the same port the video signal is coming from..

The tv does care which port it came from, since it automatically switches to the one which made the request.

One could build a IR emitter but you need soldering skills for that or buy a usb one which cost north of 30€ + shipping.

For responsiveness that’s what you want, context switches add quite a lot of jitter and perceived slowness’s, making your app feel slow despite running at 120 fps.

I found out that using mmap and just telling uring to read form there to beat anything else.

Depends a lot on the memory pressure. If you can be fairly certain the data is (or will be) resident in memory, mmap is basically unbeatable. If you can't (because the data is larger than RAM or there's other stuff competing for RAM), mmap can have gnarly system-wide performance implications[1].

[1] Mandatory mmap=poop-emoji link: https://db.cs.cmu.edu/mmap-cidr2022/

In my case: its a PROT_READ, MAP_PRIVAT map and i cannot get a SIGBUS since i tell the kernel to handle it all for me, thanks to liburing, instead i get a short send in that case.

Why would you use uring to read from an mmap? Couldn't you just memcpy?

To be more precise: i use that map to send assets out directly to clients from a zip file.

Its a new web server i am building and its the fastest way i could find out.

Just switching from epoll to liburing made the server ~45% faster too, its ridiculous. It can serve 10 gigabyte per second with a single thread, or around 10 million responses per second with h2 and 32 multiplexed requests.

I had to write a new http load generator for that since i couldn't find one which could generate enough load to saturate my server or be fast enough to withstand it.

10 gb per second is pretty slow for a disk. You should be seeing much higher than that.

??? The only configuration that will allow disk reads at 10 GB/s is if you're using PCIe 5.0. PCIe 4.0 or lower, and SATA will not drop out long before that.

He's very clearly hauling data straight from the page cache.

...I'm still confused why you wouldn't use memcpy?

How can one memcpy from a fd to a socket? I don’t touch the bytes in userspace, I just tell the kernel to send them out.

So why would you mmap?

to not let the bytes i forward enter userspace, i serve from the page cache for the asset path, directly from a zip file.

i open the file, mmap it, close it and tell io_uring_prep_send which bytes from the mapping to send, this also saves me from a possible SIGBUS cause the access to the mmap happen inside the kernel, and when a SIGBUS would happen in userspace the kernel just reports a shorter send in cqe->res

Maybe they meant using IORING_OP_MADVISE with MADV_WILLNEED to bring ranges into memory?

The Linux-specific MADV_POPULATE_READ is much more reliable than MADV_WILLNEED if you want to implement read-ahead for a memory-mapped file.

In my opinion, the POSIX advices specified for madvise are useless or even dangerous.

On Linux, for precise control of memory-mapped files one should use only these 4 Linux-specific advices: MADV_COLD, MADV_PAGEOUT, MADV_POPULATE_READ & MADV_POPULATE_WRITE.

These should be used within io_uring, so that they will be executed asynchronously.

These have a well-documented meaning and using them carefully should be sufficient to reach optimum performance with mmap.

Though at that point you can just use FADV_WILLNEED.

I'm just steelmanning here ¯\_(ツ)_/¯

Databases vendors usually find that read outperforms mmap. Mmap being fast is a myth.

Tried every way to get contents of a file as fast to a client socket as possible.

mmap and io_uring_prep_send were faster than everything else, no matter the size as long as you keep the map around for the lifetime of the process.

for one off sends when a file is smaller than 256kb then io_uring_prep_read + prep_send are faster than everything else.

Databases don't send files to client sockets as fast as possible. They do computation and lots of random access.

Note that grandparent actually didn't say they used mmap to actually get the memory, just mapping it.

Firefox is still popular in Germany, at around 10%

I remember when it was the last bastion of Firefox users with a majority marketshare there when everyone else already switched to Chrome...

>I would think that the German state or EU should provide funding for his museum. If that's not the case, it's a shame.

There is another Museum of his, which is still funded.

It is still a shame that the city which called itself Zuse-City does not try harder to keep it. I know how hard their financing situation is first hand but the ZCOM as a place and education institute was more worth then they understood.

how do they handle that malloc aint async signal safe?

You don’t have to do any significant work within the signal handler itself. In fact, the signal handler can literally be empty. What matters is that as long as SA_RESTART is not set, after the signal handler runs, the interrupted syscall fails with errno set to EINTR. Then the code that did the syscall can check whether a cancellation occurred (and retry the syscall if not).

Disclaimer: I haven’t looked at Zig’s implementation; I’m only going off how the Unix APIs work.

You can have virtually unlimited amount of rules, its just a limit per list, the number of lists aint really limited.

Network IO is heavily NIC queue bound, if your NIC only has one queue it just makes it slower to do any threading workload against it.

On my ryzen 9 it needs around 8 cores to do the same work in a threaded io loop than you can do single threaded. And the mechanism doesnt matter, you could share an fd, use SO_REUSEPORT or just share memory between threads.

Just doing the sharing makes everything extremely slow. One context switch becomes more expensive than just doing it single threaded.

Routers got such a thing build in nowadays, just gotta enable it (not the ones from your ISP of course)