LaurieWired Profile picture
Sep 2 5 tweets 3 min read Read on X
Much like humans, CPUs heal in their sleep.

CPUs are *technically* replaceable / wear items. They don’t last forever.

Yet, the moment stress is removed, transistor degradation (partially) reverses.

It's called Bias Temperature Instability (BTI) recovery: Image
Image
Transistors are little switches.

When you hold a switch on, especially when it’s hot, a bit of charge gets stuck where it shouldn’t.

Every time that happens, it gets a little bit harder to switch.

In other words, the transistor gets a little “lazier”. Image
Over 10 years, in a modern processor, the ALU can slow down 6%!

FPGAs get hit even harder. Run it hard (slightly over-volted), and you’re looking at a few % a year of slowdown.

Not something the average user would notice, but definitely has to be accounted for. Image
Image
The neat part is that BTI damage can be (partially) recovered with…sleep!

Give the transistor a break, and degradation reduces ~40% or more; the longer the better.

CPU C states create lots of tiny idle windows (microsleeps), which drastically increase the lifespan. Image
Image
I’m not exaggerating. Some BTI recovery methods are literally inspired by the human sleep cycle.

“Circadian Rhythms for Future Resilient Electronic Systems” delves deeply into this topic, with real world examples and experiments.

That’s gotta be one of the best book titles I’ve ever seen.Image

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with LaurieWired

LaurieWired Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @lauriewired

Aug 29
I’ve been on a filesystem kick, and it’s interesting to see the DNA of older ideas pop up in modern designs.

BeFS was crazy in the 90s; the whole architecture was basically a searchable database.

Skimming through their book…it sounds a lot like current Apple FS design. Image
Image
Turns out there’s a good reason for that.

“Practical File System Design”, was written by Dominic Giampaolo in 1999, for BeOS.

Giampaolo joined Apple in 2002, where he became lead architect for…APFS.

Released in 2016, it's funny to see the same ideas 17 years later. Image
Image
In some ways, BeFS is still the more “modern” filesystem!

BeFS embedded search into the FS itself, Apple keeps the indexing+search layer separate.

Both love B-trees, per-file metadata, and 64-bit structures.

It's really not *that* different. Image
Read 4 tweets
Aug 21
Why do most uninterruptible power supplies still use old, lead-acid battery tech?

Nearly every battery in your house (phone, watch, even electric car) is lithium based...except UPSs.

It all has to do with battery chemistry. Lead-Acid has some unique advantages: Image
Image
Contrary to what you might think; lithium batteries are not a “straight upgrade”.

Lead-Acid handles being “floated” at near ~100% capacity for years.

Considering UPS’s spend 99.9% of their life sitting at full charge…waiting for an outage, it's an ideal use-case. Image
Lithium-based cells *hate* sitting at 100%.

The thermal management, per-cell protection, and balancing electronics are significantly more complex than lead-acid’s simple float charge.

Lithium UPSs do exist, but they are pricey and make some huge compromises. Image
Read 4 tweets
Aug 19
The West has a blindspot when it comes to alternative CPU designs.

We’re so entrenched in the usual x86, ARM, RISC-V world, that most people have no idea what’s happening over in China.

LoongArch is a fully independent ISA that’s sorta MIPS…sorta RISC-V…and sorta x87! Image
Image
Of course, Loongson (the company) realizes that most software is compiled for x86 and ARM.

Thus, they decided to add some hefty translation layers (LBT) built into the hardware.

LBT gives you for extra scratch registers, x86+ARM eflags, and an x87(!) stack pointer. Image
LoongArch is a *hefty* ISA; about ~2,000 instructions.
To put it in perspective, base RISC-V is like 50.

That said, it’s pretty clean to read. All instructions are 32 bits, and there are only 9 possible formats.

Certainly easier to decipher than modern x86. Image
Read 4 tweets
Aug 15
lp0 is a Linux error code that means “printer on fire.”

It’s not a joke. In the 50s, computerized printing was an experimental field.

At LLNL (yes, the nuclear testing site), cathode ray tubes created a xerographic printer.

...it would occasionally catch fire. Image
Image
State-of-the art at the time, the printer was modified with external fusing ovens hit a whopping…

1 page per second!

In the event of a stall, fresh paper would continuously shoot into the oven, causing aggressive combustion. Image
As tech later advanced to drum machines, the fire “problem” didn’t go away.

High speed rotary drums could cause enough friction during a jam to self-combust.

Even minor hangups needed immediate intervention. Image
Read 5 tweets
Aug 14
PCI link bus designs are incredibly complex.

Standard FR-4 PCB material is basically at its limit. Every year it's harder to keep up with the new standards.

At what point do we flip the architecture on its head...

GPU as the motherboard, CPU as the peripheral? Image
Image
It’s not a new idea.

In the pentium era, Intel created Single Edge Contact Cartridges (SECC).

Instead of being socketed, the CPU was basically slapped on a glorified RAM stick.

Later abandoned due to cost and cooling issues, in the modern era it's starting to make sense. Image
Image
Today's GPUs draw significantly more power than CPUs.

Why is the highest power draw, highest bandwidth component the “peripheral”?

It forces us to route massive power delivery outward, rather than intelligently building from thermal center. Image
Read 4 tweets
Aug 13
Is your compiler a boy or a MAN?

Created by Donald Knuth, it’s a test to check if recursion is implemented properly.

Originally written in ALGOL 60, a precursor to C, but can adapt to nearly any language.

It really stresses the stack and heap, pushing insane call depths:
It’s a fun little program that creates an explosion of self-referential calls in just a few lines of code.

At a recursion depth of 20, the call stack already hits the millions!

Keep in mind, this test was designed in the 1960s; yet even modern systems struggle. Image
Early C fails the test.

The lack of nested functions, along with the simple stack-based memory model makes closures impossible.

You can *sorta* do the test in modern C, but it’s a total hack /w function pointers and structs.

Kinda misses the whole point. Image
Image
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(