totallyabstract

Jet fuel has no lead, it's basically kerosene. Avgas for reciprocating engines (basically only small general aviation planes/helicopters) currently contains lead but is moving to be lead free in the US.

I think this is a bit of a pedantic take. My reading of the GP is to distinguish systems based on chemical batteries from systems based on gravitational batteries rather than the reaction time of the chemical cells specifically.

Also have to take into account that number was at ground level where there is the highest air density. I’m not sure what the landing and takeoff profiles looked like in the design but presumably the wings are that size so it can operate at a higher altitude at a reasonable speed.

Sorry poor terminology use on my part. I mean more broadly that most energy is used on frontend and middle end, rather than backend and that this is what vectorisation improves in regards to energy consumption. Register renaming and branch prediction energy consumption should be improved in the same factor as decoding. Caching probably less so (depending if we are talking instruction, data or combined).

I don’t think inter-core communication is too relevant when comparing vectored and non-vectored on a single core, but definitely would be when batching across multiple cores.

Wouldn't that support the idea that most energy consumption is in decoding? If you're getting 2x, 4x, 8x ect as much value computation per instruction and yet only a 30% increase in power then clearly most the power is not used by computing the values.

Presumably two different instances of this clock would have different tick rates due to the specific crystal used and it's very difficult to produce two identical crystals.

An atomic clock is very consistent across devices as it exploits the properties of an element which is much more repeatable (just have to have a quantity of the element).

There are separate micro op caches per core however they are typically shared among hyperthreads. I wonder if this could be another good reason for cloud vendors to move away from 1vCPU = 1 hyperthread to 1vCPU = 1 core for x86 when sharing machines (not that there weren't enough good reasons already).

It will be interesting see if the next waves of wifi products solve this. For Wifi 6 and Halow there's a new feature called 'target wake time' that will let these devices sleep (and not pollute spectrum) for longer.

Wifi 6 also brings OFDMA which will let stations use much less of the channel at a time (instead of a 20MHZ+ chunk they can just use 2MHZ while other stations use the rest). 2.4GHz being stuck on old Wifi 4 (or worse) devices hasn't helped the situation.

A recent development not mentioned in this article is Wi-Fi Halow/802.11ah, this is a new standard using the 900MHz ISM band. Advantages of this are better signal penetration/range for the same output power (or lower output power for the same range).

Compared to 2.4/5G wifi Halow uses narrower bandwidths so has lower data rates but is still much higher than BLE. BLE can do up to ~2MBit with a 2MHz BW, 802.11ah can do up to ~8MBit with a 2MHz BW but can go up to 16MHz BW. Additionally 802.11ah supports MIMO, so it can also scale the bandwidth up with more antennas.

There are some other new fun features in 802.11ah namely TWT (target wake time) which is a powersaving method that solves a lot of the problems the article mentioned with powersaving in wifi.

You'd need two KC-46 to fully refuel a 747-400F. KC-46 holds about 120KL of fuel, the 747 takes about 200KL.

It depends what your are doing. Some chips can get down to about 100uw to maintain associated and send small amounts of data. I'm not sure how they would compare at 2mbit or how the range would compare.