HN user
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.
Clickable links:
A French company made a product along these lines already, but I don’t think it’s been updated since 2018: https://blog.qarnot.com/introducing-the-qc-1-crypto-heater/
It’s true this is as good as resistive heating in terms of heating efficiency, but it is still far less efficient than a heat pump. Unless you are in an area with a large excess of renewable energy it probably doesn’t make sense environmentally to use an asic heater.
For some two-way wireless protocols (like wifi) you have to take into account the guard interval, slot times and interframe spacing which are all values set in time (~1-50us). For long distance transmissions your speed-of-light limited signal propagation time can exceed these values.
In terms of size usually guard interval < slot size < inter-frame space. If propagation exceeds guard interval AND have a channel with lots of echo any communication will be difficult. If propagation exceeds slot timing then coordination between more than 2 devices will be different (high retries/low throughput). If propagation exceeds interframe spacing a two-way wifi connection will not be possible as both stations will think every frame timed out waiting for an ACK.
More info here: https://en.wikipedia.org/wiki/Guard_interval https://en.wikipedia.org/wiki/Distributed_coordination_funct... https://en.wikipedia.org/wiki/Short_Interframe_Space
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.
It isn't an issue for smaller planes (A320, 737), but larger planes (such as 747, 777, A340, A380) usually have a lower maximum landing weight than their takeoff weight. If an emergency happens early in flight they usually have to dump fuel to reduce weight before they can land. https://en.wikipedia.org/wiki/Fuel_dumping
Some silicon labs arm MCUs and radios have hardened crypto core and hardened bootloaders. Their closest equivalent to the esp32 is the wgm160p but it lacks Bluetooth and costs more.
Disclaimer: used to work there but this is all public information