改善WiFi同频干扰,提高并发用户数量,SuperWRT v0.2版本全面提升

在常见的WiFi使用场景中,有几个困扰用户比较多的问题:

  • 周边有很多WiFi设备时,造成同频干扰;
  • 当用户数量增大时,整体流量下限明显,卡顿增加;
  • 当距离设备较远时,能连上,但时常卡顿。

即将发布的SuperWRT v0.2版本,正式合入我们的开发团队潜心研发WiFi优化技术,能够明显改善上述问题。

今天我们以Ruckus的设备作为对比对象来进行一下测试,测试在普通设备上使用SuperWRT系统,将如何改善设备的WiFi性能。之所以选用Ruckus作为对比对象,是因为其WiFi设备中实现了智能天线技术,在WiFi设备厂商中还是十分优秀的,大量用于高端酒店等重要场所,在行业内有很好的口碑。

我们选用了Ruckus的R300作为对比对象,因为其性价比比较高,与其它型号在其官方对比测试中差距也不是很大。(也是因为别的型号太贵了,有点承担不起……)

下面是Ruckus官网中提供的它与其它厂家设备在第三方CARNet的测试报告,我们筛除11ac设备的测试结果(因为今天测试的都是11n设备),主要看一下36用户和60用户的数据。(这里测出的吞吐量比我们即将进行的测试要大,可能因为是用了双频,或开启了HT40。另外要注意,吞吐量更高的R700及7982是3×3的设备。)

Ruckus_CARNet_all
Ruckus_CARNet_36users2
Ruckus_CARNet_60users
Ruckus_CARNet_36users

可以看到Ruckus R300的测试结果还是非常不错的。

我们用来运行SuperWRT的设备为水星的MAC1200r。之所以选择这个设备,是因为它与R300在2.4G使用了同样的芯片,都是2×2设备,方便横向对比。当然,其射频上使用PA和LNA,及其它用料与R300还是没法比的。另外一个原因就是便宜,在JD上只有109元,还是11AC双频设备。(貌似新硬件版本换芯片了,我本次测试的还是AR9344版本。)

MAC1200r_jd_109

今天测试的所有设备都只测试2.4G,使用20MHz频宽,工作在3信道。这里使用20MHz频宽测试,更符合实际使用场景,工作在3信道可以让周边的其它1和6信道的AP对我们造成一定干扰。WiFi设备测试,重要的是在相同环境下进行对比测试,相同设备在不同的环境的测试结果可能会差别很大。所以,今天以我们所在环境进行对比,结果不代表其最高水平或其它测试环境中可达到的表现。

吞吐量使用IxChariot进行测试,每个设备测试三次,每次测试时间为3分钟。使用默认的Through脚本进行测试,IxChariot版本为6.7。

测试时,我们将设备都调整到了最佳的摆放方向。可以参考下面照片中饮水机上方的设备摆放。

IMG_1731
IMG_1733

在整个测试过程中,我用手机录制了视频,便于想了解详细测试过程的人观看。

测试的所有结果文件也可在网站的下载页面下载:测试结果

30用户并发测试

测试设备为 :

  • 30台Amazon Fire HD7(其WiFi芯片为:Broadcom BCM43239(B50 5222 12507A9A10)(11n 2×2))

IMG_1730

下面是30用户的测试结果:

第一次 第二次 第三次 平均
设备 吞吐量(Mbps) 延迟(s) 吞吐量(Mbps) 延迟(s) 吞吐量(Mbps) 延迟(s) 吞吐量(Mbps) 延迟(s)
Ruckus R300 46.279 2.667 46.34 2.643 46.955 2.634 46.525 2.648
MAC1200r SuperWRT 54.706 2.253 54.414 2.282 54.393 2.284 54.504 2.273
MAC1200r openWRT 28.382 4.283 30.881 3.933 31.201 4.08 30.155 4.099
MAC1200r 原厂 44.449 2.445 50.002 2.893 49.536 3 47.996 2.779
mt7620芯片设备 33.614 4.347 30.989 4.128 32.196 4.586 32.266 4.354

60用户并发测试

测试设备为 :

  • 8台Thinkpad x200:Intel(R) WiFi Link 5300 AGN (11n 3×3)
  • 8个Netgear WNDA3100v2:BCM4323KFBG (11n 2×2)
  • 8个Mercury MW150US:RTL8188CUS(11n 1×1)
  • 6个Mercury MW300UM:RTL8192CU(11n 2×2)
  • 30台Amazon Fire HD7:Broadcom BCM43239(B50 5222 12507A9A10)(11n 2×2)

注:其中一共8台笔记本,每台笔记本自带一个无线网卡,再连接2-3个USB无线网卡。Netgear由于驱动原因挂在虚拟机中。笔记本上的每个网卡配置单独的IP地址。

