Performance issues in WRT54GS and tinyPEAP

Discussion in 'TinyPEAP Firmware' started by scaron, Apr 4, 2005.

  1. scaron

    scaron Network Guru Member

    I am puzzled/concerned with the overall system performance of this box. Sorry about the length of this post, but the question is worth it :)

    I setup a test network with 4 wireless systems connected to a wired network through a WRT54GS in mixed mode (2 systems using 802.11g WMP54G-CA PCI cards and 2 laptops using 802.11b mini-PCI cards. As far as I can tell, tinyPEAP is working properly and we have a "WPA Enterprise" solution (save one glitch in "own" certificates).

    In this test network, each user is setup with its own credentials, thus avoiding any "optimization" of the CPU workload. Rather than believe the bit rate shown by each client (a mixture of Windows XP SP1 and SP2), I wanted to see the impact of the encryption process on normal traffic.

    To this effect, on the 54G client with the best connection, I started a bi-directional iperf connecting to a wired system for 10 minutes at a time. Here are typical results:

    [776] local port 5001 connected with port 1434
    Client connecting to, TCP port 5001
    TCP window size: 8.00 KByte (default)
    [792] local port 41830 connected with port 5001
    [ ID] Interval Transfer Bandwidth
    [776] 0.0-600.0 sec 381 MBytes 5.33 Mbits/sec
    [792] 0.0-600.0 sec 227 MBytes 3.18 Mbits/sec

    While some people might be concerned with the poor performance of the link, I am concerned with the asymmetry: in the sample above, the upload speed (thread [776], wireless to wired) is 67% faster than the download speed (thread [792], wired to wireless). Monitoring of the WRT54GS was done in a SSH session on another wireless client using the top command. CPU usage was 38 to 45% ksoftirqd_cpu0, ~2.2% for dropbear, ~1.5% for top, and 0% for everything else. So, there is no measurable overhead for the RADIUS/tinyPEAP software unless it is hidden at interrup time. There was no subjective impact on any of the other three wireless clients (1 inet game, 2 browsers).

    Here are the results of the same bi-directional test on my 11B client with the best bitrate:

    [832] local port 5001 connected with port 1134
    Client connecting to, TCP port 5001
    TCP window size: 8.00 KByte (default)
    [808] local port 42162 connected with port 5001
    [ ID] Interval Transfer Bandwidth
    [808] 0.0-600.0 sec 132 MBytes 1.85 Mbits/sec
    [832] 0.0-600.1 sec 147 MBytes 2.05 Mbits/sec

    Again, the upload speed (thread [832], wireless to wired) is faster than the download speed (thread [808], wired to wireless), if only by 10%. In this particular sample, monitoring of the WRT54GS was done in a SSH session on the wired client using the top command. CPU usage was 17 to 21% ksoftirqd_cpu0, ~2.2% for dropbear, ~1.5% for top, and 0% for everything else.

    During these tests, there was no noticeable effects on the three other wireless clients. There were also no errors, drops, overruns, or collisions on any of the network interfaces (br0, eth0/1, lo, vlan0/1). Finally, statistics for each side of the bridge are consistent: eth0 RX 550.4 MiB TX 790.3 MiB and eth1 RX 782.9 MiB TX 551.6 MiB.

    In this network, 54G is taking a beating and so is common sense: there is usually little use for uploads faster than downloads. I will presume that the encryption process is not CPU bound since CPU is idle at least 50% of the time on the WRT54GS in all my tests. (I will presume the same of all P4 clients).

    Is there any kind of tool in your firmware that would enable pinpointing the bottleneck (encryption is IO bound, poor client software, and the like)? If not, is there a debugging firmware that would allow answering these questions? And, finally, do you believe that these results would scale on the WRT54 (that is, same overall performance, less idle time because of the slower CPU), indicating that these results are "par for the course" for this hardware?

    Side note:

    I noted a stange behavior from the bridge while testing. When the wireless client has an IP in the same subnet than that of the bridge, iperf will fail on the server side when -d is specified on the client side. The server tries to connect to the bridge IP (at the original client port). It does not matter which of the wired or wireless system is the server: the behavior is the same either side of the bridge.

    I disabled the DHCP server on the router so that wireless clients would be assigned leases from the DHCP server on the wired network from a different subnet.

    To avoid side effects from the bridge, the WRT54GS is uplinked to a BEFSR81 to which the wired systems are connected and all other local ports are empty. To avoid side effects from the Internet, the WAN port is empty and the default gateway in the basic setup screen is set to the IP of the BEFSR81. This is as close as a wired to wireless bridge you can get without changing the firmware.
  2. nairb2128

    nairb2128 Network Guru Member

    I would like to point out first that tinyPEAP itself has no inpact on throughput performance becaue it only handles the authentication and user management. However, with that being said, there are some things you should look at. First, mixed-mode G has been known to cause performance problems (in general, not just the wrt54g). I would venture to guess this might be causing the upload to be faster than the download. Try doing the tests in G only or B only mode. Also, are you using TKIP or AES? If you are concerned about performance, you might want to try dynamic WEP. As fars tools go, once again the firmware we use is just a stock Sveasoft satori firmware. We add the RADIUS server and user management. Your result are not 'par for the course' however. Our own testing results can be found in the tinypeap white paper ( Note the results are in megaBYTES not megaBITS.

    Hope that helps,
  3. scaron

    scaron Network Guru Member

    Hello Brian,

    Actually, it is your well written whitepaper that convinced me to give this beta a try. This being said, the performance quoted in your whitepaper is roughly 2 Mbytes/s or 16Mbits/s usefull payload. On a typical 36Mbit to 48Mbit 11g connection, this leaves 55% to 67% of the bandwidth to overhead and lost time.

    At this point in time, I am unconcerned with performance. I do want to verify that TKIP (and the MIC field) is in use in this firmware with Windows XP SP1/2 clients. Since the WRT54/GS units lack the hardware to do so, TKIP must be implemented in software and this may cause some of the performance degradation that we see.

    If the Satori firmware is offering both, Windows XP SP1 clients that did not install Q815485 should chose TKIP over AES. Those that did install this patch as well as Windows XP SP2 clients should chose AES over TKIP. If the Satori firmware is simply offering TKIP, then all Windows clients should use it.

    On my WRT54GS V1.0, here below is the status provided by wl. What tool can I use to verify that either software TKIP or AES is in use? And since this is the most significant part of WPA, do you agree that it should be easily verified?


    login as: root
    root@'s password:

    Welcome to the Sveasoft WRT54G/GS Firmware

    Satori-4.0 stable build
    version v2.07.1.7sv



    BusyBox v1.00-pre9 (2004.11.16-04:01+0000) Built-in shell (ash)
    Enter 'help' for a list of built-in commands.

    (none):[~]# wl revinfo
    vendorid: 14e4
    deviceid: 4320
    radiorev: 2205017f
    chipnum: 4712
    chiprev: 1
    corerev: 7
    boardid: 101
    boardvendor: 14e4
    boardrev: 10
    driverrev: 332150a
    ucoderev: f500cb
    bus: 0
    (none):[~]# wl wepstatus
    wepstatus is 1 (on)
    (none):[~]# wl wep
    Algorithms (hardware):
    WEP enabled
    TKIP disabled
    AES disabled
    (none):[~]# wl tkip
    Algorithms (hardware):
    WEP enabled
    TKIP disabled
    AES disabled
    (none):[~]# wl aes
    Algorithms (hardware):
    WEP enabled
    TKIP disabled
    AES disabled
  4. scaron

    scaron Network Guru Member

    WPA TKIP is finally up on my test network.

    Note 1: the setup documentation on says "2. Choose RADIUS or as its security mode". This should be updated to "Choose Radius or WPA RADIUS ..." and the WPA RADIUS should be the first example in the documentation since it is a lot less clumsy than RADIUS with useless keys.

    Note 2: this is a multilingual environment. While WPA is readily available in the drivers of XP SP1/2 US English versions, all of these drivers did not trickle down in the French version. So, even if I used the same hardware on both test systems, I was not using the same drivers :-(

    The documentation typo, the lack of an example of what I should have been expecting, and the mismatched drivers did me in.

    So, as you pointed out, I was using dynamic WEP. Using WAP TKIP does seem to burden the CPU a bit (about 5% more than dynamic WEP) and overall link performance is about the same.

    I will investigate the performance issue elsewhere.

    Thank you for your support.
  5. nairb2128

    nairb2128 Network Guru Member

    You will be hard pressed to find a wireless network that you can use more than 60% of its theoretical bandwidth in a single connection, if ever. Thus, the 55% overhead really is to be expected regardless of what AP you are using (when encryption is turned on).

    Regarding WPA and TKIP, the reason the instructions say to use RADIUS and not WPA RADIUS is because not all cards support WPA, although most do now. At the time of the writing however, most did not.
  6. scaron

    scaron Network Guru Member

    Contrary to what I said, I will close the performance issue in this forum, mainly because everything is in favor of tinyPEAP ;-)

    I believe the main contibution of this software is to use WPA's encryption (TKIP or AES) while avoiding the Pre Shared Key pitfall commonly found in small workgroups/domains. Thus, I want to promote WPA (at least TKIP) and authentication (at least PEAP) and tinyPEAP fits the bill PERFECTLY.

    There seems to be no penalty, at least on the WRT54GS, for using the technology.

    In mixed mode, the unit operates at 54Mbps and drops to 11Mbps whenever a B client comes in. This "penalty" is apparent in concurrent transfers from wireless hosts to a host on the wired side. Typical results are (all tests using iperf for 180 seconds)
    Client type: B G Rate: 11 Mbps CPU usage: ~50%
    Upload in Mbps 3.27 6.18 Total bandwitdh 9.45
    Download in Mbps 3.60 5.64 Total bandwitdh 9.24

    When using G clients only: Rate: 54 Mbps CPU usage: ~90%
    Upload in Mbps 14.9 (Max 16.9)
    Download in Mbps 14.4 (Max 14.9)

    However, the upload/download bias as well as the CPU drain disapear when the bridge is not used, that is in wireless to wireless transfers:
    When using G clients only: Rate: 54 Mbps CPU usage: ~75%
    Upload in Mbps 10.1 (Max 10.3)
    Download in Mbps 10.2 (Max 10.2)

    In this case, we can further stress the unit by invoking concurrent transfers on each unit:
    Upload in Mbps 4.93 4.96 Total bandwitdh 9.89
    Download in Mbps 4.96 4.93

    Variation in bandwidth usage all relates to the activity "in the air" and is not really predictible. The WRT54GS seems to max out at a composite speed of around 10Mbps when bi-directional traffic is sustained and 17 Mbps for uni-directional traffic. So, as far as I can tell, tinyPEAP is a great addition to the base firmware and the penalty for using WPA TKIP is negligible.

  7. pascal333

    pascal333 Network Guru Member

    TinPeap and alchemy

    I have just run across discussions of tinyPEAP in conjunction with Sveasoft sartori on the WRT54g.

    I am very interested in the tinyPEAP.

    I am running Sveasoft alchemy pre 7 (the latest pre release ) on a WRT54g v3.

    Is there any compatibility problem between the alchemy firmware and tinyPEAP?

    Do you know if the tinyPEAP is compatible with the WRT v3 ?

  8. tinyPEAP

    tinyPEAP Network Guru Member

    Hi pascal,

    First of all, thanks for your interst in our project. ;)

    TinyPEAP is based on the satori release of Sveasoft firmware,
    and to my knowledge, it is NOT compatible with WRT54g V3.
    As far as Alchemy version is concerned, we've decided to postpone our support due to the space issue; alchemy + tinyPEAP won't fit w/out removing some applications.
    We would like to have tinyPEAP on Alchemy at some point,
    however we do not know the exact date at this point.

    tinyPEAP Development Team
  9. buddyclub

    buddyclub Network Guru Member

    Cannot get WRT54GSv4 with firmware v1.05.2 TinyPeap to work

    I have bought a Linksys AP model WRT54GSV4 with firmware v1.05.2 specifically to get TinyPeapto work. I have downloaded the tinypeap v2.13 gs and followed the directions to upload it to the AP and it keeps giving the "Wrong Code Pattern" error. I have tried tftp or web.
    What am I doing wrong or is my version in-compatible with TinyPeap.

    Thank you for your help.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice