> On 21-May-2016, at 3:39 AM, David Lang <da...@lang.hm> wrote:
>
> There was a new wifi firmware release today (not yet in LEDE or OpenWRT
> trunk) announced around post 11400 on this forum
>
> https://forum.openwrt.org/post.php?tid=50173&qid=325044
>
> David Lang
>
> On Fri, 20 May 2016, Dave Taht wrote:
>
>> Date: Fri, 20 May 2016 14:16:13 -0700
>> From: Dave Taht <dave.t...@gmail.com>
>> To: Dheeran Senthilvel <dheeranm...@gmail.com>
>> Cc: lede-dev@lists.infradead.org,
>> "cerowrt-de...@lists.bufferbloat.net"
>> <cerowrt-de...@lists.bufferbloat.net>
>> Subject: Re: [Cerowrt-devel] [LEDE-DEV] WRT1900ACS Testing
>> We had found some pretty major performance problems on this hardware
>> as of a few months ago. I am curious if they still exist? A whole
>> bunch of benchmarks went by on the cerowrt-devel list, also.
>>
>> They were:
>>
>> 1) broken local ethernet network stack - running 4 copies of netperf
>> against it - one would grab all the bandwidth and the other three
>> barely even start or hang completely.
>>
>> 2) No BQL in the ethernet driver
>>
>> 3) Wifi was horribly overbuffered in general
>>
>> 4) Wifi would crash against flent's rrul test.
>>
>>
>> On Thu, May 19, 2016 at 3:37 AM, Dheeran Senthilvel
>> <dheeranm...@gmail.com> wrote:
>>> Hi,
>>> I am currently running LEDE r274 build dated 18-May-2015. The build seems
>>> to be stable as of now, have been flashing the images ever since the
>>> snapshot was made available in the repository. Current Status of the device
>>> is as follows,
>>>
>>> # Wireless - both 2.4Ghz (@297MB/s) and 5Ghz(@1079MB/s) are working
>>> fine.(Speed tested using iperf).
>>>
>>> # USB - Not Tested
>>>
>>> # LEDs - Only Power, WiFi & LAN leds are functioning. WAN & USB are
>>> not working (Similar OpenWrt Ticket - https://dev.openwrt.org/ticket/21825)
>>>
>>> #Terminal Output
>>>
>>>
>>>> root@Shelby:~# lsmod
>>>
>>> ahci_mvebu 1653 0
>>> ahci_platform 2367 0
>>> armada_thermal 3284 0
>>> cfg80211 220675 2 mwlwifi
>>> compat 13025 2 mac80211
>>> crc_ccitt 979 1 ppp_async
>>> ehci_hcd 34246 2 ehci_orion
>>> ehci_orion 2563 0
>>> ehci_platform 4368 0
>>> gpio_button_hotplug 5988 0
>>> hwmon 2026 3 tmp421
>>> i2c_core 18339 3 tmp421
>>> i2c_dev 4551 0
>>> i2c_mv64xxx 7033 0
>>> ip6_tables 9625 3 ip6table_raw
>>> ip6t_REJECT 1056 2
>>> ip6table_filter 682 1
>>> ip6table_mangle 1042 1
>>> ip6table_raw 648 0
>>> ip_tables 9775 4 iptable_nat
>>> ipt_MASQUERADE 698 1
>>> ipt_REJECT 914 2
>>> iptable_filter 736 1
>>> iptable_mangle 868 1
>>> iptable_nat 1029 1
>>> iptable_raw 702 0
>>> ledtrig_usbdev 2307 0
>>> libahci 19501 3 ahci_mvebu
>>> libahci_platform 4501 2 ahci_mvebu
>>> libata 127382 5 ahci_mvebu
>>> mac80211 401118 1 mwlwifi
>>> mmc_block 21754 0
>>> mmc_core 77838 2 mvsdio
>>> mvsdio 7362 0
>>> mwlwifi 69628 0
>>> nf_conntrack 60523 9 nf_nat_ipv4
>>> nf_conntrack_ipv4 6125 11
>>> nf_conntrack_ipv6 6564 6
>>> nf_conntrack_rtcache 2461 0
>>> nf_defrag_ipv4 884 1 nf_conntrack_ipv4
>>> nf_defrag_ipv6 13185 1 nf_conntrack_ipv6
>>> nf_log_common 2407 2 nf_log_ipv4
>>> nf_log_ipv4 3218 0
>>> nf_log_ipv6 3663 0
>>> nf_nat 10036 4 nf_nat_ipv4
>>> nf_nat_ipv4 4054 1 iptable_nat
>>> nf_nat_masquerade_ipv4 1509 1 ipt_MASQUERADE
>>> nf_nat_redirect 919 1 xt_REDIRECT
>>> nf_reject_ipv4 1911 1 ipt_REJECT
>>> nf_reject_ipv6 2236 1 ip6t_REJECT
>>> nls_base 5190 1 usbcore
>>> ppp_async 6521 0
>>> ppp_generic 19930 3 pppoe
>>> pppoe 8047 0
>>> pppox 1239 1 pppoe
>>> pwm_fan 2840 0
>>> sata_mv 26825 0
>>> scsi_mod 88117 3 usb_storage
>>> sd_mod 23412 0
>>> slhc 4543 1 ppp_generic
>>> thermal_sys 20307 2 armada_thermal
>>> tmp421 2500 0
>>> usb_common 1676 1 usbcore
>>> usb_storage 37368 0
>>> usbcore 120847 8 ledtrig_usbdev
>>> x_tables 10689 26 ipt_REJECT
>>> xhci_hcd 81489 2 xhci_plat_hcd
>>> xhci_pci 2324 0
>>> xhci_plat_hcd 3897 0
>>> xt_CT 2797 0
>>> xt_LOG 851 0
>>> xt_REDIRECT 825 0
>>> xt_TCPMSS 2660 2
>>> xt_comment 511 62
>>> xt_conntrack 2516 16
>>> xt_id 506129
>>> xt_limit 1241 20
>>> xt_mac 631 0
>>> xt_mark 704 0
>>> xt_multiport 1308 0
>>> xt_nat 1329 0
>>> xt_state 801 0
>>> xt_tcpudp 1800 10
>>> xt_time 1670 0
>>>
>>>> root@Shelby:~# cat /etc/config/system
>>>
>>> config system
>>> option hostname 'Shelby'
>>> option timezone 'IST-5:30'
>>> option ttylogin '0'
>>>
>>> config timeserver 'ntp'
>>> list server '0.openwrt.pool.ntp.org'
>>> list server '1.openwrt.pool.ntp.org'
>>> list server '2.openwrt.pool.ntp.org'
>>> list server '3.openwrt.pool.ntp.org'
>>> option enabled '1'
>>> option enable_server '0'
>>>
>>> config led 'led_wan'
>>> option name 'WAN'
>>> option sysfs 'pca963x:shelby:white:wan'
>>> option trigger 'netdev'
>>> option mode 'link tx rx'
>>> option dev 'eth0'
>>>
>>> config led 'led_usb2'
>>> option name 'USB2'
>>> option sysfs 'pca963x:shelby:white:usb2'
>>> option trigger 'usbdev'
>>> option interval '50'
>>> option dev '1-1'
>>>
>>> config led 'led_usb3'
>>> option name 'USB3'
>>> option sysfs 'pca963x:shelby:white:usb3_1'
>>> option trigger 'usbdev'
>>> option interval '50'
>>> option dev '2-1'
>>>
>>>> root@Shelby:~# ls /sys/class/leds
>>> shelby:white:power shelby:white:sata
>>>
>>>
>>> Sorry Guys! Never Used mailing lists
>>> _______________________________________________
>>> Lede-dev mailing list
>>> Lede-dev@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>>
>>
>> --
>> Dave Täht
>> Let's go make home routers and wifi faster! With better software!
>> http://blog.cerowrt.org
>> _______________________________________________
>> Cerowrt-devel mailing list
>> cerowrt-de...@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
Glad someone is interested in this topic. First lets clear some of your doubts,
# mventa-hwbm patch is available to enable buffer management in the LAN ports.
Might have solved the ethernet problem you had said.
# mwlwifi - The github repo only provides a binary blob and a linking code,
would be glad if they just provided the code as is so the kernel-devels can
make it work properly. As of now every update is accompanied with throughput
lags or high pings (including OEM firmware) not to forget complete lockdown
time to time, requiring manually reboot.
# marvell-cesa - crypto engine driver, only some have been able to make the
patch work and benchmarks show results same as “mwlwifi” driver condition -
just working.
Please feel free to follow the OpenWrt forum page on Update on "Linksys
WRT1900AC support” to know current updates -
https://forum.openwrt.org/viewtopic.php?id=50173. Notable developer cum tester
include david502, mrfreeze, nitroshift. These guys are real developers/sysadmin
who build their own firmwares with all current patches and have made them
public for other to test. Would be awesome if these guys come over to LEDE
Development.
As of the new driver in the github repo, news is that its only for
WRT1900AC V1 & ACS - building is one thing but the initial testing shows high
pings with a decent performance and still occasional reboots are necessary.
Another update has been made available in the repo just after the before said
mwlwifi update
Its gonna take a while before either Linksys just releases a proper working
drivers (or) just releases the code under GPL for upstream kernel-development
(Just like what happened for raspberrypi). Have to be patient till then, but
anyway the performance and usability of the hardware under LEDE/OpenWrt is
still better than the OEM firmware (not to mention that the OpenWrt buildbot is
successful occasionally, which is why I am using LEDE in the first place - its
really neat)
Regards
Dheeran
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