IMG_1765
IMG_1767

下面是60用户的测试结果:

第一次 第二次 第三次 平均 备注
设备 吞吐量(Mbps) 延迟(s) 吞吐量(Mbps) 延迟(s) 吞吐量(Mbps) 延迟(s) 吞吐量(Mbps) 延迟(s)
Ruckus R300 34.516 7.597 35.701 7.268 36.533 7.252 35.583 7.372
MAC1200r SuperWRT 42.088 6.163 41.636 6.506 38.835 6.866 40.853 6.512
MAC1200r openWRT 18.52 22.481 23.258 21.420 (1)
MAC1200r 原厂 33.738 35.286 12.326 27.117 (1)
mt7620芯片设备 23.239 22.078 22.659 (1)
Comlli AC750
(高功率及接收灵敏度设备)
31.263 8.773 28.432 8.488 29.848 8.631 (2)

注:(1)丢包及延迟严重,无法完成打流,几乎刚打流就会出错。数据为打流中断时的结果。(具体过程可以观看测试过程视频。)

mac1200r_60_2

注:(2)打流完前出错。打流期间数据统计缓慢。

ac750_60_2

总结

下面对两次的对比测试结果进行一下总结说明。

30用户测试时,使用同类型终端,且内置WiFi芯片比较好,测试时的设备也相对比较近,算比较好的信道环境。在这种环境下,高通芯片原厂的SDK有很好的表现(因为MAC1200r在原厂的SDK的基础上开发的,推测应该对无线驱动改的不多),Ruckus吞吐量不算很高,但很稳定。SuperWRT的表现是最好,有很好的吞吐量和延迟。openWRT使用ath9k相对比较弱一些。使用mt7620芯片的设备表现也一般。

60用户测试时,笔记本使用的USB无线网卡的天线较差,信号相对不是很好。同时,60用户测试时,混合了不同的终端,及不同角度,抢占更加多,信道更加繁忙,更能模拟出在真实使用的环境。所以,在60用户测试中,只有Ruckus和SuperWRT依然稳定。其它的设备都出现打流中断的问题。这种问题,我们可以理解为在干扰及信道繁忙时的掉包,实际使用中就是卡顿的问题,比如刷个图片卡在一半。所以,虽然Ruckus设备在30用户时总流量不及原厂的SDK,但在更复杂环境时,看出了其出色的稳定性。SuperWRT的无线优化,使一个普通的水星设备,也达到了非常优秀的无线性能,也说明了我们优化的实力。

注意:SuperWRT的高并发特性是需要许可证才能使用的功能,您也可以打开测试选项先测试效果(打开测试选项后,设备15分钟后会自动重启)。

SuperWRT第三个测试版本发布

SuperWRT在沉默了近四个月时间后,迎来了自开发以来最重要的版本发布。

如果说,之前SuperWRT还仅是提供一些基本功能的话,这次发布的版本,更充分体现出了SuperWRT系统的特点。

SuperWRT在架构设计上更加完整,更易于集成新功能,有更加友好的外部API接口。所以,本次发布中集中了多用户权限,及远程管理等功能。

这次的新版本主要增加了以下功能:

  1. 增加了对远程管理服务器的支持。配套的Opwifi Easy版本服务器已经可以测试(虽然目前还很简陋,前期实现的功能都为了验证与设备的对接)。
  2. 加入访客网络功能,访客网络可与本地网络完全隔离,可限速。
  3. 加入了Webportal功能,可支持本地方式和远程方式,目前仅可以绑定在访客网络上使用。webportal远程方式支持IP和域名白名单。可配合Opwifi Easy版本使用,在远程方式中,支持下发流量限速、限时、限速功能。
  4. 支持工作在单独的AP模式下。
  5. 可配置为瘦AP模式,进行集中管理。
  6. 在AP模式下,加入了对VLAN的支持。
  7. 配套uboot支持PPPoE拨号、DHCP和静态地址方式进行WAN连接。
  8. 配套uboot加入HTTP文件下载功能。在升级失败后,或无法启动时,通过WAN连接自动下载版本恢复系统。
  9. 加入日志式写配置方式,在写配置时出现断电或异常,自动回退旧配置。
  10. 不同级别用户权限管理。目前管理员帐号可控制所有功能,用户帐号仅可查看状态和配置WAN相关设置。(如:可用于运营,仅给客户用户帐号,维护人员才有管理帐号)
  11. 正式加入SSID广告功能,可选择不打开SuperWRT的SSID广告,不打开时用户数量限制在16个。将广告SSID以z开头并加密,以保证排在列表最后,最大限度不打扰用户。(如支持我们,请打开SSID广告,谢谢)
  12. 增加了新版本提醒。
  13. 优化了API的处理效率及内存占用。API返回时间减少60%。
  14. 加入启动时版本完整性校验。
  15. 一些小的功能改进:
    1. 加入静态DNS配置功能。
    2. 加入ar8327的WAN与LAN口通过VLAN方式支持。
    3. 网络不通时,自动弹出网页诊断页。
    4. 优化PPPoE稳定性。
    5. 配套uboot加入按Flash大小提供默认分区格式。
    6. 优化了uboot下文件上传速度,及修复一些Bug。
    7. 加入无线的信道和功率调整功能。
    8. 增加定时重启功能。
    9. 优化网页兼容性和一些小提示的友好性。
  16. 本次加增了用户密码的安全性。所以,旧版本升级后用户不可以登录,需要清空配置。

