Is the HW accelerated OpenSSL also enabled for the stable branch? Thanks!
Yes, it should be. I made the same changes for both.
My builds STABLE vs BETA are the same "configured" build, just against different branches.
1 Like
Tried disabling adaway and clearing DNS cache and brower cache and still failed. Just never updated that I guess. No biggie in my case. I run various firmware including DD-WRT, davidc502, and Gargoyle. Tried davidc502 latest, but he still has issue with his builds if you do a custom MAC on the WAN interface. Found that out when I tried it today.He is saying wait until his build with 4.9 kernel. Currently running my "safe harbor", ispysail's Gargoyle. Uses 10.3.2.0-20161011 wireless driver which does not cause me any issues and is the fastest 5GHz wireless in my iperf test.
New Builds:
3285-STABLE
3761-BETA
1 Like
As long as it's not a limitation of the driver (as all builds are using the same driver, which seems to currently under re-work), then as long as the branch it was built out of supports setting 160, then my builds will.
Thanks, skipping 3277.
Hi All, sorry for the stupid question, but how does the revision: 3285 correspond to git? I guess, more correctly, how is it that the number r3285 is generated? If I knew that I could probably get to the git revision.
Thanks
./scripts/getver.sh r3285
1a52d11d38ddb3cb511a55d01ce4b497322eb1ed
And you can go the other way as well.
1 Like
Thank you, very helpful.
1 Like
Hi can anyone give me any guidance on what to flash on a wrt1900acsv2 router. I recently bricked it flashing openwrt wrt1900acs. The label on on the router says the model number is wrt1900acs. But the FCC-ID is given as wrt1900acv2. I recovered the bricked partition by reflashing the OEM firnware FW_WRT1900ACSV2_2.0.1.177097_prod.img which is acsv2 specific. This appears to be working (at least it boots). I only see versions for acv1, acv2, and acs on the dropbox site.
Thanks
Roger
Flash this one from the Linksys UI: https://www.dropbox.com/home/lede/STABLE/r3285-STABLE?preview=lede-stable-17.01-snapshot-r3285-111cf1b-mvebu-linksys-wrt1900acs-squashfs-factory.img
Hello. First you need to install the ethtool package.
Then command should be:
ethtool -K eth1 tso off gso off gro off
eth1 is the WAN port (it used to be called eth0 in OpenWRT and older LEDE versions) which is what QoS uses.
Be sure to add it to the end of BOTH the start and boot functions in /etc/init.d/sqm (you need to scroll down to find boot)
and no, do not include the # sign
You can verify it worked by running the command after rebooting:
ethtool --show-offload eth1
Thanks for the info, been reading about and testing this, definitely helps performance!
@cybrnook You should consider including this. It definitely outperforms your default SQM/QoS settings (which still using all of your other default SQM settings such as piece_of_cake). The ethtool package would need to be included.
Including what, ethtool?
@cybrnook, including adding the line that disables TCO (tcp offloading) of QoS by adding that command to the sqm init.d script (which requires the ethtool package)
I confirmed these results myself.
Edit: Testing results in definite decrease in ping and increase in download speeds. Upload and buffer bloat are basically the same (learning towards very slightly better for both)
Well I am not setting any custom settings for SQM out of the box. By default SQM is not even enabled.
I don't argue that you may be seeing performance gains through SQM using this, I think it's best to leave it to the users discretion.
However, if there is demand for it, I would look into making it a default. Only reason I am hesitant, is SQM is a "package" and not part of the default build. So every time there is an update to the SQM package itself, I would need to re-validate my manual adjustment prior to release.
@cybrnook, I understand. I haven't changed any other settings for SQM. Try it for yourself though, assuming you are using SQM. Install ethtool and run the command
ethtool -K eth1 tso off gso off gro off
I saw an immediate significant decrease in ping and a slightly faster and much more stable downstream speeds.
Edit; A simple reboot will restore defaults.
Hey star! Do you think you can show a screenshot? I wanna make sure I am doing it right. And I'm using winscp to modify the sqm scripts to add the command.
So the issue with this approach is that the linux kernel will leave any already assembled giant (super) packet intact, so you needto disable GRO on all interfaces on your router (well those interfaces connected to the SoC), otherwise giants can creep in again. "tc -s qdisc" will have some information about packet sizes (maxpacket for fq_codel and max_len for cake, if these are >> 1500 you still have issues with super packets). That said, cake actually aims at segmenting supers into smaller segments based on predicted transmission time so ideally cake should not care...