WLAN with Linux SDIO: sneak preview
Wolfgang Spraul
wolfgang at openmoko.com
Mon Nov 3 06:38:43 CET 2008
Werner,
> What's next ? Most urgently, resurrection of the Atheros stack
> in stable-tracking, so that we have a proper baseline for
> performance comparison.
"Above all, abandonment is the key to innovation -- both because it
frees the necessary resources and because it stimulates the search for
the new that will replace the old."
(Peter F. Drucker)
Wolfgang
On Nov 3, 2008, at 11:05 AM, Werner Almesberger wrote:
> This is the first sneak preview of the replacement of the Atheros
> SDIO stack underneath the WLAN driver with the Linux SDIO stack.
>
> Unlike previous versions, this stack now uses the S3C MMC driver.
> I've removed the SPI-based variants and performance enhancements
> related to them from the patch set, so the whole set is now a lot
> leaner than it used to be.
>
> My goals for this release were:
>
> - no regression on throughput
> - no regression on latency
> - supports insertion as a module
>
> Unfortunately, the latest rebasing of stable-tracking broke the
> Atheros stack, so I don't have performance data that's directly
> comparable yet. My preliminary results suggest that throughput
> when sending data to the Neo, ping latency, and ping jitter are
> roughly comparable. Throughput when sending is about 10% below
> what I see with the Atheros SDIO stack.
>
> There's a more detailed performance evaluation below.
>
> The AR6k driver can be built as a module. I've briefly tested
> insertion, removal, re-insertion, and removal with ongoing
> traffic.
>
> As a welcome side-effect, the stack change also seems to solve
> bug #1597, event/0 suddenly getting busy after ~18 hours.
>
> What's next ? Most urgently, resurrection of the Atheros stack
> in stable-tracking, so that we have a proper baseline for
> performance comparison.
>
> After that, the use of SDIO interrupts wants looking into. The
> Linux SDIO stack currently polls (!) for interrupts, which
> causes unnecessary overhead and introduces latency. There is a
> set of patches by Christer Weinigel that add SDIO interrupt
> support to s3cmci, but they don't work out of the box, apparently
> due to some idiosyncrasies of the 2442.
>
> This may or may not improve latency, which would be the next
> target. On the same wireless network on which the Neo has an
> average ping of 70+ms, with large excursions, my laptop gets an
> average of 1.7ms and a maximum of about 5-6ms.
>
>
> ===== Build instructions =====
>
> - get the base kernel from stable-tracking:
>
> git clone git://git.openmoko.org/git/kernel.git wherever
> cd wherever
> git checkout b961c6de2a96a96436bb342722974aaf54aea638
>
> - get the patches from SVN:
>
> svn co -r 4746 \
> http://svn.openmoko.org/developers/werner/wlan-spi/patches-tracking
> ln -s patches-tracking patches
>
> - remove the Atheros SDIO stack and move the AR6k driver into
> drivers/ar6000/:
>
> rm -rf drivers/ar6000
> mv drivers/sdio/function/wlan/ar6000 drivers/
> rm -rf drivers/sdio include/linux/sdio
>
> - apply the patches:
>
> quilt push -a
>
> - enable the necessary drivers:
>
> Device Drivers
> AR6000 wireless networking over SDIO (CONFIG_AR6000_WLAN)
>
> and
>
> Device Drivers
> MMC/SD/SDIO card support
> Samsung S3C SD/MMC Card Interface support (CONFIG_MMC_S3C)
>
> - compile, install, ...
>
> If the AR6k driver was built as a module, it's in
> drivers/ar6000/ar6000.ko
>
> ... reboot, and enjoy !
>
> Build process too complex ? Then stay tuned. It'll get easier soon.
>
>
> ===== Performance data: Atheros SDIO =====
>
> This is with the Atheros SDIO stack in the "origin/stable" branch.
> The two data sets are ttcp transfers with default settings.
>
> ---- host => -------- => neo ---------
> *1000B/s ctx_sw *1000B/s ctx_sw
> 1: 746.98 348 740.39 12252
> 2: 747.31 393 740.39 12021
> 3: 740.06 346 734.23 12313
> 4: 749.99 321 740.39 12352
> 5: 735.84 469 730.40 12211
> 6: 741.04 444 736.49 12288
> 7: 752.34 435 748.98 12255
> 8: 754.03 417 748.65 12183
> 9: 745.99 392 742.03 12252
> 10: 741.37 379 737.14 12355
> AVG: 745.50 394 739.91 12248
>
> ---- neo => --------- => host --------
> *1000B/s ctx_sw *1000B/s ctx_sw
> 1: 804.28 286 796.26 11577
> 2: 790.63 302 784.72 11644
> 3: 793.25 275 784.72 11643
> 4: 788.40 319 778.16 11606
> 5: 789.89 273 781.06 11598
> 6: 808.15 256 800.44 11592
> 7: 823.62 273 814.82 11582
> 8: 820.00 292 810.10 11631
> 9: 812.06 286 803.12 11633
> 10: 817.20 359 808.54 11606
> AVG: 804.75 292 796.19 11611
>
>
> ===== Performance data: Linux SDIO =====
>
> This is with the Linux SDIO stack based on the "origin/stable-
> tracking"
> branch.
> There is a second two data set with pings.
>
> ---- host => -------- => neo ---------
> *1000B/s ctx_sw *1000B/s ctx_sw
> 1: 734.23 425 730.08 5334
> 2: 746.32 420 744.33 5213
> 3: 748.65 354 746.98 5042
> 4: 745.32 468 743.34 5195
> 5: 768.19 374 764.69 4629
> 6: 766.43 397 763.29 4824
> 7: 734.23 436 732.63 5671
> 8: 721.60 411 718.20 5485
> 9: 709.10 478 707.30 5872
> 10: 765.73 419 759.84 4438
> AVG: 743.98 418 741.07 5170
>
> ---- neo => --------- => host --------
> *1000B/s ctx_sw *1000B/s ctx_sw
> 1: 728.18 408 723.47 11618
> 2: 702.86 374 698.47 11603
> 3: 734.55 378 729.13 11591
> 4: 719.13 391 713.01 11611
> 5: 713.62 406 707.90 11578
> 6: 723.16 419 716.98 11593
> 7: 717.28 363 711.50 11600
> 8: 706.71 392 701.68 11589
> 9: 744.00 402 739.74 11602
> 10: 735.20 380 730.08 11630
> AVG: 722.47 391 717.20 11601
>
> host => neo: min /avg /max stddev (100 samples)
> 10.60/ 75.91/ 287.00 49.09 ms
> neo => host: min /avg /max stddev (100 samples)
> 20.85/ 78.82/ 216.25 41.60 ms
>
>
> ===== Performance comparison =====
>
> I did not include the ping data for the Atheros SDIO stack, because
> "stable" has more unrelated printk activity in this test, which are
> very likely to increase the latency. With both stacks, latency can be
> very high. This still needs examining.
>
> ttcp throughput is almost identical when sending data to the Neo.
> In the opposite direction, the the Linux SDIO stack achieves only
> 90% of the throughput of the Atheros stack.
>
> Some of the differences may also be caused by the different kernels.
> I'll have to redo the Atheros measurements once the driver is unbroken
> in stable-tracking.
>
> The Linux SDIO stack still has plenty of room for improvement. E.g.,
> the S3C MCI driver uses neither SDIO interrupts nor DMA, while
> Samuel's S3C24xx driver for the Atheros stack has both.
>
> - Werner
>
More information about the openmoko-kernel
mailing list