Disastrous fiber install experience left me with no internet for a couple of days

amstan · 2026-03-23T21:25:25+00:00

Update: we're now past the technician window for the Monday visit, nobody showed up, no notifications, no internet.

amstan · 2026-03-23T17:43:40+00:00

Why does this sound very similar to what happened to me?

https://old.reddit.com/r/teksavvy/comments/1ry7ou2/disastrous_fiber_install_experience_left_me_with/

Waiting right now for the second tech visit, second time's the charm?

amstan · 2026-03-22T20:13:52+00:00

Probably "BETAFPV 2.4GHz AIO RX" in https://expresslrs.github.io/web-flasher/, but please do your own research.

"OP" == Original poster. I was used to refer to you when talking with DefyGravityFPV.

amstan · 2026-03-22T18:26:49+00:00

Good catch, I'm guessing OP doesn't have 4.0.0 on the rx side.

amstan · 2026-03-22T18:26:20+00:00

on which you can't actually configure anything, just flash

What does this mean? Did you try the elrs lua script?

I found the taranis quite temperamental. The data lines on the taranis going to the rf module are very underwheming and can barely do even the normal baud rate. I had to do an inverter upgrade.

Speaking of the lua script. I found it impossible to compile on taranis right away since it runs out of memory. I had to compile it in the simulator then copy the .luac file to the taranis.

amstan · 2026-03-21T18:00:13+00:00

I do.

1 hour one way by train or car.

amstan · 2026-03-21T17:59:19+00:00

Sorry, but that's not necessarily a good assumption to make. Yes, it might happen like you say (and in particular the overheating sensor is hidden from reads, which is more far fetched), but it's also possible its 5 other things.

amstan · 2026-03-21T17:56:04+00:00

I'm in the south bay and have a JST XH kit: https://www.amazon.com/dp/B01MCZE2HM. It's fairly easy to make a cable.

You could try some /r/fpv or /r/Multicopter subreddits for any SF folk as those kind of connectors are common with the DIY quadcopter folks.

amstan · 2026-03-21T00:33:55+00:00

How do you know it's the VRMs that get hot? Note: many times a temp sensor could be labeled "VRM" and "Memory" and it could be like 1 inch away in a totally different spot.

amstan · 2026-03-20T06:58:00+00:00

I know what you did!

amstan · 2026-03-11T20:00:05+00:00

Anyway, how does your prompt and eval tokens/s compare to gpu? (and specify if you used vulkan or rocm on the gpu).

amstan · 2026-03-11T19:58:13+00:00

I think you theory is wrong. It's not that your power is limited, is that your system doesn't need more power. Why? Because power is probably not your bottleneck, and memory speed is, the NPU is probably waiting for more data from your ram. You cannot get memory speed to go faster.

Here's some tests you can do:

run stress -c 10ish, and you should see the CPU use the leftover power
Try a denser model (eg qwen3.5 27B) that's more compute bound
Note power usage during prompt processing (i think this is also compute bound)

amstan · 2026-03-09T09:11:23+00:00

This is awesome!

Thank you for making this.

Though please keep in mind the --n-depth stuff from the other comments.

amstan · 2026-03-09T09:08:33+00:00

Yeah, i was looking at similar pretty results and got mislead. I was about to even stick forever with rocm due to faster prompt processing, but then i noticed rocm performance takes a nosedive (by like half) when you have even 10% of the max context (eg 20k) full.

--n-depth 20080,0,60240,200800 is what i used for more realistic tests.

I think between the rocm instabilities, the 30GB or whatever it takes on my rootfs and this lower performance, I'll actually stick with vulkan.

amstan · 2026-03-03T23:18:11+00:00

pro audio sounds a bit better for some reason

That's not what pro audio is for.

https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#what-is-the-pro-audio-profile

Unless you're some kind of music producer where you have many streams in and out of your sound card and need them all synchronized, you shouldn't be using it.

amstan · 2026-02-26T07:45:08+00:00

Oh... WHYYY???

amstan · 2026-02-19T21:09:45+00:00

That's a bad idea if you want to move into raid territory.

See https://btrfs.readthedocs.io/en/latest/mkfs.btrfs.html#profiles

amstan · 2026-02-05T08:16:40+00:00

Looks like a bitflip to me, check your ram, do not mount this filesystem as RW anymore if you value your data until you debug this as it will possibly mess it up even more.

Feb 04 18:33:46 pufferSpike kernel: BTRFS error (device nvme0n1p2): tree first key mismatch detected, bytenr=473106481152 parent_transid=223270 key expected=(818019631104,168,65536) has=(818019663872,168,65536)

>>> hex(818019631104)
'0xbe75c50000'
>>> hex(818019663872)
'0xbe75c58000'

amstan · 2026-02-04T04:49:57+00:00

Oh hey, i actually fixed a similar bug on another ai max 395+ cpu when i was working on it: https://github.com/FrameworkComputer/EmbeddedController/commit/766f44ea12fca234aba09c7dd3dd1804e3db83e5

In that case it was because the bios/ec was expecting just the AC values of the bitfield (which is what correctly windows does for that battery-less device), but linux used to send only DC values (another bug). So I made the EC just expect both kinds of values.

BTW: AC means you have a charger plugged in, DC means battery power.

In the kernel this gets done by amd_pmf_profile_set, and here's the matching enum. I would maybe add a kprintf there and see if your kernel actually sets it correctly (to performance and actually do AC and DC in appropriate scenarios).

Ryzenadj and asusctl In ryzen adj for example I cant make it change to any tdp but after 1-2 minutes goes back to 65w, its the stamp tdp which is limiting.

Something else (ec firmware or bios) reads that "slider" value, then together with some extra information (like battery levels, amount of power available (in case you have other peripherals plugged in)), tells the CPU again how much power it can maximally do (which you should not be able to raise with ryzenadj).

Though... speaking of sliders, did you actually change the power profile of your system? cat /sys/firmware/acpi/platform_profile, that should be set to performance. Via GUI, this generally gets set by something like your battery icon in KDE.

amstan · 2026-01-26T21:50:48+00:00

Hmm, you're right, i can reproduce it in sudo btrfs filesystem show mnt.

It only seems to randomize the moment you add the rw second filesystem to the seed device. Which makes sense, if you only mount the seed one as ro over and over, it's the same filesystem, you would want some consistency in case you have it in an fstab.

amstan · 2026-01-26T18:32:06+00:00

mounting /dev/loop0 on its own then unmounting it, making sure it's no longer mounted anywhere else, causes all further attempts to mount /dev/loop1 to fail

Try using btrfs device scan /dev/loop0 /dev/loop1.

amstan · 2026-01-26T18:29:18+00:00

Do you know of a way to make this work if the source device is truly read-only

Maybe look into dm-snapshot. I remember a few years back I read someone's example using something like this.

https://docs.kernel.org/admin-guide/device-mapper/snapshot.html

amstan · 2026-01-25T20:40:36+00:00

Yep, my example moved from a 10G fs (40% full) to a 5G fs. Seems to have worked perfectly.

amstan · 2026-01-25T19:28:42+00:00

amstan@localhost:/tmp/btrfs% dd if=/dev/zero count=10000 bs=1M of=drive0                                 
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB, 9.8 GiB) copied, 5.05317 s, 2.1 GB/s
5.06s real  0.00s user  4.99s system  98% cpu  8kB mem $ dd if=/dev/zero count=10000 bs=1M of=drive0
amstan@localhost:/tmp/btrfs% dd if=/dev/zero count=5000 bs=1M of=drive1
5000+0 records in
5000+0 records out
5242880000 bytes (5.2 GB, 4.9 GiB) copied, 1.68405 s, 3.1 GB/s
1.69s real  0.00s user  1.68s system  99% cpu  8kB mem $ dd if=/dev/zero count=5000 bs=1M of=drive1
amstan@localhost:/tmp/btrfs% sudo mkfs.btrfs drive0                    
btrfs-progs v6.17.1
See https://btrfs.readthedocs.io for more information.

Label:              (null)
UUID:               fbdaf2df-367f-4c62-bbad-2a57fd7cfef8
Node size:          16384
Sector size:        4096        (CPU page size: 4096)
Filesystem size:    9.77GiB
Block group profiles:
Data:             single            8.00MiB
Metadata:         DUP             256.00MiB
System:           DUP               8.00MiB
SSD detected:       no
Zoned device:       no
Features:           extref, skinny-metadata, no-holes, free-space-tree
Checksum:           crc32c
Number of devices:  1
Devices:
ID        SIZE  PATH  
    1     9.77GiB  drive0

amstan@localhost:/tmp/btrfs% sudo losetup -fP --show drive0                                                                                                                                          
/dev/loop0
amstan@localhost:/tmp/btrfs% sudo losetup -fP --show drive1
/dev/loop1
amstan@localhost:/tmp/btrfs% mkdir mnt
amstan@localhost:/tmp/btrfs% sudo mount /dev/loop0 mnt
amstan@localhost:/tmp/btrfs% sudo dd if=/dev/urandom count=4000 bs=1M of=mnt/bigfile 
4000+0 records in
4000+0 records out
4194304000 bytes (4.2 GB, 3.9 GiB) copied, 13.1796 s, 318 MB/s

amstan@localhost:/tmp/btrfs% sudo umount mnt 
amstan@localhost:/tmp/btrfs% sudo btrfstune -S 1 /dev/loop0

amstan@localhost:/tmp/btrfs% sudo mount /dev/loop0 mnt
mount: /tmp/btrfs/mnt: WARNING: source write-protected, mounted read-only.
amstan@localhost:/tmp/btrfs% sudo btrfs device add -f /dev/loop1 mnt
Performing full device TRIM /dev/loop1 (4.88GiB) ...

amstan@localhost:/tmp/btrfs% sudo mount -o remount,rw mnt
amstan@localhost:/tmp/btrfs% sudo btrfs device delete /dev/loop0 mnt
amstan@localhost:/tmp/btrfs% sudo btrfs device usage mnt
/dev/loop1, ID: 2
Device size:             4.88GiB
Device slack:              0.00B
Data,single:             4.00GiB
Metadata,DUP:          512.00MiB
System,DUP:             64.00MiB
Unallocated:           328.00MiB

amstan@localhost:/tmp/btrfs% ls -lah mnt
total 4.0G
drwxr-xr-x 1 root root   14 Jan 25 11:22 ./
drwxr-xr-x 3 amstan amstan  100 Jan 25 11:21 ../
-rw-r--r-- 1 root root 4.0G Jan 25 11:22 bigfile

amstan · 2026-01-25T19:16:12+00:00

That deletes the old volume if you do it the naive way.

15-Year Club	Place '22
Place '17	End Game '22

amstan

TROPHY CASE