3 ms·
> I just installed DD-WRT on my router to use OpenVPN client on the router, the bandwidth speed drops to a level that makes the setup totally useless. A fair a
by bifrost 13y ago
> I just installed DD-WRT on my router to use OpenVPN client on the router, the bandwidth speed drops to a level that makes the setup totally useless.
A fair amount of that has to do with how little CPU is available on your router device, I suspect no manufacturer will support a device that can do a lot of crypto and still be in the consumer price range.
That said, I could ship you a device right now that'll do 100Mbps of encrypted traffic all day long, but it doesn't have wifi and its about $500...
- rdl 13y agoFor "roll your own" with an embedded device, the Marvell Kirkwood is probably the best since it has AES acceleration in hardware. One of the Sheevaplugs has this. It's not really well supported in Linux yet. It ends up being about as fast as an Atom.
- Wicher 13y agoThe Kirkwood AES accelerator (mv_cesa) is not exposed to userspace in Linux. It won't accelerate your SSL. You can use it to accelerate dm-crypt, though. I owned a Sheevaplug and own a Dreamplug. They're not nearly as fast as even a 2009 Atom... But power-efficient, yes.
- rdl 13y agoIs that just a driver limitation, or is there a problem with the hardware so the driver is written that way? It also doesn't do DMA, so I've heard bad things about performance with it for small packets.
- Wicher 13y agoIf I remember correctly it's a driver limitation, and theoretically it could be modified so it would do what you want, but consider the amount of userspace/kernelspace crossings to be made just to send some ciphertext over the network to some other party. I imagine something like this would take place: SSL does not happen in the kernel. So you need to send a payload to the kernel to encrypt, you get back the ciphertext, wrap it in your packet (add some headers) and then push this data once more to the kernel, which sends it out over the network for you. Receiving ciphertext would go along similar lines. That's probably not very efficient. Contrast this with full disk encryption using dm_crypt (linux). No shuffling back and forth of data. Userspace only really needs to handle the plaintext (and not even directly, but through the FS layer, which is also in the kernel). So maybe it may just not be worthwile to expose the interface to userspace on reasonably powerful platforms? Anything above a tiny MIPS or old 486? The VIA padlock crypto accelerator is (or was at some point) exposed to userspace and OpenSSL could take advantage of it. I wonder how much of a performance increase that yielded, considering the issue I noted above. Also, hardware accelerators typically only support a couple of modes and key sizes. That's fine for full disk encryption, but in a networked world you need more flexibility.
- bifrost 13y ago> I wonder how much of a performance increase that yielded It yielded 100Mbps+ SCP's with zero system CPU usage, very very handy. I've used a few older SSL accelerators and they were good for about 1Gbps or so. IMHO AES-NI makes these things obsolete, and with that going into the new Intel Atom cores, I think thats likely going to drop a lot of the competition out.
- rdl 13y agoAh, yes, the Silvermont series should be amazing. It looks like it might have virtualization extensions, too. I can't tell when it's supposed to come out, though. Should rock for NASes too. Right now only certain i3/i5 NAS seem to do AES acceleration, so the cheapest are around $2k bare from QNAP or $999 from iXSystems.
- deleted 13y ago[deleted]
- rufugee 13y agoYou are correct. I use OpenVPN to terminate a connection and get great performance, but it's served up by a reasonably powered box. If OP is using dd-wrt, I'm being it's on a WiFi router with 300mhz cpu at best and 48-64 mb ram.