Uploading now.......
Alright, new builds with 20170512 driver:
Stable: https://www.dropbox.com/sh/odt2nmquwgj1l9h/AAAUicyFlAnaPuRvgdDCnD-Ka?dl=0
Beta: https://www.dropbox.com/sh/egijrljt5le2asb/AADq5PLKLFmIP2bSTr6kHxYZa?dl=0
Enjoy 
3 Likes
Solved my latency issue by recompiling driver without AMSDU (packet merging), got same latency/ping as stock firmware. Info can be found on the link above.
Alright, new builds with 20170512 driver:
Sorry to be dim, but I have a WRT1900 ACS v2 , currently running LEDE, Lede leviathan III SNAPSHOT r3063-f2e6e11 / LuCI Master (git-17.020.82842-e1edb10) kernel 4.4.2
If I wanted to update that with this build, which should I choose?
I see a download for
lede-stable-17.01-snapshot-r3383-8011215-mvebu-linksys-wrt1900acv2-squashfs-sysupgrade.bin
So that one is ACV2
and also
lede-stable-17.01-snapshot-r3383-8011215-mvebu-linksys-wrt1900acs-squashfs-sysupgrade.bin
That one is for ACS
There is no file which is stating ACS v2, I really don't want to flash the wrong thing
Thanks
Use the stable branch, and you can flash the normal ACS image (works for v1 and v2).
Thank you.
I had some questions about SQM. I thought about creating a new thread, but I'm using a build from here, so I thought I would ask here. Let me know if I should split it off instead.
I am using LEDE-STABLE Reboot 17.01-SNAPSHOT r3383-8011215 / LuCI lede-17.01 branch (git-17.129.29271-6467df3) on a WRT1200AC. My product box says WRT1200ACv2, but LEDE doesn't specify. I used lede-stable-17.01-snapshot-r3383-8011215-mvebu-linksys-wrt1200ac-squashfs-factory.img to flash this build.
My current connection is through Comcast cable, I use a SB6183 modem to connect. My contract speed is 200/10, but I am overprovisioned to 240/10 when I measure it without SQM turned on. This has horrible latency of course, so I want to use QoS/SQM to bring latency down as much as possible while preserving as much speed as possible.
My main question is I am seeing a huge difference between SQM performance on wired vs wifi. Currently, with cake/piece_of_cake.qos:
- WIRED I am able to see great performance, DSLreports test shows me at 224down/9.3 up with ~16ms latency on down and ~5ms on up, which is amazing and around what I want.
- WIFI (5Ghz band), I see wild fluctuations, anywhere from 150 down to 195 down, with latency all over the shop, from 60 to 500ms, averaging at 300ms. Upload is pristine at 8.9 up with latency at 30ms with a very low spread. The upload isn't a problem here, but download is.
I have some link layer adaptations in my config from reading some threads on this forum, without which my wired speed would not go above ~150 down or so, is that adversely messing with the WIFI speeds? The upload has been steady whatever modifications I do. All other settings are at default values:
Interface eth1
Download: 240000
Upload: 9000
cake/piece_of_cake.qos
mpu 64 nat dual-dsthost
mpu 64 nat dual-srchost
Ethernet with overhead VDSL2: 18 per packet overhead (byte)
linklayer adapation to use: cake
Any ideas? Should I be using fq_codel instead? I was using SQM when my speed was lower (around 100 down/10up, and I was having fantastic performance with 110/9 using SQM/fq_codel). I'm not sure what has changed once speed got bumped to 200. The CPU on the WRT1200AC should be more than good enough, I'm tracking CPU usage and it's barely above 20percent usage on the peaks.
Wow, I was fiddling around with the various settings after typing all that out and I found a winner!
If I use cake/simplest_tbf (fq_codel/simplest_tbf also works, but cake gives me better perf with tighter latency spread), I am able to sustain:
- ~200 down/9up on WIFI with 30-100ms latency on down and 10-30ms on up
- ~210down/9up on WIRED with 10-40ms latency on down and 10-15ms on up
I read some stuff about simplest_TBF being better from hynman[1], but I never imagined it blowing away HTB like this. Anyone know the details around why this is happening?
[1]
Not really. But HTB (that "simple.qos" uses) seems to perform badly with some dual-core processor architectures with kernel 4.4 and lower. But there are no exact details, why that happens.
You might also test installing LEDE master snapshot that has kernel 4.9 for mvebu target. There have been some HTB improvements between 4.4 and 4.9.
See the difference:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/net/sched/sch_htb.c?h=linux-4.9.y
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/net/sched/sch_htb.c?h=linux-4.4.y
The last HTB commit in Linux 4.4 is backport of a commit in Feb 2016, while 4.9 has some 15 later commits.
One example of commit improving things for dual-core: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/net/sched/sch_htb.c?h=linux-4.9.y&id=a9efad8b24bd22616f6c749a6c029957dc76542b
Interesting, I stayed away from 4.9 builds since they were causing crashes for some people. So I just picked the 4.4 build since I thought it would be more stable.
Is there an expected change with HTB vs TBF? I'm very happy with the speeds and latency for now, and would be loathe to get a new kernel etc if it's not going to change the results that much. My priorities are lower latency while preserving as much bandwidth as possible (core use case is being able to play multiplayer games like overwatch while netflix/VOIP are happening on other devices).
If you look closely on the "4.9 crashes", the crashes are happening only for "Mamba" WRT1900ACv1, which has different processor (Armada XP) than rest of the series (Armada 385). Your wrt1200ac should be quite stable with 4.9.
Ok I'll give it a shot with 4.9. I'm also getting a 1900ac next week, so maybe I will try it on that and compare the two. Is there a collectd plugin for seeing the output from tc -s qdisc over time or something? Just so I can see how latency fluctuates when different connections are being used.
I am currently using a WRT1200AC v1 with latest beta / 4.9 Kernel. I use Cake/Piece_of_cake.qos and it works great on wired and wifi and scores A+ on DSL reports bufferbloat. I use TalkTalk (british ISP) fibre 73 down / 20 up. Speed tests without SQM gather around 71 down and 18 up with cake enabled I get 68 down and 16 up. perfect for my needs 
now just crossing my fingers that we see pi-hole integration 
I read some more about TBF vs HTB: http://lartc.org/howto/lartc.qdisc.classless.html. Essentially TBF is a very simple single class queuing mechanism, which doesn't really do much apart from set a bandwidth limit. I was getting flashbacks to my CS302 networking class while reading it HTB actually classifies different streams, which is what one would want. I'm still not sure what the interaction is between a qdisc like cake/fq_codel and the underlying TBF/HTB selector, or if they work together somehow, but I suspect I'll get down to reading about that soon enough.
Also when I check the simplest_tbf script, I realized that when I select it with cake, it will actually fall back to fq_codel:
case $QDISC in
cake*)
sqm_warn "Cake is not supported with this script; falling back to FQ-CoDel"
QDISC=fq_codel ;;
esac
So with that information in mind, I updated to 4.9 from davidc502's build. Once again, on cake/piece_of_cake.qos wired ethernet was totally fine seeing full speed (same as with 4.4). WIFI on the other hand, was the same dismal story with ridiculous latency up to 300ms with cake. I switched once again to simplest_tbf.qos, and saw very acceptable latency numbers with a sacrifice of some bandwith (around 190 down with ~30ms-70ms avg latency which is very respectable).
So there is definitely something weird happening with either HTB or cake over WIFI/5ghz band. And whatever TBF does is able to overcome that while preserving latency.
I tried to set up flent, but I only have a windows box to test with over 5ghz, so can't get pretty graphs that way to try and pinpoint the issues. Anyone have any ideas on what to tweak to make CAKE work over wifi? I get slightly lower latency with it, with slightly more bandwidth back so I would like to give it a shot still.
Just tried another run with fq_codel/simple.qos and got similar perf to simplest_tbf.qos. Switched back to cake/piece_of_cake.qos and got the terrible perf. So it looks like the issue is isolated to cake vs fq_codel on WIFI, with fq_codel winning.
Also, I noticed that fq_codel/simple.qos is much better at dealing with spikes in latency than fq_codel/simplest_tbf.qos. I think I will stick to fq_codel/simple.qos for now.
Interesting thing to note is that upload has always been very well handled by either algorithm. Wondering if something allows them all to be stable at lower bandwidths, but cake has a hard time dealing with larger bandwidth over wifi than fq_codel?
Hmm, not sure what's wrong on your end but I would start from scratch with a linksys stock firmware flash and factory flash of lede then try again.
I got my WRT1900ACv2, but it does not seem to be accepting the LEDE build. Once I flash it in the stock UI, it says to wait until reboot, and then it comes back right to the stock linksys firmware. Anything that can be done here? Is the device just unable to take openwrt/dd-wrt/LEDE firmware updates?
How bizarre, none of the LEDE or OPENWRT images worked, but when I tried the DDWRT image for the 1900ACv2 called factory-to-ddwrt.img, it came up immediately with DD-WRT. Now, to figure out how to get this to OpenWRT/LEDE...
I tend to use internet explorer or edge for the stock firmware for maximum compatibility and different cookies then access lede through chrome. http://davidc502sis.dynamic-dns.net/releases/lede-mvebu-linksys-wrt1900acv2-squashfs-factory.img
You know how to power cycle back to the stock firmware partition right? There are two partitions, like a dual boot/failsafe hopefully you still have it installed.
On DD-WRt, I enabled SSH and I did a ubootenv get boot_part which returns 1.
root@DD-WRT:~# ubootenv get boot_part
a_pEnv->crc = a32704e3
crc32 = a32704e3
1
I tried ubootenv set boot_part 2, and confirming with ubootenv get boot_part that it was in fact set to 2. When I reboot, it comes right back to boot_part 1 with DD-WRT!
root@DD-WRT:~# ubootenv set boot_part 2
a_pEnv->crc = a32704e3
crc32 = a32704e3
root@DD-WRT:~# ubootenv get boot_part
a_pEnv->crc = c895f7bf
crc32 = c895f7bf
2
root@DD-WRT:~# reboot
root@DD-WRT:~# Connection to 192.168.1.1 closed by remote host.
Connection to 192.168.1.1 closed.
There seems to be some weird timing bug or something is being set to read-only so boot_part values aren't taking effect. If I go to DD-WRT's flashing tab, and try to load up "ddwrt-linksys-wrt1900acv2-webflash.bin" which is supposed to flash linksys firmware on the other partition, it keeps coming back up with DD-WRT instead of stock firmware. And if I tick the "don't keep defaults" option when imaging, it wipes my DD-WRT config settings instead of clean installing to boot_part 2. So, I have no idea what the hell is going on. Here's my ubootenv list output (removed my specific mac ids etc) if that helps. I feel like I'm doing something wrong/typo-ing something simple here:
root@DD-WRT:~# ubootenv list
a_pEnv->crc = a32704e3
crc32 = a32704e3
CASset=max
MALLOC_len=5
MPmode=SMP
SMT-2D=-redacted-
altFwSize=0x2800000
altKernAddr=0x3200000
altKernSize=0x0600000
altnandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock7 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $altKernAddr $altKernSize; bootm $defaultLoadAddr
auto_recovery=yes
autoload=no
baudrate=115200
boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr
boot_part=1
boot_part_ready=3
bootargs_dflt=$console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel
bootargs_end=:-redacted-:255.255.255.0:Armada38x:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd=run nandboot
bootcmd_auto=stage_boot $boot_order
bootcmd_fdt=tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_boot=tftpboot 0x2000000 $image_name; setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_edit=tftpboot $fdtaddr $fdtfile; fdt addr $fdtaddr; setenv bootcmd $bootcmd_fdt_boot
bootcmd_lgcy=tftpboot 0x2000000 $image_name; setenv bootargs $bootargs_dflt; bootm 0x2000000;
bootdelay=0
cacheShare=no
console=console=ttyS0,115200
defaultLoadAddr=0x2000000
device_partition=0:1
disaMvPnp=no
eeeEnable=no
enaClockGating=no
enaCpuStream=no
enaFPU=yes
enaMonExt=no
enaWrAllo=no
eth1addr=-redacted-
eth1mtu=1500
eth2addr=-redacted-
eth2mtu=1500
eth3addr=-redacted-
eth3mtu=1500
ethact=egiga0
ethaddr=-redacted-
ethmtu=1500
ethprime=egiga0
fdt_addr=2040000
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-38x-modular.dtb
firmwareName=cobra.img
flash_alt_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $altKernAddr $altFwSize && nand write $defaultLoadAddr $altKernAddr $filesize
flash_pri_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand write $defaultLoadAddr $priKernAddr $filesize
ide_path=/
image_name=uImage
initrd_name=uInitrd
ipaddr=192.168.1.1
kernel_addr_r=2080000
lcd0_enable=0
lcd0_params=640x480-16@60
lcd_panel=0
loadaddr=0x02000000
loads_echo=0
mtddevname=uboot
mtddevnum=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:2048K(uboot)ro,256K(u_env),256K(s_env),1m@9m(devinfo),40m@10m(kernel),34m@16m(rootfs),40m@50m(alt_kernel),34m@56m(alt_rootfs),80m@10m(ubifs),-@90m(syscfg)
mvNetConfig=mv_net_config=4,(-redacted-,0:1:2:3),mtu=1500
mv_pon_addr=-redacted-
nandEcc=nfcConfig=4bitecc
nandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock5 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $priKernAddr $priKernSize; bootm $defaultLoadAddr
netbsd_en=no
netmask=255.255.255.0
netretry=no
partition=nand0,0
pcieTune=no
pexMode=RC
priFwSize=0x2800000
priKernAddr=0x0a00000
priKernSize=0x0600000
pxe_files_load=:default.arm-armadaxp-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
ramdisk_addr_r=2880000
rootpath=/srv/nfs/
sata_delay_reset=0
sata_dma_mode=yes
script_addr_r=3000000
script_name=boot.scr
serverip=192.168.1.254
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
update_both_images=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand erase $altKernAddr $altFwSize && nand write $defaultLoadAddr $priKernAddr $filesize && nand write $defaultLoadAddr $altKernAddr $filesize
usb0Mode=host
usbActive=0
usbType=2
vxworks_en=no
yuk_ethaddr=-redacted-