gavinmc Hi, I've been mulling over a problem I have with OpenVPN compression and wondered if an idea I had might make sense or if (more likely) it is just the ramblings of a beginner. If you bear with me I'll describe it briefly and someone might say why it's a bad idea. As I understand it, if the compression ratio is R (ie R=0.9 means a 10% reduction in data size), then you'll get data compression if R<1, but not if R>1. Is that right? The docs seem to say that's roughly it. As far as I can see, there are two criteria which determine whether compressing data is a good idea: 1. The data, when compressed, is smaller than the original. 2. The time taken to compress is less than the time saved by the compression. #1 is really a subset of #2 -- if the data doesn't compress, it won't save time to compress it. So, an ideal adaptive compression might determine whether to compress or not based on criteria #2. Suppose openvpn can monitor the average Bitrate of data sent across the link, B (this should be independent of whether compression is in use). The time taken to forward a frame of size M across the link should be roughly: Time = M / B seconds If the observed compression ratio is R as above, the transfer time saved by compressing the data should be about: dTime = (1-R) * M / B seconds One could in principal monitor cTime, the average time taken to compress the data and possibly even xTime, the average time taken to expand the data. Then use a criteria like: if(dTime > (cTime + xTime)) { enable_compression; } xTime might be awkward to determine, as it's only available at the far end, but you could ignore it if need be and just use cTime. I would imagine compressing is probably more costly than decompressing. The reason I suggest this is that I've noticed that a busy CPU on a slow laptop appears to kill OpenVPN performance if compression is enabled. My guess is that the compression or decompression time is slowing things down. I would prefer that the adaptive compression would realise that the compression is not a benefit in this case and disable it. Maybe this is overly simplistic, pure nonsense or maybe OpenVPN already does this (the man page doesn't seem to suggest it, but I might have misread). Thanks in advance for any opinions, corrections or criticisms, Gavin
hannuko Sounds a good idea to me. Instead of turning compression on/off, the system could also move to a simpler compression algoritm, or use faster compressing parameters.
Mimiko There is no need to adapt the compression ratio, as it is though like a file compression by some software: use the maximum computing power to reduce maximally the size. Either you use compression or not based on needs and computing power. Usually, the speed thru the tunnel is not at full line speed, so a compression is needed to push more data. This compression consumes computing power, so in case of production server, where only OpenVPN is running and/or a gateway, with current computiong speeds, compression does not increase significally the latency. Even a pentium III with 630MHz with other software running, can handle a speed of 2-3 MB/s without much latency.
janjust this is exactly what comp-lzo adaptive does : it watches the compression stream and turns compression on or off.