用于管理设备的OpWiFi Easy版本使用php编写,使用Laravel框架,
为完全开源,可在GitHub中下载。

https://github.com/superwrt/opwifi-easy

在uboot中增加PPPoE支持

经过了一段时间的开发,终于在uboot中支持PPPoE了。

传统的uboot中是不支持PPPoE的,那为什么SuperWRT在uboot中增加PPPoE支持呢?主要是为了解决uboot的连接广域网问题。可以通过uboot进行WAN的多种方式连接(静态地址、DHCP、PPPoE),从而实现在uboot中自动恢复有错误的系统,实现真正的设备自愈。即实现uboot可以自动恢复设备Firmware。

我们知道,现在很多网络设备可以进行集中管理,需要进行远程的版本维护。或者,有些设备在用户确认后,自动下载版本,而无需用户手动上传。这些升级方式都会存在一个问题,就是如果升级失败了怎么办?这种失败可能会有很多原因:升级过程中设备断电,未测试到的Bug,甚至硬件问题引起的。即使仅有万分之一的概率,对用户来说,也是不可以接受的。目前解决这个问题比较常见的一种方式是,使用双Firmware系统,一个系统启动失败后,自动切换到另一个,但这种方式的代价就是成本比较高,因为双Firmware更占存储空间。

SuperWRT需要保证用户的设备使用的稳定性和可靠性,同时又尽量不对硬件有过高要求,或增加成本。所以,我们选择了在uboot中增加广域网连接功能。这样,在系统升级失败后,uboot会检测到系统不完整,然后,自动使用设备中的广域网配置,去服务器上载版本并升级。

当然,DHCP及静态地址方式也是支持的。

SuperWRT的开发目标说明

SuperWRT的第二个版本发布了,本次主要带来的是自助适配设备功能。该功能算是围绕SuperWRT开发目标的一个核心功能了。所以。这里介绍一下Terra开始SuperWRT中的一些思考逻辑。

SuperWRT的开发目标就是做一个更稳定的Wi-Fi路由器系统。所以,SuperWRT不追求眼花缭乱的功能,因为功能多了难免Bug也多,SuperWRT只会开发作为Wi-Fi路由器常需要的功能。当然,SuperWRT的功能也并不是只局限于以前看到最普通的家用路由功能,我们还会增加一些我们认为重要的功能。比如:更强大的限速功能,我们认为对用户来说很重要。

SuperWRT的另一个开发逻辑是,我们认为需要稳定路由器的用户,是拿路由器来用的,而不是整天折腾的。路由器作为一个上网设备,就是保证有其它设备可以有流畅的上网体验的,最好不要烦扰用户,甚至能让用户忘了它的存在。所以,我们配置力求简单。比如:限速时可以使用的智能流量整形功能,其实我们在里面做了很多逻辑,对于不同的场景来保证QoS的策略最优,而且用适应多WAN队列人情况,但用户只要打开就好了,用户烦扰每个具体项是做什么的。我们也不会强制用户必须装什么软件才能控制设备。

同样是上面的逻辑。我们开发配套uboot的WEB方式只支持上传固件,而不支持上传ART什么的。因为我们认为,需要开发人都可以接串口,开发人将设备适配好使,对于需要刷机的用户来说,你只要拿固件来刷就好了。每个设备的ART信息是针对该设备射频的,使用其它设备的ART可能你看信号强度高了,但信号质量不一定好。同样,不重复的原机MAC,可以用助于手机的室内定位。所以,我们鼓励用户使用原机的ART信息和MAC地址信息,开发的人将原厂的分区分析出来,然后做出的适配的uboot,这样刷机的人只要刷入这个uboot,系统启动后使用的ART信息和MAC地址就是对的。

SuperWRT另一个重点优化的是WLAN功能。Terra也开发过了好多年WLAN底层,对如何优化WLAN的体验有一些理解。我们认为目前大多数的设备在现有的硬件基础上,还是有一些优化空间的。这也将是SuperWRT的一个核心特点。所以,我们先开发Qualcomm Atheros芯片的设备,因为它们的芯片相对资料比较丰富,Radio和MAC的性能还不错。MTK Ralink的芯片需要优化还是相对多一些,而Boradcom的芯片做的真心不错,就是资料太少,所以,这些芯片都不会第一批支持。在没有优化到我们满意的程度时,是不会发布一个新的芯片的支持的。

当然目前SuperWRT还在开发测试阶段,也仅仅发布了两个测试版本,还有一些Bug导致不稳定。但我们会尽力解决这些问题,向着我们的开发目标不断前进。

SuperWRT第一个测试版本(支持WR886n)发布

SuperWRT的第一个测试版本在2015年12月4日发布了。测试版本目前仅在TP-Link WR886n 上进行测试,测试版本验证完成后,会陆续支持其它设备。

第一次发布的为Tiny版本,即支持2M Flash设备的版本。众所周知,目前第三方路由器系统(如OpenWRT、DD-WRT)由于体积原因,已无法支持2M Flash的设备,但TP-Link等厂家的很多数设备仍使用2M的Flash,导致大家无法直接刷机。SuperWRT的Tiny版本在系统上进行全面的瘦身,裁剪和重写了绝大部分功能,在2M Flash仍能提供比较常用的功能。测试版本稳定后,我们将会带来更多设备的支持。

当然使用Linux系统支持16M RAM的无线路由器仍有瓶颈,我们全力保证设备平时的正常工作。但打开网页时,由于使用了脚本,仍会有时突发造成系统内存不足,而触发watchdog重启设备。

Tiny版本的定位就是基础的上网设备,同时增加一些大家刷第三方系统(如OpenWRT)需要的功能。目前Tiny版本主要加强了以下功能:

  • 用户限速:支持用户默认限速,也可对指定MAC限速
  • PPPoE的叠加拨号:支持负载均衡(成功后会的状态页显示多个IP)
  • PPtP VPN:支持修改端口(但必须有公网IP,即未经过NAT)。
  • 响应式管理网页:可以更好的支持手机端管理。

同时,提供了相应bootloader,支持网页刷机,有DHCP服务器可以给电脑分配IP,还可以通过域名oplogin.com/oplogin.cn登陆。

在测试阶段,目前仅对TP-Link的WR886n进行了支持,以在一定范围内进行小规模试验。SuperWRT其实对AR934x/QCA955x/QCA953x/QCA956x芯片都是支持的。前期版本进行充分验证后,会释放其它设备的支持。对MTK系统芯片,短期内还不会支持,主要是由于针对MTK的Wi-Fi驱动还有很多优化工作要做。

第一个测试版本仍然是在Ath9k驱动的基础上进行的更改。SuperWRT专有的无线驱动s11还在测试及开发中,在后期测试可以后会在版本中使用。

欢迎大家参与测试,一起让SuperWRT更加完善。

从MadWifi到ath5k,ath9k,ath10k最后到Linux kernel

这是一篇关于Atheros开源驱动发展历史的介绍。

MadWifi的官方开发者是Sam Leffler。他一直为FreeBSD维护和提高Atheros的驱动,并维护了MadWifi的HAL二进制文件。在2005年,Sam决定不再维护MadWifi,由其它志愿者进行维护。由于MadWifi的开发正式开放,并努力发展成Linux可用的WLAN驱动的之一,于是MadWifi项目诞生。

在驱动中,与Atheros芯片寄存器交互的部分叫做HAL(Hardware Abstraction Layer)。由于WLAN使用的是开放频谱,而各国对该频段都有相应的频段和功率的限制,但Atheros的芯片可以通过修改寄存器来实现所在国法律实际不允许的设置。所以,MadWifi的作者Sam Leffler经过Atheros同意,使用了一个二进制版本的HAL实现。后来MadWifi的后续维护人员使用了Reyk Floeter为FreeBSD开发的ar5k中的HAL源代码,发展出了开源的OpenHAL用于替代二进制的HAL。

在2007年MadWifi项目宣告终止,最后一个发布是在2008年。Madwifi的工作任务由ath5k和ath9k替代。ath5k和ath9k是在compat-wireless项目下进行维护。compat-wireless是一个为Linux开发的支持WLAN芯片驱动的合集。compat-wireless中的驱动代码会合入Linux kernel。但在使用了一个稳定版本的Linux kernel后,为了支持更新的WLAN芯片,需要更新的WLAN驱动部分,所以一般来说compat-wireless中驱动更常用一些。

继续阅读从MadWifi到ath5k,ath9k,ath10k最后到Linux kernel