I think you misread my post. Instead of running iperf3 directly on the R7800 in client mode I ran it on my laptop connected to the R7800 via ethernet. I'm seeing low speeds while connecting to the same server as in the previous tests. Especially strange is the nosedive the speeds take towards the end of the last run.
I also ran the same test over WiFi with much better speeds and performance doesn't degrade as the test progresses:
Latest master here with 4.14.51 patch applied, there must be some congestion on the link between me and ping.online.net, but the french iperf3 server I sometimes use is showing rock steady - so it looks like 4.14.51 definitely fixes it.
Running single threaded over lan is a bit slower, and it would be good to get to the bottom of that, but a parallel test does still max out from LAN side at 384Mbps.
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt SNAPSHOT, r7314-c4aadbdaf6
-----------------------------------------------------
root@OpenWrt:~# cat /proc/version
Linux version 4.14.50 (perus@ub1804) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r6781-2c192b6916)) #0 SMP Mon Jun 25 14:53:31 2018
[ 1.048426] 9 fixed-partitions partitions found on MTD device qcom_nand.0
[ 1.055861] Creating 9 MTD partitions on "qcom_nand.0":
[ 1.062716] 0x000000000000-0x000000c80000 : "qcadata"
[ 1.089741] 0x000000c80000-0x000001180000 : "APPSBL"
[ 1.098876] 0x000001180000-0x000001200000 : "APPSBLENV"
[ 1.100482] 0x000001200000-0x000001340000 : "art"
[ 1.105764] 0x000001340000-0x000001480000 : "artbak"
[ 1.110595] 0x000001480000-0x000001880000 : "kernel"
[ 1.120242] 0x000001880000-0x000007900000 : "ubi"
[ 1.282232] 0x000007900000-0x000008000000 : "reserve"
[ 1.294766] 0x000001480000-0x000007900000 : "firmware"
[ 1.465539] no rootfs found after FIT image in "firmware"
[ 2.421008] 2 uimage-fw partitions found on MTD device firmware
[ 2.421078] 0x000001480000-0x000001880000 : "kernel"
[ 2.434540] 0x000001880000-0x000007900000 : "ubi"
My hunch is that it is some automatic new logic that tries to split the "firmware" again, although the components (kernel, ubi) are already visible in DTS as themselves. Likely harmless.
Possibly caused by mtd changes in mid-May or something in upstream kernel.
Looks like the double partitions may actually cause trouble...
Log from serial console when tyring to sysupgrade from r7314:
Sending KILL to remaining processes ...
Switching to ramdisk...
[ 153.290095] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" stops
[ 153.398774] UBIFS (ubi0:1): un-mount UBI device 0
Performing system upgrade...
Unlocking kernel ...
Writing from <stdin> to kernel ...
ubiattach: error!: strtoul: unable to parse the number '6 mtd10'
ubiattach: error!: bad MTD device number: "6 mtd10"
ubiformat: error!: more then one MTD device specified (use -h for help)
ubiattach: error!: strtoul: unable to parse the number '6 mtd10'
ubiattach: error!: bad MTD device number: "6 mtd10"
libubi: error!: "/dev/" is not a character device
ubimkvol: error!: error while probing "/dev/"
error 22 (Invalid argument)
cannot create rootfs volume
libubi: error!: "/dev/" is not a character device
ubiupdatevol: error!: error while probing "/dev/"
error 22 (Invalid argument)
tar: write error: Broken pipe
mount: mounting /dev/ on /tmp/new_root failed: Invalid argument
mounting ubifs failed
sysupgrade successful
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource busy
[ 154.913143] reboot: Restarting system
Looks like the ubiattach gets "6mtd10" as argument, while it should get "6".
Likely there is "mtd6 mtd10" initially, and the first mtd gets stripped away, but the second word is unexpected. That is generated by some query to the mtd structure.
Question:
Is the "double MTD partitions seen in other builds than my build?" There should be nothing special related to mtd in my master build, so I assume that the same phenomenom should appear also in the buildbot snapshot and other recent master builds.
My "large flash" patch was backported yesterday to 18.06, so both master and 18.06 now use also the old "netgear" partition, so it will be easier to jump between master and 18.06 builds in future. Coming from 17.01 will require TFTP in any case.
Note that 18.06.0-rc1 has been compiled with the old traditional small flash space, so upgrading from that will require TFTP. But as sysupgrading from 18.06.0-rc1 is semi-broken in any case (due to the double ubi partition detection with ipq806x Netgear routers), TFTP will likely be needed in any case...
My patch for fixing ipq806x partition detection (remove "firmware" and thus the double ubi & kernel from mtd) was also merged yesterday to master and 18.06, so hopefully both are back on the normal sysupgrade path today.
Like said earlier, sysupgrading from master and 18.06 builds of 19-27 June (including rc1) for R7800 may be impossible. With 18.06 I got sysupgrade to succeed on the second try for some reason, but with master I always needed TFTP. Be prepared for that. (The bug described in FS#1617 affected at least R7800, R7500, R7500v2 and D7800, which all should be fixed now.)