From: Scott E. <sc...@ju...> - 2013-06-03 16:12:22
|
Just got my first Zephyr boards. The WIFI speeds are unimpressive. Here's the ping speed to a workstation on the LAN root@duo:~# ping hex PING hex (192.168.10.3): 56 data bytes 64 bytes from 192.168.10.3: seq=0 ttl=64 time=23.162 ms 64 bytes from 192.168.10.3: seq=1 ttl=64 time=15.076 ms 64 bytes from 192.168.10.3: seq=2 ttl=64 time=14.771 ms 64 bytes from 192.168.10.3: seq=3 ttl=64 time=29.847 ms 64 bytes from 192.168.10.3: seq=4 ttl=64 time=14.099 ms 64 bytes from 192.168.10.3: seq=5 ttl=64 time=13.825 ms 64 bytes from 192.168.10.3: seq=6 ttl=64 time=13.702 ms 64 bytes from 192.168.10.3: seq=7 ttl=64 time=13.397 ms 64 bytes from 192.168.10.3: seq=8 ttl=64 time=13.031 ms 64 bytes from 192.168.10.3: seq=9 ttl=64 time=12.726 ms root@duo:~# lsmod Module Size Used by ipv6 263882 16 mwifiex_sdio 19595 0 mwifiex 160431 1 mwifiex_sdio firmware_class 6982 1 mwifiex cfg80211 196178 1 mwifiex root@duo:~# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:15:C9:28:F8:95 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:204 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:136 errors:0 dropped:0 overruns:0 frame:0 TX packets:136 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:11472 (11.2 KiB) TX bytes:11472 (11.2 KiB) mlan0 Link encap:Ethernet HWaddr 00:19:88:24:FB:9C inet addr:192.168.10.105 Bcast:192.168.10.255 Mask:255.255.255.0 inet6 addr: fe80::219:88ff:fe24:fb9c/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1146 errors:0 dropped:0 overruns:0 frame:0 TX packets:152 errors:2 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:190318 (185.8 KiB) TX bytes:20140 (19.6 KiB) uap0 Link encap:Ethernet HWaddr 00:19:88:24:FB:9C BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Here's a comparison to a BeagleBone Black with a USB WIFI dongle pinging the same machine. root@black:~# ping hex PING hex (192.168.10.3): 56 data bytes 64 bytes from 192.168.10.3: seq=0 ttl=64 time=0.409 ms 64 bytes from 192.168.10.3: seq=1 ttl=64 time=0.199 ms 64 bytes from 192.168.10.3: seq=2 ttl=64 time=0.242 ms 64 bytes from 192.168.10.3: seq=3 ttl=64 time=0.202 ms 64 bytes from 192.168.10.3: seq=4 ttl=64 time=0.213 ms I'm running the 3.6 kernel from the linux-gumstix repo. Any suggestions? -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Andy W. <an...@si...> - 2013-06-03 16:27:32
|
On Mon, 2013-06-03 at 09:11 -0700, Scott Ellis wrote: > Just got my first Zephyr boards. The WIFI speeds are unimpressive. > > Here's the ping speed to a workstation on the LAN > > root@duo:~# ping hex > PING hex (192.168.10.3): 56 data bytes > 64 bytes from 192.168.10.3: seq=0 ttl=64 time=23.162 ms > 64 bytes from 192.168.10.3: seq=1 ttl=64 time=15.076 ms > 64 bytes from 192.168.10.3: seq=2 ttl=64 time=14.771 ms > 64 bytes from 192.168.10.3: seq=3 ttl=64 time=29.847 ms > 64 bytes from 192.168.10.3: seq=4 ttl=64 time=14.099 ms > 64 bytes from 192.168.10.3: seq=5 ttl=64 time=13.825 ms > 64 bytes from 192.168.10.3: seq=6 ttl=64 time=13.702 ms > 64 bytes from 192.168.10.3: seq=7 ttl=64 time=13.397 ms > 64 bytes from 192.168.10.3: seq=8 ttl=64 time=13.031 ms > 64 bytes from 192.168.10.3: seq=9 ttl=64 time=12.726 ms > > root@duo:~# lsmod > Module Size Used by > ipv6 263882 16 > mwifiex_sdio 19595 0 > mwifiex 160431 1 mwifiex_sdio > firmware_class 6982 1 mwifiex > cfg80211 196178 1 mwifiex > > root@duo:~# ifconfig -a > eth0 Link encap:Ethernet HWaddr 00:15:C9:28:F8:95 > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > Interrupt:204 > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:136 errors:0 dropped:0 overruns:0 frame:0 > TX packets:136 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:11472 (11.2 KiB) TX bytes:11472 (11.2 KiB) > > mlan0 Link encap:Ethernet HWaddr 00:19:88:24:FB:9C > inet addr:192.168.10.105 Bcast:192.168.10.255 Mask:255.255.255.0 > inet6 addr: fe80::219:88ff:fe24:fb9c/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:1146 errors:0 dropped:0 overruns:0 frame:0 > TX packets:152 errors:2 dropped:0 overruns:0 carrier:0 Hmm. 2 Tx errors. A bit of asymmetry on Tx vs Rx packet counts. > collisions:0 txqueuelen:1000 Have you tried setting the Tx queue length shorter, to say 100? 1000 is rather deep. > RX bytes:190318 (185.8 KiB) TX bytes:20140 (19.6 KiB) > > uap0 Link encap:Ethernet HWaddr 00:19:88:24:FB:9C > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > > Here's a comparison to a BeagleBone Black with a USB WIFI > dongle pinging the same machine. > > > root@black:~# ping hex > PING hex (192.168.10.3): 56 data bytes > 64 bytes from 192.168.10.3: seq=0 ttl=64 time=0.409 ms > 64 bytes from 192.168.10.3: seq=1 ttl=64 time=0.199 ms > 64 bytes from 192.168.10.3: seq=2 ttl=64 time=0.242 ms > 64 bytes from 192.168.10.3: seq=3 ttl=64 time=0.202 ms > 64 bytes from 192.168.10.3: seq=4 ttl=64 time=0.213 ms > > I'm running the 3.6 kernel from the linux-gumstix repo. > > Any suggestions? None really. What does iwconfig show as the channel data rate for the interface? Regards, Andy |
From: Steve S. <sa...@gm...> - 2013-06-03 17:59:32
|
Scott, More than likely performance is suffering due to the lack of SDIO interrupt support for OMAP in the 3.6 kernel. I last time I made any effort to patch in SDIO interrupt support was back in 3.2. Steve On Mon, Jun 3, 2013 at 9:11 AM, Scott Ellis <sc...@ju...> wrote: > Just got my first Zephyr boards. The WIFI speeds are unimpressive. > > Here's the ping speed to a workstation on the LAN > > root@duo:~# ping hex > PING hex (192.168.10.3): 56 data bytes > 64 bytes from 192.168.10.3: seq=0 ttl=64 time=23.162 ms > 64 bytes from 192.168.10.3: seq=1 ttl=64 time=15.076 ms > 64 bytes from 192.168.10.3: seq=2 ttl=64 time=14.771 ms > 64 bytes from 192.168.10.3: seq=3 ttl=64 time=29.847 ms > 64 bytes from 192.168.10.3: seq=4 ttl=64 time=14.099 ms > 64 bytes from 192.168.10.3: seq=5 ttl=64 time=13.825 ms > 64 bytes from 192.168.10.3: seq=6 ttl=64 time=13.702 ms > 64 bytes from 192.168.10.3: seq=7 ttl=64 time=13.397 ms > 64 bytes from 192.168.10.3: seq=8 ttl=64 time=13.031 ms > 64 bytes from 192.168.10.3: seq=9 ttl=64 time=12.726 ms > > root@duo:~# lsmod > Module Size Used by > ipv6 263882 16 > mwifiex_sdio 19595 0 > mwifiex 160431 1 mwifiex_sdio > firmware_class 6982 1 mwifiex > cfg80211 196178 1 mwifiex > > root@duo:~# ifconfig -a > eth0 Link encap:Ethernet HWaddr 00:15:C9:28:F8:95 > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > Interrupt:204 > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:136 errors:0 dropped:0 overruns:0 frame:0 > TX packets:136 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:11472 (11.2 KiB) TX bytes:11472 (11.2 KiB) > > mlan0 Link encap:Ethernet HWaddr 00:19:88:24:FB:9C > inet addr:192.168.10.105 Bcast:192.168.10.255 Mask:255.255.255.0 > inet6 addr: fe80::219:88ff:fe24:fb9c/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:1146 errors:0 dropped:0 overruns:0 frame:0 > TX packets:152 errors:2 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:190318 (185.8 KiB) TX bytes:20140 (19.6 KiB) > > uap0 Link encap:Ethernet HWaddr 00:19:88:24:FB:9C > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > > Here's a comparison to a BeagleBone Black with a USB WIFI > dongle pinging the same machine. > > > root@black:~# ping hex > PING hex (192.168.10.3): 56 data bytes > 64 bytes from 192.168.10.3: seq=0 ttl=64 time=0.409 ms > 64 bytes from 192.168.10.3: seq=1 ttl=64 time=0.199 ms > 64 bytes from 192.168.10.3: seq=2 ttl=64 time=0.242 ms > 64 bytes from 192.168.10.3: seq=3 ttl=64 time=0.202 ms > 64 bytes from 192.168.10.3: seq=4 ttl=64 time=0.213 ms > > I'm running the 3.6 kernel from the linux-gumstix repo. > > Any suggestions? > > > > > -- > View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344.html > Sent from the Gumstix mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Scott E. <sc...@ju...> - 2014-01-31 17:27:15
|
The two obvious drivers are mwifiex and mwifiex_sdio. Source is here drivers/net/wireless/mwifiex/ It would be nice if a USB wifi dongle that used this chip existed. Something you could plug into the Duovero to narrow things down. You could ask someone on the DreamPlug lists to see what kind of performance they are getting and with what kernel. I think they use the same radio attached via SDIO. Maybe some i.mx6 SOC board uses the same radio as well. Sorry not much use. Probably just have to go through the code and figure it out. -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4968645.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Florian V. <flo...@ep...> - 2013-06-04 06:35:16
|
Hello, On 06/03/2013 07:59 PM, Steve Sakoman wrote: > Scott, > > More than likely performance is suffering due to the lack of SDIO > interrupt support for OMAP in the 3.6 kernel. > > I last time I made any effort to patch in SDIO interrupt support was > back in 3.2. > I saw this patch in Gumstix's kernel 3.5: https://github.com/gumstix/linux/commits/omap-3.5 It do not seem to be in 3.6 however. So you may try with the 3.5 to see if things are better. Regards, Florian |
From: Steve S. <sa...@gm...> - 2013-06-04 16:39:35
|
I stand corrected! The last time was 3.5 not 3.2 :-) Steve On Mon, Jun 3, 2013 at 11:35 PM, Florian Vaussard <flo...@ep...> wrote: > Hello, > > On 06/03/2013 07:59 PM, Steve Sakoman wrote: >> Scott, >> >> More than likely performance is suffering due to the lack of SDIO >> interrupt support for OMAP in the 3.6 kernel. >> >> I last time I made any effort to patch in SDIO interrupt support was >> back in 3.2. >> > > I saw this patch in Gumstix's kernel 3.5: > > https://github.com/gumstix/linux/commits/omap-3.5 > > It do not seem to be in 3.6 however. So you may try with the 3.5 to see > if things are better. > > Regards, > > Florian > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: acsmith <ac...@st...> - 2014-02-16 17:02:52
|
To add to the wifi issues, I finally stopped to look at the error message. I'm getting the following output when the wifi freezes up, it repeats over and over again I can usually lengthen the time until error by removing ipv6 There's got to be a problem with driver. Not sure where to start. Anyone else seeing this kind of issue? Thanks, Andrew -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4968740.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2013-06-04 15:07:05
|
Thanks all. I agree it's probably the sdio driver. I tried a quick hack at back porting the omap_hsmmc.c changes from 3.9, but my port has some issues. It compiles and loads, but has errors in the irq handling. Looks like I'm going to have to take the time to understand it ;-( The 3.5 patch does not apply cleanly to 3.6. Also, there appears to be a regression with the Overo radios going from 3.2 to 3.5. I'd say at least a 30% performance degradation from my tests. I think I'd rather try to pull back changes from later kernels. There are some reports of decent performance using a mwifiex radio connected via sdio. http://article.gmane.org/gmane.linux.ports.arm.omap/91510/match=fenkart It would be nice to get that kind of performance from the Zephyr. Here are some tests showing the 3.2 to 3.5 regression I was seeing with the Overo if anyone is interested. The same hardware was used. https://gist.github.com/scottellis/5706523 -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4967360.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: hobbesc7 <hob...@gm...> - 2013-09-03 15:22:54
|
Scott Ellis wrote > I agree it's probably the sdio driver. Did you ever solve this? I'm also using 3.6 and have slow wifi speeds. I moved to 3.6 from 3.5 because I was having trouble with i2c in 3.5. 3.6 works well for me, other than the slow wifi. -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4967857.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: acsmith <ac...@st...> - 2014-02-23 01:14:52
|
acsmith wrote > To add to the wifi issues, I finally stopped to look at the error message. > I'm getting the following output when the wifi freezes up, it repeats over > and over again > > I can usually lengthen the time until error by removing ipv6 > > There's got to be a problem with driver. Not sure where to start. Anyone > else seeing this kind of issue? > > > Thanks, > > Andrew Well I've tried debugging this message with different hardware and software and come up with pretty much nothing. I've tried several different images (my own, Pansenti console image, stock Gumstix downloaded image). I've tried different micro SD cards (manufacturer, size). I've even tried on two different DuoVero boards (both W/O 29155 13-29 GS4430Z-R3920). With each different variant the results are the same, after some random amount of time I get the error message [ 1065.791320] BUG: scheduling while atomic: swapper/1/0/0xfffe0000 [ 1065.797637] Modules linked in: ipv6 mwifiex_sdio mwifiex firmware_class cfg80211 [ 1065.805450] [<c0014f50>] (unwind_backtrace+0x0/0x11c) from [<c03c5e14>] (__schedule_bug+0x48/0x5c) [ 1065.814910] [<c03c5e14>] (__schedule_bug+0x48/0x5c) from [<c03cbcd0>] (__schedule+0x68/0x790) [ 1065.823883] [<c03cbcd0>] (__schedule+0x68/0x790) from [<c000f2ec>] (cpu_idle+0x104/0x120) [ 1065.832489] [<c000f2ec>] (cpu_idle+0x104/0x120) from [<803c1f14>] (0x803c1f14) which repeats over and over. I think it may have something to do with heat or how long it's been running but it might just be a coincidence. When the device is cold it seems to run longer without an error message and applying the supplied heat sink seems to help but I don't know for sure. At this point I'm not sure if it is an issue with the mwifiex driver/firmware, maybe that's just how some other problem first shows up. Once and a while I also get [ 927.082305] huh, entered softirq 1 TIMER c00403e0 preempt_count 00000100, exited with 00000000? No idea about that one. For those that are using a DuoVero, I'd really appreciate some feedback on your experiences. Ever seen any of these errors before? Is your system running fine? If so, what image & hardware (uSD card) are you using? Thanks for the help, Andrew -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4968801.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: acsmith <ac...@st...> - 2013-12-31 22:46:24
|
I'm having similar issues with wifi speeds, not really surprising since I'm using an image derived from Scott's. Using iperf I'm only getting about 13Mbit/s while connected to an 802.11n access point (sitting next to it). 802.11n is over 70Mbit/s. We should be getting much better performance than this. I'm trying to stream some H264 video using gstreamer. It's crashing over wifi but working perfectly on wired connection. The video doesn't need a lot but would like to get the wifi running as fast as possible. Anyone have better wifi results on Zephyr? My results for Overo 3.5 kernel aren't plagued like Scott's, mine runs at same speed as 3.2. -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4968486.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: acsmith <ac...@st...> - 2014-02-23 15:38:41
|
I should also note that usually when the stream of error messages happens, it only appears on the console. Often the COM continues to function but runs a bit slower. The only way to know that the error messages are coming is if the console is open (or probably by looking at dmesg). So some advice for others with a DuoVero who are experiencing some weird performance, take a look at the console output (might have to give it some time) and see if you are getting something similar. Thanks, Andrew -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4968802.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: acsmith <ac...@st...> - 2014-01-26 05:21:45
|
I thought I'd bump this thread again and add some info. Not only have I found the DuoVero wifi speeds slow but also unreliable. When I push the limits (still in the single digit Mb/s) I've found that the DuoVero will crash. It's really not a reliable form of communication at the moment. I'm going to try and find some time to investigate the suggestions posted above, just curious if anyone else out there has some insight or has messed around with it at all (even with unsuccessful results)? Thanks, Andrew -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4968616.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: acsmith <ac...@st...> - 2014-03-10 15:26:32
|
I'm happy to report that with Scott's help it looks like things are much better. I tested out a Dora release of one of Scott's images (found here <http://www.jumpnowtek.com/gumstix/duovero/Duovero-Systems-with-Yocto.html> ) and everything worked fine, no more error messages. Scott and I both tested the old image using only wired communication and that seemed to be stable. Therefore, it's our guess that it's an issue with the wifi on the Dylan branch. As soon as I updated to the Dora branch, everything was good. So whatever was causing the problem seems to be gone in the newest branch. Long story short, if using DuoVero I'd suggest using the Dora branch. Now just need to improve the speeds. Thanks for the help, Andrew -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4968894.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2014-01-30 13:52:07
|
The problem we are encountering is not throughput (our bandwidth requirement is low), but that one or both drivers do not come up during boot. We are using both the bt and wifi. The error appears as a timeout in the firmware loading stage. It's very intermittent though. Most of the time the system comes up fine. I ran some tests on SD card read/write Fast card root@duovero:~# dd if=/dev/zero of=zero.dat bs=10M count=100 100+0 records in 100+0 records out 1048576000 bytes (1.0 GB) copied, 52.718 s, 19.9 MB/s root@duovero:~# dd if=/dev/zero of=zero.dat bs=10M count=100 100+0 records in 100+0 records out 1048576000 bytes (1.0 GB) copied, 51.1367 s, 20.5 MB/s root@duovero:~# dd if=zero.dat of=/dev/null bs=10M count=100 100+0 records in 100+0 records out 1048576000 bytes (1.0 GB) copied, 51.5274 s, 20.3 MB/s root@duovero:~# dd if=zero.dat of=/dev/null bs=10M count=100 100+0 records in 100+0 records out 1048576000 bytes (1.0 GB) copied, 47.9992 s, 21.8 MB/s Slow card root@duovero:~# dd if=/dev/zero of=zero.dat bs=10M count=100 100+0 records in 100+0 records out 1048576000 bytes (1.0 GB) copied, 121.967 s, 8.6 MB/s root@duovero:~# dd if=/dev/zero of=zero.dat bs=10M count=100 100+0 records in 100+0 records out 1048576000 bytes (1.0 GB) copied, 113.839 s, 9.2 MB/s root@duovero:~# dd if=zero.dat of=/dev/null bs=10M count=100 100+0 records in 100+0 records out 1048576000 bytes (1.0 GB) copied, 56.4273 s, 18.6 MB/s root@duovero:~# dd if=zero.dat of=/dev/null bs=10M count=100 100+0 records in 100+0 records out 1048576000 bytes (1.0 GB) copied, 51.9299 s, 20.2 MB/s There is some asymmetry with the read/write speeds with the slow card which could be in the card's specs. But in all cases these are really pretty good. Much faster then the roughly 10 Mb/s (1.2 MB/s) I am seeing with iperf over wifi. It doesn't look like the low-level SDIO driver (omap_hsmmc.c) is the bottleneck. Both the bluetooth and wifi drivers use the same sd8787_uapsta.bin firmware. That could be the problem, though hard to fix. Could try another version. There are also the kernel shim drivers btmrvl and btmrvl_sdio for bluetooth and mwifiex and mwifiex_sdio for wifi. I think that's where I'm going to start looking. Any other ideas, suggestions? -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4968632.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2014-03-10 16:11:58
|
I didn't do anything in the new builds to intentionally improve things, but I agree with Andrew that the new images seem more stable with wifi. There are some binaries available if anyone is interested http://www.jumpnowtek.com/downloads/duovero/ Just a heads up, they are sysvinit based not systemd. There is support for AP mode with the necessary userland tools. Some instructions for getting a simple AP running are here http://www.jumpnowtek.com/gumstix/duovero/Duovero-Access-Point.html Those are new write-ups for the new site. I'd appreciate hearing about any errors. Scott -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4968895.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2014-01-30 14:15:58
|
That didn't take long. Found this commit upstream commit 69676b1c2af451bfe5cd36ff4973a484b5d5a86c Author: Andreas Fenkart <and...@st...> Date: Mon Apr 22 11:10:23 2013 +0200 Bluetooth: btmrvl: report error if verify_fw_download times out FW does the synchronization of the different modules during init. It will report different modules, that it is ready at different times. The fw download 'winner' will be reported fw ready first. Without this patch, btmrvl was already continuing before the FW told it too. Probably on behalf of the 'winner' which then never sees FW ready and times out. Signed-off-by: Andreas Fenkart <and...@st...> Signed-off-by: Gustavo Padovan <gus...@co...> I'll see about backporting it to the Gumstix 3.6 kernel. -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4968633.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Ash C. <ash...@gm...> - 2014-01-30 18:12:10
|
Thanks Scott---that looks very helpful! On Thu, Jan 30, 2014 at 6:15 AM, Scott Ellis <sc...@ju...> wrote: > That didn't take long. > > Found this commit upstream > > commit 69676b1c2af451bfe5cd36ff4973a484b5d5a86c > Author: Andreas Fenkart <and...@st...> > Date: Mon Apr 22 11:10:23 2013 +0200 > > Bluetooth: btmrvl: report error if verify_fw_download times out > > FW does the synchronization of the different modules during init. > It will report different modules, that it is ready at different times. > The fw download 'winner' will be reported fw ready first. Without this > patch, btmrvl was already continuing before the FW told it too. Probably > on behalf of the 'winner' which then never sees FW ready and times out. > > Signed-off-by: Andreas Fenkart <and...@st...> > Signed-off-by: Gustavo Padovan <gus...@co...> > > > I'll see about backporting it to the Gumstix 3.6 kernel. > > > > > -- > View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4968633.html > Sent from the Gumstix mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: acsmith <ac...@st...> - 2014-01-30 19:52:58
|
Nice find about the upstream commit, maybe that'll help things. Scott Ellis wrote > Both the bluetooth and wifi drivers use the same sd8787_uapsta.bin > firmware. That could be the problem, though hard to fix. > Could try another version. I confirmed that I'm using mwifiex 1.0 (14.66.9.p96) driver on my system. That's the latest one I could find on the Marvell repository <http://git.marvell.com/?p=mwifiex-firmware.git;a=tree;f=mrvl;h=b4c5fcee5bdae3b17e796afabcf3c86321712219;hb=HEAD> . Is there another version worth trying? I didn't see any other 8787 versions. Thanks for the work Scott. Andrew -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4968637.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: dtran11 <dt...@gm...> - 2014-05-02 22:31:03
|
Any update on WiFi performance? I am seeing half the bandwidth of a Overo running 3.2. Also are you guys using the heatsink with your duovero? Thanks -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4969082.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2014-01-30 21:55:14
|
Backported patches for the firmware loading issue are here https://github.com/Pansenti/meta-pansenti/blob/master/recipes-kernel/linux/linux-gumstix-3.6/0011-Bluetooth-btmrvl-release-lock-while-waiting-for-fw.patch https://github.com/Pansenti/meta-pansenti/blob/master/recipes-kernel/linux/linux-gumstix-3.6/0012-Bluetooth-btmrvl-report-error-if-verify_fw_download.patch That's a Yocto [dylan] meta-layer. I've been testing on a [dora] system, but it's the same kernel. I've been rebooting two COMs repeatedly for a few hours now with no failures. Cold and warm reboots. One slow SD card, one fast. That's longer then I've ever gone without a firmware loading failure with a slow card. One of the boards, the slow card, on one occasion had a problem when I brought down uap0 manually. Repeated messages like this ... mwifiex_sdio mmc1:0001:1: read mp_regs failed ... I couldn't bring the interface back up, but after a reboot everything was fine again. I only saw this error once. These patches do nothing to improve the wifi throughput speed. They are only for the firmware loading. -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4968639.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Panayiotis M. <pmo...@gm...> - 2014-01-31 09:27:59
|
Hello all, I'm also interested in the performance of the WiFi on Zephyr. I would like to ask if this info is relevant: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-td4967344.html https://github.com/gumstix/linux/commit/010810d22f6f49ac03da4ba384969432e0320453 and how we could improve the performance of the Zephyr WiFi based on this information. Best regards, Panayiotis On Thu, Jan 30, 2014 at 11:54 PM, Scott Ellis <sc...@ju...> wrote: > Backported patches for the firmware loading issue are here > > > https://github.com/Pansenti/meta-pansenti/blob/master/recipes-kernel/linux/linux-gumstix-3.6/0011-Bluetooth-btmrvl-release-lock-while-waiting-for-fw.patch > > > https://github.com/Pansenti/meta-pansenti/blob/master/recipes-kernel/linux/linux-gumstix-3.6/0012-Bluetooth-btmrvl-report-error-if-verify_fw_download.patch > > That's a Yocto [dylan] meta-layer. I've been testing on a [dora] system, > but it's the same kernel. > > I've been rebooting two COMs repeatedly for a few hours now with > no failures. Cold and warm reboots. One slow SD card, one fast. > That's longer then I've ever gone without a firmware loading failure > with a slow card. > > One of the boards, the slow card, on one occasion had a problem > when I brought down uap0 manually. > > Repeated messages like this > ... > mwifiex_sdio mmc1:0001:1: read mp_regs failed > ... > > I couldn't bring the interface back up, but after a reboot everything > was fine again. I only saw this error once. > > > These patches do nothing to improve the wifi throughput speed. > They are only for the firmware loading. > > > > > > -- > View this message in context: > http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4968639.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: acsmith <ac...@st...> - 2014-05-02 22:59:07
|
Nope, never got anywhere near the speeds it should be running. I've tried it with and without the heatsink and didn't find it made much difference. I thought for a while I was getting some crashing because of overheating but it turned out to be something else. I wish I could help with the wifi speeds because that could potentially be a huge deal for some applications. Unfortunately it appears to be a problem with the driver. Good luck, Andrew -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4969083.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: acsmith <ac...@st...> - 2014-01-31 16:22:50
|
Scott Ellis wrote > Backported patches for the firmware loading issue are here > > https://github.com/Pansenti/meta-pansenti/blob/master/recipes-kernel/linux/linux-gumstix-3.6/0011-Bluetooth-btmrvl-release-lock-while-waiting-for-fw.patch > > https://github.com/Pansenti/meta-pansenti/blob/master/recipes-kernel/linux/linux-gumstix-3.6/0012-Bluetooth-btmrvl-report-error-if-verify_fw_download.patch > > That's a Yocto [dylan] meta-layer. I've been testing on a [dora] system, > but it's the same kernel. > > I've been rebooting two COMs repeatedly for a few hours now with > no failures. Cold and warm reboots. One slow SD card, one fast. > That's longer then I've ever gone without a firmware loading failure > with a slow card. > > One of the boards, the slow card, on one occasion had a problem > when I brought down uap0 manually. > > Repeated messages like this > ... > mwifiex_sdio mmc1:0001:1: read mp_regs failed > ... > > I couldn't bring the interface back up, but after a reboot everything > was fine again. I only saw this error once. > > > These patches do nothing to improve the wifi throughput speed. > They are only for the firmware loading. Thanks for the patches Scott. I applied them and with some limited testing it looks like the wifi booting is more reliable. I did a few boots and every time the wifi came up and connected. Now the throughput needs to be addressed. Just to confirm it, I quickly checked the wifi speeds and got about the same, about 10Mb/s. From your post earlier, it appears as though it's not a problem with the SDIO driver because MMC reads/writes are an order of magnitude faster than with the wifi. I'm not sure if the MMC connection uses a dedicated IRQ line but I know the wifi definitely does not. Could that be an issue? In "iwconfig mlan0" it's listed with a bit rate of 72.2 Mb/s. One odd thing to note, when I was checking that info the wifi locked up (solid red light) and the system froze, I had to reboot. I've seen other issues where some interaction with the wifi locks up the system. I tried disabling power management (which makes red light stay solid) but the throughput is the same. Where else along the chain could be the bottleneck? I know your needs don't include improving throughput but do you have some suggestions on where to look? Thanks, Andrew -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4968644.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: dtran11 <dt...@gm...> - 2014-05-02 23:39:35
|
Thanks for the update. When it crash does it give any kernel error logs or just halt and all LEDs on module turn off. I am seeing the latter. It seems as though the chip failed from overheating (not using heatsink). My test is to transfer a 50mb file via WiFi. Dies at 80% completion. Also the heatsink doesn't fit so I haven't put it on. -- View this message in context: http://gumstix.8.x6.nabble.com/Wifi-speeds-with-Duovero-Zephyr-tp4967344p4969084.html Sent from the Gumstix mailing list archive at Nabble.com. |