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
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 100baseT/Half 100baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Port: Twisted Pair
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
Do a search on here, seems people have been getting this error for years.
Not needed, losetup is a device specific package
The error you're describing can only happen during sysupgrade from an initramfs image from a multi-device build (like OpenWrt official builds)
This is due a limitation of the build system that doesn't take device-specific package into account.
Either build your own QNAP image (single device build includes device specific packages) or install losetup in the running initramfs image.
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.
Just to clarify.
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.
And the device is official supported.
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.
Is EXT4 kmod required as well?
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
Yes, ext4 is used for the loop device.
In addition e2fsprogs would be also required to format the loop device during sysupgrade.
So we would need losetup, kmod-ext4 and e2fsprogs as target default packages.
The good thing is, we already have 2 emmc based devices in ipq807x who would benefit from that change.
Have you by chance measured the size difference?
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:
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:
That is not openwrt in the video -> not relevant here.
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.