swindon.ingr.com (Nik Simpson x333) (12/18/90)
Is it possible to get nntpxmit to compress news batches it transmits, this seems an obvious optimisation to make. -- |--------------------------------------------------| | Nik Simpson UUCP :uunet!ingr!swindon!st_nik!nik| | Senior Systems Engineer. Intergraph UK Ltd. | |--------------------------------------------------|
rsalz@bbn.com (Rich Salz) (12/20/90)
In <1990Dec18.094942.5125@st_nik!swindon.ingr.com> nik@st_nik!swindon.ingr.com (Nik Simpson x333) writes: > Is it possible to get nntpxmit to compress news batches it transmits, >this seems an obvious optimisation to make. I don't think it's obvious at all, really. You're increasing the amount of CPU time on both machines at the cost of lesser TCP time. I think that for more sites, the network is much cheaper than the CPU. /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
roy@phri.nyu.edu (Roy Smith) (12/21/90)
nik@st_nik!swindon.ingr.com (Nik Simpson x333) writes: > Is it possible to get nntpxmit to compress news batches it transmits rsalz@bbn.com (Rich Salz) responds: > You're increasing the amount of CPU time on both machines at the cost of > lesser TCP time. I think that for more sites, the network is much cheaper > than the CPU. Has anybody ever done any measurements one way or the other as to which way takes more CPU? (what? gather actual experimental data?) I remember some years ago, when sending compressed batches over 1200 bps was the normal way of shipping news, the common wisdom was that compress made your connect time cheaper at the cost of more CPU time, a tradeoff people were generally willing to make. Then, somebody (sorry, I don't remember who) did some measurements and discovered that the total user+system CPU time to send a compressed batch was actually *less* than to send an uncompressed batch. How can that be? Because I/O through the tty driver is very expensive; the CPU time spent doing the compress was more than paid for by cutting down the number of bytes the tty driver had to process. Could the same be true for TCP? Obviously, the per-byte overhead for DMAing 1.5k blocks through an ethernet interface is a lot less than for shoving it through a dz serial port, but has anybody actually tried measuring it? Is it possible that compress is a CPU win for nntp just like it was (is) for dialup? Now, mind you, I don't actually think that will turn out to be the case, but I don't buy either Nik's nor Rich's claims of obviousness. And, of course, the right answer will very much depend on whether you are running over a highly congested 19.2 or 56 kbps line or a T1 with bandwidth to spare. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy "Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
ronald@robobar.co.uk (Ronald S H Khoo) (12/21/90)
rsalz@bbn.com (Rich Salz) writes: > I don't think it's obvious at all, really. You're increasing the amount of > CPU time on both machines at the cost of lesser TCP time. > > I think that for more sites, the network is much cheaper than the CPU. Well, different people have different networks. There is a case for an option to compress, for the benefit of those doing full newsfeeds over a 2400 baud SLIP link. But I stress *OPTION* -- I certainly don't want to compress NNTP feeds over the ether .... -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)