The main difference with io_uring is you're not blocking the thread, just like O_NONBLOCK + epoll would, but don't have to rely on thread-level syscalls to do so: there's no expensive context switch to kernel mode. Using O_NONBLOCK + epoll is already async :)
In fact, in all cases, you don't know when the syscall actually starts execution even with regular calls. The only thing you're sure is the kernel "knows" about the syscall you want. However, you have absolutely no indication on whether it started to run or not.
The real question is: are the classical measures accurate? All we have is an upper bound on the time it took: I fired the write at t0 and finished reading the response at t1. This does not really change with io_uring. Batches will mostly change one fact: multiple measurements will share a t0, and possibly a t1 when multiple replies arrive at once.
Is it important? Yes and no. The most important thing in such benchmarks is for the added delay to be consistent between measurements, and when it starts to break down. So it's important if you're chasing every µs in the stack, but not if your goal is lowering the p99 which happens under heavy load. In this case, consistency between measurements is paramount in order to get histograms and such that make sense.
It's Arch based, with (iirc) Hyperland as it's "DE", so really not much memory I'd guess.
My desktop runs Arch with Sway (so quite close), three monitors, and uses ~400MB ram after boot. Most of it are the framebuffers. All the rest is eaten by Firefox, rust-analyzer and qemu.
Outside of gaming, not much. However, now that I'm used to a 144Hz main monitor, there is no world where I would get back. You just feel the difference.
So basically, no use when you've not tasted 120+Hz displays. And don't because once you do, you won't go back.
I have a 165hz display that I use at 60hz. Running it at max speed while all I'm doing is writing code or browsing the web feels like a waste of electricity, and might even be bad for the display's longevity.
But for gaming, it really is hard to go back to 60.
Mine supports variable refresh rate, which means for most desktops tasks (I.e when nothing is moving), it runs at 48Hz.
Incredibly, Linux has better support than windows for it on the desktop: DWM runs full blast, while sway supports VRR on the desktop. Windows will only enable it for games (and games that support it). Disclaimer: Wayland compositor required.
It’s not enabled by default on e.g. sway because on some GPU and monitor combos, it can make the display flicker. But if you can, give it a try!
Windows 11 idles at around 60 Hz in 120 Hz modes on my VRR ("G-SYNC Compatible") display when the "Dynamic refresh rate" option is enabled, and supports VRR for applications other than games (e.g., fullscreen 24 FPS video playback runs at 48 Hz* via VRR rather than mode switching, even with "Dynamic refresh rate" disabled).
* The minimum variable refresh rate my display (LG C4) supports is 40 Hz.
Since we're in feedback mode, 2.16 has no BitLineBar reference to feed to the comparators. I had to cheese the level by connecting the "capacitor" outputs straight to the outputs, and it worked.
On the capacitor though, the capacitor level is weird as you don't build the capacitor charge system with transistors. Though I definitely get that the simulation engine is for digital stuff, not analog :)
Also a general feedback on the time-based challenges: dial them back. A lot. Most of them are just not interesting and have zero learning value. In fact, the "DRAM refresh" one just made me quit the game (clicking on 8 rows to keep them fresh). Okay, 10s is enough, I got the point. No need to hold up for a whole minute. Kinda same for the hex one. However, some of them are good, and the UI for the binary ones is great, especially for the two's complement one!
Small nitpick on the UI: some blocks don't have their connections aligned with the grid, making the wiring OCD-incompatible. But that's minor. It's a shame since the wire routing algorithm works quite well overall, and I'm impressed an LLM could produce that good of an UI!
Otherwise, quite a fun little game, if slow paced when one already knows some bits of digital logic. Keep up!
Ever tried to uninstall an antivirus on windows? Or any program that does not want to be uninstalled? I've had programs whose uninstall.exe was no different than /bin/true.
On this point, Windows is no better than macOS: the OS relies on the goodwill of the developers to provide working uninstallers. The only protection is a world where the OS provider does the application packaging: Linux repositories, Mac App Store, Windows Store. And even then, apps are still free to litter your filesystem at runtime, unless they're heavily sandboxed. Then FlatPak it is, or iOS apps or Android apps. Not great.
Yes, I have uninstalled antivirus. The uninstaller removed most of the files, except those in memory. I turned off the computer at the end of the day, and after startup the next morning the remaining files were gone.
The only remaining files were the "user space" like custom preferences or files created by the user using the program. The uninstaller rightfully leaves it up to the user to decide what to do with those.
Except actual routers don't handle the traffic on the CPU, they have dedicated hardware to actually handle the packets. The CPU basically runs the OS, configures the hardware router, and does housekeeping tasks (e.g. ARP or FDB expirations, NAT cleanup, etc). The only packets that ever reach it are "trap to CPU" situations that don't require acceleration as those are rare or expensive to implement in hardware (e.g. better suited to a CPU). Those usually include management protocols (ICMP, ARP, NDP, STP, etc) or packets with unknown destination (e.g. the first packet to an IP that requires ARP resolution).
That's how you can have multi-Gbps on a router with a 200MHz MIPS CPU. Or Tbps on a router with a quad-core Xeon.
The TL;DR is to have two vlans on the cable from your switch (called a "trunk"), "lan" and "wan", carrying the respective LAN and WAN networks. Then, on the Pi, create two vlans on the underlying Ethernet interface. Then those two VLAN interfaces can be configured just like the LAN and WAN interfaces of the router. On the switch, you’d dedicate one port to the WAN by adding it to the WAN VLAN without tagging, and the other interfaces do the LAN VLAN, also untagged.
I’ll pick nftables over iptables any day, it’s leagues better (granted, it’s not hard). The nftables wiki is great, as the syntax and modules are documented in a single easy to read page.
As an added bonus, you get atomic updates of all chains for free.
Granted, for simple usecases, ufw or firewalld may be simpler though.
You can still use the iptables interface for nftables rules if you'd like, but I think you miss out on things like atomic application of rulesets, ranges, lists, and variables (not shell variables).
In this very specific case, battery storage would not have helped (in fact, it would have worsened the problem). One of the issues in the failure is renewables, but not because of intermittence. It's because of their ~infinite ramp and them being DC.
Anything that's not a spinning slug of steel produces AC through an inverter: electronics that take some DC, pass it through MOSFETs and coils, and spits out a mathematically pure sine wave on the output. They are perfectly controllable, and have no inertia: tell them tout output a set power and they happily will.
However, this has a few specific issues:
- infinite ramps produce sudden influx of energy or sudden drops in energy, which can trigger oscillations and trip safety of other plants
- the sine wave being electronically generated, physics won't help you to keep it in phase with the network, and more crucially, keep it lagging/ahead of the network
The last point is the most important one, and one that is actually discussed in the report. AC works well because physics is on our side, so spinning slugs or steel will self-correct depending on the power requirements of the grid, and this includes their phase compared to the grid. How out-of-phase you are is what's commonly called the power factor. Spinning slugs have a natural power factor, but inverter don't: you can make any power factor you want.
Here in the spanish blackout, there was an excess of reactive power (that is, a phase shift happening). Spinning slugs will fight this shift of phase to realign with the correct phase. An inverter will happily follow the sine wave measured and contribute to the excess of reactive power. The report outlines this: there was no "market incentive" for inverters to actively correct the grid's power factor (trad: there are no fines).
So really, more storage would not have helped. They would have tripped just like the other generators, and being inverter-based, they would have contributed to the issue. Not because "muh renewable" or "muh battery", but because of an inherent characteristic of how they're connected to the grid.
Can this be fixed? Of course. We've had the technology for years for inverters to better mimic spinning slugs of steel. Will it be? Of course. Spain's TSO will make it a requirement to fix this and energy producers will comply.
A few closing notes:
- this is not an anti-renewables writeup, but an explanation of the tech, and the fact that renewables are part of the issue is a coincidence on the underlying technical details
- inverters are not the reason the grid failed. but they're a part of why it had a runaway behavior
- yes, wind also runs on inverters despite being spinning things. with the wind being so variable, it's much more efficient to have all turbines be not synchronized, convert their AC to DC, aggregate the DC, and convert back to AC when injecting into the grid
I agree with your detailed assessment, but importantly, I argue more battery storage would've allowed for the grid to fail gracefully through rapid fault isolation and recovery (assuming intelligent orchestration of transmission level fault isolation). Parallels to black start capabilities provided by battery storage in Texas (provided by Tesla's Gambit Energy subsidiary). When faults are detected, the faster you can isolate and contain the fault, the faster you can recover before it spreads through the grid system.
The storage gives you operational and resiliency strength you cannot obtain with generators alone, because of how nimble storage is (advanced power controls), both for energy and grid services.
> Can this be fixed? Of course. We've had the technology for years for inverters to better mimic spinning slugs of steel. Will it be? Of course. Spain's TSO will make it a requirement to fix this and energy producers will comply.
This is synthetic inertia, and is a software capability on the latest battery storage systems. "There was no market mechanism to encourage the deployment of this technology in concert with Spain’s rapid deployment of solar and wind." from my top comment. This should be a hard requirement for all future battery storage systems imho.
> Large-scale battery energy storage systems (BESS) already play a major role in ancillary service markets worldwide. Batteries are especially suitable for fast response times and thus focus on applications with relatively short reaction times. While existing markets mostly require reaction times of a couple of seconds, this will most likely change in the future. During the energy transition, many conventional power plants will fade out of the energy system. Thereby, the amount of rotating masses connected to the power grid will decrease, which means removing a component with quasi-instantaneous power supply to balance out frequency deviations the millisecond they occur. In general, batteries are capable of providing power just as fast but the real-world overall system response time of current BESS for future grid services has only little been studied so far. Thus, the response time of individual components such as the inverter and the interaction of the inverter and control components in the context of a BESS are not yet known. We address this issue by measurements of a 6 MW BESS's inverters for mode changes, inverter power gradients and measurements of the runtime of signals of the control system. The measurements have shown that in the analyzed BESS response times of 175 ms to 325 ms without the measurement feedback loop and 450 ms to 715 ms for the round trip with feedback measurements are possible with hardware that is about five years old. The results prove that even this older components can exceed the requirements from current standards. For even faster future grid services like synthetic inertia, hardware upgrades at the measurement device and the inverters may be necessary.
In fact, in all cases, you don't know when the syscall actually starts execution even with regular calls. The only thing you're sure is the kernel "knows" about the syscall you want. However, you have absolutely no indication on whether it started to run or not.
The real question is: are the classical measures accurate? All we have is an upper bound on the time it took: I fired the write at t0 and finished reading the response at t1. This does not really change with io_uring. Batches will mostly change one fact: multiple measurements will share a t0, and possibly a t1 when multiple replies arrive at once.
Is it important? Yes and no. The most important thing in such benchmarks is for the added delay to be consistent between measurements, and when it starts to break down. So it's important if you're chasing every µs in the stack, but not if your goal is lowering the p99 which happens under heavy load. In this case, consistency between measurements is paramount in order to get histograms and such that make sense.
reply