merbanan

On 8GB VRAM (RTX 2060 Super) + 64GB DRAM I can run Qwen 3.8 Flash Next in usable speeds. The last 2 weeks have resulted in quite some speed ups in Strata land.

I created a pruned experts model of the q2 quant, while it gave good performance on limited hardware there was severe quality degradation.

Q2_0 does 33 tok/s decode and ~600t/s prompt processing at 128k context on RTX2060 8GB VRAM.

ISTA IQ3_XXS does ~21 tok/s decode and ~240t/s prompt processing

Vorbis sends the entropy tables in the actual file at the start.

https://www.xiph.org/vorbis/doc/Vorbis_I_spec.html#x1-470003

If you have the complete file you can calculate the optimal ones. In a streaming scenario that does not work and you have use something you think is good.

Yes. Mediatek SoCs have hardware acceleration support for that.

https://github.com/torvalds/linux/blob/master/drivers/net/et...

Doesn't seem like they are digitising the media.

I read somewhere about a home router that corrupted packets in transit. In this case it was a torrent that never completed because of this. IIRC something in the nat engine bugged out and replaced bytes in the data and not just in the ip header.

More or less everything is broken. Its just that most protocols are designed to handle it.

MAP-T/MAP-E moves the CG-NAT functionality to the CPE. 60x users per IPv4 address should be doable.

Well I think this falls right into the anti-competitive argument. With the option of booting unsigned code the platform is available for anyone. Microsoft did sign boot loaders so linux can boot, there would have been some kind of fallout if they had not. So the booting of unsigned Mach-O sunds like a minimal action to not let it become a public issue for Apple.

The addition of raw mode sounds like a stable abi for booting linux. The Asahi developers have found "stuff" with the hardware. Just that feedback will be of great value to the continued development of the Apple SoCs. So my guess is that the raw mode is a gift with the expectation to be able to see how the Linux folks solves other issues.

Broadcom arm-based devices should have it.

Yes, the clip-on adapter could not power the chip in-circuit. So I use the power from the board. As I said this worked fine on some boards but not others.

I never got a clip-on adapter working on later generation Broadcom devices. On previous ones I shorted the cs-pin to make the nand chip disappear from the SoC. Then you could flash the chip.

Arm based devices have an early boot menu accessible by holding the "a" button. From here boot with fail-safe defaults.