"Jens B. Jorgensen" <[EMAIL PROTECTED]> writes: First off, it was my impression that bsd_comp only affects ppp (TCP?) headers. It doesn't do any general data compression (so it wouldn't try to compress the jpg data in a packet, just the headers). I had heard that it is essentially always a win.
> Note that compression protocols, while improving bandwidth, will > always introduce some amount of latency since encoding/decoding > takes compute time. This really depends on how you define latency. Let's say I want to send a 1K TCP packet. Presumably, how fast the first byte gets to the other side is essentially irrelevant since the application waiting on the data can't do anything until it gets the entire packet (given the way TCP works). In that case, if you can spend a trivial amount of time compressing the packet (and you can with today's mostly idle CPUs) to some fraction of its original size, the whole packet will get transferred faster. Although the "first byte through" latency is higher, the packet latency can be *much* lower. Another more abstract example where the *effective* latency is dramatically reduced when compression is used is in the case of gzip compressed ssh connections and X. In a test letting ssh use gzip to compress all it's transfers cut a remote launch of xview across a ppp link to 1/3 of the non-compressed launch time. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
