| 1 |
Linux GNUbie wrote: |
| 2 |
|
| 3 |
>On Sun, 2005-04-24 at 08:32 +0200, Daniel Armyr wrote: |
| 4 |
> |
| 5 |
> |
| 6 |
>>I am not too familiar with VPN, but as I understand it, it is pretty much only a convenient way to tunnel all traffic through an encrypted pipe. Would a benchmark using an ssh-tunnel give sufficiently relevant results? |
| 7 |
>> |
| 8 |
>> |
| 9 |
> |
| 10 |
>I have friends that told me that the hardware specs of the Linksys |
| 11 |
>BEFSR41 or WRT54G cannot support the VPN client service simply because |
| 12 |
>of the encryption/decryption process that needs more processing power |
| 13 |
>and physical memory. |
| 14 |
> |
| 15 |
|
| 16 |
The WRT54GS has 8MB of flash, btw, and (IIRC) 32MB of RAM (I have one on |
| 17 |
the desk next to me, would have to check.) The extra flash makes it a |
| 18 |
bit roomier to hack on. I'm (slowly) getting it set up to replace a |
| 19 |
machine at work that we use to bridge a couple of networks. |
| 20 |
|
| 21 |
I did some googling and came up with: |
| 22 |
|
| 23 |
http://martybugs.net/wireless/openwrt/openvpn.cgi |
| 24 |
|
| 25 |
----(snip)---- |
| 26 |
Performance Testing |
| 27 |
Network Architecture |
| 28 |
This WRT is connecting to an 802.11b Minitar MNWAPB access point, and |
| 29 |
hence is restricted to 802.11b 11Mbps speeds. |
| 30 |
|
| 31 |
The throughput was measured by using wget to retrieve a 3MB file over |
| 32 |
the wireless link. |
| 33 |
|
| 34 |
Initial tests were performed during setup, when the WRT was physically |
| 35 |
located close to the Minitar access point, so the WRT was associated to |
| 36 |
the Minitar with a link rate of 11Mbps. The tests were repeated once the |
| 37 |
WRT was installed at the client site, with similar results. |
| 38 |
|
| 39 |
Throughput Without VPN |
| 40 |
Throughput over the wireless link between the WRT and the Minitar was |
| 41 |
tested at approximately 600 kbytes/sec (ie, typical for an 802.11b |
| 42 |
wireless link). |
| 43 |
|
| 44 |
Throughput With VPN |
| 45 |
Once the VPN tunnel was established, and all traffic routed through it, |
| 46 |
the tests were repeated. Throughput dropped to approximately 300 kbytes/sec. |
| 47 |
|
| 48 |
The major cause of this slow-down is the CPU in the WRT, as it needs to |
| 49 |
encrypt and decrypt all the traffic that is passing through the VPN |
| 50 |
tunnel. This can be observed by monitoring the CPU usage on the WRT |
| 51 |
while transferring large amounts of traffic through the VPN tunnel - the |
| 52 |
OpenVPN process consumes 99% of the CPU during this time. |
| 53 |
|
| 54 |
The slow-down caused by the VPN tunnel is acceptable in the situation |
| 55 |
I'm using the WRT. If this isn't the case, the throughput of the VPN |
| 56 |
tunnel can be increased by moving the VPN termination from the WRT onto |
| 57 |
a faster device (ie, a linux router) behind the WRT. |
| 58 |
----(snip)---- |
| 59 |
|
| 60 |
So there's at least one test, but as usual YMMV. |
| 61 |
|
| 62 |
-P |
| 63 |
|
| 64 |
-- |
| 65 |
gentoo-embedded@g.o mailing list |
Archives