[Fork] 374.43 LTS Beta including new rev AC68U routers (V27BI)

[fink.nottle]

Yes, the plan is that there will be one AC68U version going forward that supports all versions and with a newer wireless driver (the wireless driver is tied to the SDK). And unfortunately, this is going to require a factory default reset.

But, there is one thing you may want to check. Most linux distros ship with a very outdated regulation db that can kill throughput. I had problems with my Intel 7260AC card on Mint, and others had problems with various Centrino N cards. See this thread...
https://www.snbforums.com/threads/rt-ac66w-slow-linuxmint-ubuntu-wireless-n-connection-solved.32760/

My regulatory db file on xenial is pretty recent. It's from 2015. I did try with a factory reset too, and rebooted my laptop as well. The throughput was somewhat better (in the 70 Mbps range), but the original firmware still performs better. I can do more repeated tests and average out the results to get a better sense of the performance hit. Is there any additional debugging that can be done ?

 

[john9527]

My regulatory db file on xenial is pretty recent. It's from 2015. I did try with a factory reset too, and rebooted my laptop as well. The throughput was somewhat better (in the 70 Mbps range), but the original firmware still performs better. I can do more repeated tests and average out the results to get a better sense of the performance hit. Is there any additional debugging that can be done ?

Unfortunately, none that I know of. The wireless drivers are all closed source.

What band are you testing?

Only things I can recommend to check/try...
Airtime Fairness is disabled (should be disabled by default)
Disable WMM APSD
Disable TX Bursting
Disable all the Beam Forming options except for Explict on the 5GHx band.

 

[RocketJSquirrel]

Yes, the plan is that there will be one AC68U version going forward that supports all versions and with a newer wireless driver (the wireless driver is tied to the SDK).

I thought part of the motivation for the original fork was to keep the older wireless drivers because they were faster (or better in some way) than the newer ones. Was I mistaken?

 

[john9527]

I thought part of the motivation for the original fork was to keep the older wireless drivers because they were faster (or better in some way) than the newer ones. Was I mistaken?

True, especially for the N66 (which hasn't changed).

But, we're now at crossroads on the AC68 and it's newer revs. To support the newer revs (the most common request I've received) you need a new SDK....which means new wireless drivers, no choice. There's only been the one report of someone seeing a performance impact. Most (including myself) are seeing equal or a little bit better performance on the original rev AC68's.

 

[RMerlin]

True, especially for the N66 (which hasn't changed).

But, we're now at crossroads on the AC68 and it's newer revs. To support the newer revs (the most common request I've received) you need a new SDK....which means new wireless drivers, no choice. There's only been the one report of someone seeing a performance impact. Most (including myself) are seeing equal or a little bit better performance on the original rev AC68's.

Agreed. The wireless driver issue mostly affected the RT-N66U (especially after the move from SDK5 to SDK6), maybe to a lesser extent the RT-AC66U (which was a native SDK 6.34 device). I wouldn't expect any drop in performance from native SDK 6.37 devices like the AC56/AC68.

 

[RocketJSquirrel]

Thanks John & RMerlin for the responses to my driver question.

Given that the John fork will end up with the same wireless drivers as the Merlin version, what is my motivation for staying with the John fork vs. Merlin on my older AC68U?

 

[RMerlin]

Thanks John & RMerlin for the responses to my driver question.

Given that the John fork will end up with the same wireless drivers as the Merlin version, what is my motivation for staying with the John fork vs. Merlin on my older AC68U?

Wireless is just one aspect of the firmware. Some people have better results with John's IPv6 stack than the newer one Asus and I are using. Also some people who don't use any of AiProtection's features will prefer not having it present at all in the firmware.

And John does have some unique features over my firmware. So people should look at them as alternatives to one another. Same with Tomato where some people prefer Toastman's over Shibby's, even if Toastman carries fewer features. Different development focus.

 

[ColinTaylor]

con: No Adaptive QoS
pro: Traditional QoS works well, simple to overclock

 

[fink.nottle]

True, especially for the N66 (which hasn't changed).

But, we're now at crossroads on the AC68 and it's newer revs. To support the newer revs (the most common request I've received) you need a new SDK....which means new wireless drivers, no choice. There's only been the one report of someone seeing a performance impact. Most (including myself) are seeing equal or a little bit better performance on the original rev AC68's.

I'm quite convinced that this is entirely a client side oddity, and the internet is replete with performance issues on these wifi cards and iwlwifi drivers. I did try windows on the same laptop, and it did fine. I will try out the other settings you mentioned, and report back. Other than that, I can only suggest someone trying out a similar Centrino wifi card on linux with this firmware.

 

[jrmwvu04]

You're not using AB-Solution where I prevent pixelserv-tls from starting before the virtual IP is up.

So I was thinking about this some more, and I decided if I'm editing the launch config for pixelserv to check if the virtual interface is up, why not instead just create the virtual interface at that point. Which I did, and it has been working. Is there any reason not to do it this way?

 

[thelonelycoder]

So I was thinking about this some more, and I decided if I'm editing the launch config for pixelserv to check if the virtual interface is up, why not instead just create the virtual interface at that point. Which I did, and it has been working. Is there any reason not to do it this way?

If it works, it works.
For this case there is not really a need to place it into wan-start as this particular action is not sevice dependent.
Placing the virtual interface code into the S80pixelserv file will work as by the time the file is run, most of the router services are up anyway.
Let me know how it goes.

 

[john9527]

So I was thinking about this some more, and I decided if I'm editing the launch config for pixelserv to check if the virtual interface is up, why not instead just create the virtual interface at that point. Which I did, and it has been working. Is there any reason not to do it this way?

Probably not a problem.....just from a personal preference, I'd probably want to have the physical interfaces up first before adding any virtual interfaces. But that's just me.

 

[thelonelycoder]

Probably not a problem.....just from a personal preference, I'd probably want to have the physical interfaces up first before adding any virtual interfaces. But that's just me.

I would imagine that most services are up by the time USB devices are mounted, they usually come very late during boot up.
But I'm with you: Place your user scripts where they belong.

 

[Builder71]

True, especially for the N66 (which hasn't changed).

But, we're now at crossroads on the AC68 and it's newer revs. To support the newer revs (the most common request I've received) you need a new SDK....which means new wireless drivers, no choice. There's only been the one report of someone seeing a performance impact. Most (including myself) are seeing equal or a little bit better performance on the original rev AC68's.

So the RT-N66U will stay on the old WiFi drivers? (V27 and onwards.)

 

[john9527]

So the RT-N66U will stay on the old WiFi drivers? (V27 and onwards.)

Yes sir.....no changes.

 

[Builder71]

Yes sir.....no changes.

That's a relief!
SDK6 WiFi drivers are a big pile of cr@p on the RT-N66U.

 

[john9527]

Closing this thread with the final release of V27! Thanks to all those who provided feedback!

@RMerlin - Please 'unsticky' and lock. Thanks.

 

[RMerlin]

Unsticked, and also closed it. Just PM me if you ever need it reopened.