u/das1996

Both of us are on att fiber/1gbit. I'm bypassed on gpon. Remote client sits behind a bgw320, also on gpon. Connection to all remote endpoints is over wg tunnel.

Had a zfs replication task fail at exactly 30m - it was a single snapshot that had ~180GB of new data since the last snapshot. Most of it completed. This was a daily scheduled overnight replication task in TN. Replication task is configured using ssh+nc.

This morning i ran a simple single stream iperf3 test to the same target. It too failed at 30m (30m20s to be exact).

I then reran the same iperf3 test from the same local client to my vps endpoint. No issues after 30m. Speeds were more sporadic given it's a vps.

From my the local truenas instance to remote tn I get consistent 890mbps upload over wg. Test to the vps test fluctuated between 400 and 700 mbps.

Note, after both failures, it took 6-7 min to re-establish the wg connection. Remote logs indicated no internet connectivity at the remote end. It could ping the default gateway ip (192.168.1.254), but not the internet and no dns (server configured at 192.168.1.254) resolution.

Pings to 192.168.1.254 were successful indicating the bgw did not reboot. Also, bgw's uptime does not indicate a crash.

An additional iperf3 test performed, this time limiting upload bandwidth to 500 mbps (-b 500M) was successful. I then tried another one at full speed with same 30m failure.

I don't have much remote access to the bgw other than to ask the person running it to check certain things. Given the test to vps was successful suggests that att has some limits implemented on the bgw. I do recall some other replication tasks in the past that moved even more data (600gb) successfully, but that was scattered over multiple datasets and snapshots. I don't believe there was a single snapshot exceeding 100GB.

Is this a known limitation with att or is there some other factor at play?

Currently, the primary venue for tracking issues is GitLab. However, for many new users - myself included - the GitLab registration process has become a major roadblock. GitLab now frequently mandates a credit card verification or complex phone authentication just to create a free account, often flagging standard residential IP addresses or privacy-focused setups as "suspicious."

Why this matters:

• Reduced Quality Control: The users most likely to test software and report bugs are often privacy-conscious. If they are blocked from signing up without jumping through invasive hoops, TUXEDO loses valuable testing data.
• Barrier to Entry: For a Linux distribution, requiring financial information (even for verification) or forcing accounts just to file a bug report feels like an unnecessary paywall. It discourages users from contributing feedback entirely.

Could the team consider:

1. Alternative Issue Tracking: Is there a way to open a more accessible feedback channel (like a dedicated forum or a simplified ticketing system) that doesn’t require aggressive account verification?
2. Public Reporting: Could you enable guest issue creation or allow bug reporting via a moderated email alias so users don't have to create third-party accounts at all?

I love the hardware and the work TUXEDO is doing with the OS, but I want to make sure the process for helping improve that OS is as open as the software itself.

What consideration has been given to the write amplification that will result from using btrfs?

Ways to minimize?

My use case will be a whitebox desktop and/or laptop with consumer grade ssd (150-300 tbw). Generally like to extend the life of ssd's by using tmpfs for various cache and temp files.

Thoughts?

MSI z890 mag tomahawk wifi board
270K plus cpu
4x crucial CP2K16G64C32U5B 16gb ddr5 6400 MT/s

Installed to sata ssd

Sleep function appears to just blank monitor. Kill-a-watt meter shows idle power drop from ~30W to 15W, fans continue spinning.

Same test using ubuntu 26.04 and KDE neon (kernel 6.17.x) drops power to 0-2w (s3), fans stop, etc. Proper s3 sleep.

Suggestions on how to proceed to get tux to sleep properly?

https://os.tuxedocomputers.com/

TUXEDO-OS-202604211002.iso

Where can one read the change log on this?