I have not tried it yet, but based on earlier discussion in TCP BBR support it sounds like it brings most benefits for the bulk traffic originators (like youtube servers etc.). I am not sure if it would bring significant benefits to home routers.
It should be a common effort I suppose.
A while ago I've been testing different congestion algorithms in my local isp environment and I've had different results even on a client side (I've been testing with downloading Linux images with torrent) opposing to common view that it's a server-side mechanism.
At that time YeAH gave me the best result.
I've repeated tests and BBR tend to give me same results.
But in any case it will surely be useful for WiFi client devices with low signal while using online streaming services: video, voip and such.
SixXS will be sunset in H1 2017. All services will be turned down on 2017-06-06, after which the SixXS project will be retired. Users will no longer be able to use their IPv6 tunnels or subnets after this date, and are required to obtain IPv6 connectivity elsewhere, primarily with their Internet service provider.[/quote]
If you are still using aiccu-based SixXS 6in4 tunnels, start looking for alternatives...
I am not sure if I have ever tried to flash back to OEM stock firmware with R7800 but it should work ok with the TFTP recovery mode.
This is pure guess, but if you have not set a fixed IP address to your PC from 192.168.1.X subnet, it is quite possible that the DHCP client in your PC tries to renew address during flash, fails, and changes IP address in the middle of a flash to a link-local 169.254.x.x address and that causes TFTP to fail. Windows PCs are especially eager to change IP rather quickly. (I have experienced that several times when I have been lazy with R7800 or WNDR3700 and have not changed to a fixed IP before the TFTP flash. then the TFTP transfer stops in the middle.)
I have used the TFTP2 GUI client, which makes it rather easy to prepare the TFTP transfer in advance before triggering the recovery mode.
I have flashed back to stock the way hnyman mentioned several times from my MacBook. Usually a smooth and simple process once you set a static IP and ensure your firmware is in the correct spot. Firmware transfers over in about 4.7 seconds, then restarts into the Netgear page.
Yes i did set a static IP address. But it doesnt work.
I tried to install it through putty with the command sysupgrade -n -F. This results in a bootloop. I could fix the bootloop by flashing LEDE over TFTP, but the stock one breaks at 75% everytime.
[quote="Spots, post:95, topic:316"]
I tried to install it through putty with the command sysupgrade -n -F. This results in a bootloop.[/quote]
Sure. In most devices you can't install the OEM image via sysupgrade. That holds true to R7800, too. (The few devices where you can do that (like wrt1900ac series), are exceptions,)
[quote="Spots, post:95, topic:316"]
I could fix the bootloop by flashing LEDE over TFTP, but the stock one breaks at 75% everytime.
[/quote]Sounds strange as the the whole TFTP functionality is in the OEM bootloader (u-boot) that is not modified by LEDE or Openwrt. LEDE (or Openwrt) firmware has no role in the TFTP recovery flash. So, OEM firmware images should be compatible with OEM TFTP flash routine...
Yes. The changes are pretty much about tweaking some LEDs, config settings etc. to match R7800 better. Full diffs are available in the download directory as patch files, just like I say on the first message of this thread: