I bought a Fritzbox 4060 to test 2.5Gbps with my actual FTTH plan (2.5Gbps Down /1Gbps Up) and I am able to reach something near 2.5Gbps with the Fritzbox while I cannot reach that speed with the QNAP.
I see that the negotiated speed is 2.5Gbps on the WAN port (10g-1)
root@OpenWrt:~# ethtool 10g-1
Settings for 10g-1:
Supported ports: [ ]
Supported link modes: 100baseT/Half 100baseT/Full
1000baseT/Full
10000baseT/Full
1000baseKX/Full
10000baseKX4/Full
10000baseKR/Full
2500baseT/Full
5000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 100baseT/Half 100baseT/Full
1000baseT/Full
10000baseT/Full
1000baseKX/Full
10000baseKX4/Full
10000baseKR/Full
2500baseT/Full
5000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 8
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Link detected: yes
And also I can see the same from the ONT (of course)
I'm getting an error here on the sysupgrade with squashfs,
[ 224.378788] stage2 (2800): drop_caches: 3
Wed Mar 22 00:11:29 UTC 2023 upgrade: Switching to ramdisk...
Wed Mar 22 00:11:30 UTC 2023 upgrade: Performing system upgrade...
/lib/upgrade/do_stage2: line 38: losetup: not found
Failed to detach all loop devices. Skip this try.
[ 225.961601] reboot: Restarting system
Sure, there are lots of ways to skin the cat but that's a horrible user-experience. If single-device builds include device-specific packages, why can't the official build system make a single device build for ipq807w? What percentage of OpenWRT users have made their own build?
And, what's the path to being supported here? Will this device be officially supported, and if so -- will users have to make their own build?
If the device in included in the OpenWrt code, then it's officially supported.
If there is a problem with OFFICIAL OpenWrt builds, open an issue to see what can be done.
The mentioned limitation only applies to the initramfs-image that is used during the initial install. And I already supplied 2 workarounds how to deal with it during the install.
The sysupgrade image itself contains all the device-specific packages, that means after a successfull install sysupgrade works fine.
I ended up building an image from Bitthief and re-flashing all 3 QNAP devices (took longer than expected), due to learning curve, work and initially 2 devices would not Sysupgrade but got their in the end.
I have both HW and SW offloading enabled and while i don't see a CPU being maxed out, I've not seen a major improvement in throughput.
@rmandrad you mentioned a bunch of tweaks / settings that have helped you, can you share what you have done on top please.
What is now the best way to test ? IPERF3 is single thread are there other test I should try ?
The issue is the initramfs image doesn't have the sufficient tooling to do the flash. I've never had that experience with other OpenWRT "supported" images. I always assumed support meant that there was a documented path to operation using built images, not that I could build them myself. But I could simply be wrong on that, and I've just never used such a device until now.
Cause, if not then I would just simply ship losetup as the target default package as there are more and more boards requiring it for installation and we are not dealing with a target that has low storage
So we're arguing about <1mb on transient image loaded into flash, used on a device with 1 GB of flash. I love the internets.
But let's ignore the absurdity for a second. Why doesn't the openwrt build system use the same build path to build an initramfs image that a Makefile would use to target a single image? In other words, what is the advantage of having two ways to make the initramfs image? If we can just use Make and get a working image, what is the advantage to maintaining the other way to build an initramfs image that doesn't account for device specific dependencies?
It's not just 1MB on an image loaded into RAM, but also 1MB of packages that would be shipped but never used by the 32MB NOR device that we support as well, that is the issue.
There are no 2 ways to build an initramfs, but there is a limitation when you are building with: CONFIG_TARGET_MULTI_PROFILE and CONFIG_TARGET_PER_DEVICE_ROOTFS
then only packages that are selected with * so built-in are included as there is only one kernel with initramfs being built for the whole subtarget thus DEVICE_PACKAGES is ignored.
Now, everybody is free to try and rework the build system to allow building kernel+initramfs per each device.
I have no experience with firmware development, so I will just point out the following video (and its indicated resources) that perhaps someone already knew. If not, I hope it will be useful:
Excuse me, but if you go to minute 9:35 after he has done the whole procedure, the interface of the installed firmware is that of OpenWRT (and it is also clearly indicated). But maybe I'm missing something.
what that guy is doing is fundamentally different from what the official docs and everyone here is doing. he is connecting to ssh directly without ever loading an initramfs image. then he's manually flashing the rootfs and kernel. cool. then he flashes the 10gb firmware. this may work with openwrt, i would only feel comfortable if after his kernel and rootfs flash, you could flash over them with a new nightly snapshot.
