Path: utzoo!utgpu!watserv1!watmath!att!mcdchg!laidbak!ism.isc.com!uunet!wuarchive!zaphod.mps.ohio-state.edu!ncar!gatech!rutgers!cbmvax!grr From: grr@cbmvax.commodore.com (George Robbins) Newsgroups: comp.dcom.modems Subject: Re: USRobotics Courier HST/ix? Message-ID: <15268@cbmvax.commodore.com> Date: 19 Oct 90 14:58:26 GMT References: <540.2718D7BC@zswamp.fidonet.org> <1990Oct15.120645.7065@nstar.uucp> <1990Oct16.172741.13979@cbnews.att.com> <1990Oct18.181733.18413@nstar.uucp> Reply-To: grr@cbmvax.commodore.com (George Robbins) Organization: Commodore, West Chester, PA Lines: 107 In article <1990Oct18.181733.18413@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: > I am considering replacing the HST (14.4) modems with V.32 > with v.42bis and MNP5 here on nstar - with the idea that > UUCP throughput with the V.32 and v.42bis will be very close > to that of the PEP modems. Do you agree (that V.32 and PEP will > produce about the same throughput on uucp transfers)? Not yet... I don't think the ground rules have really changed. If the uucp traffic is compressed new batches, the trailblazers can average around 12K-BPS (with good connections and fast CPU's) while your V.32 modem will somewhere less than 9600 and the compression will be ineffective. Since news compression is rather close to 2:1, the trailblazer uucp thruput comes out to 24K-BPS (actually it's a bi-modal distribution, with some systems averaging around 8K-BPS raw, or 16K-BPS with compression. Note that this second cluster is about what you get with a V.32 modem, but V.32 *NEVER* goes faster, while the Trailblazer is often 50% faster! (compression over the last 2-days was 1.8, depressed somewhat by the volume of alt.porn gif's which don't compress well 8-) However, you might find the compression effective enough that you could send un-compressed batches. I don't think the thruput would exceed the compressed rate, but you get rid of the cpu overhead involved in the compression process. Of course, it has been asserted that the overhead of squeezing the extra characters thru unix tty drivers and character I/O is greater than that of compressing the stuff in the first place. So, what are the alternatives? 1) If your uucp traffic isn't compress batches or compress source archives, hen a modem doing on the fly compression could do better. The question then becomes what data are you uucp'ing? The thruput on the usual mail/odd job uucp mix is bounded by uucp/system overhead on small files, not modem thruput. Batched mail would help, but it ain't here yet. 2) Use a modem with "higher raw thruput". Something like the USR 14400 with their proprietary uucp replacement might win out if their software was universally available and there were enough out there to talk to. I'd have to see some real A/B testing, since everybody always seem to claim best case numbers when extolling the virtues of their favorite modem. 3) Use a V.32bis modem with its potential higher thruput. Assuming you get one, then there are some real questions about how often you will be able to establish connections at one of the higher bit rates. If most calls fall back to 4800/7200/9600 then you're not much better off then V.32, and if connection probability isn't in the 75% range then you end up with a lot of delayed transmissions or can't get here from there for days... 4) Use more efficient protocols. There's some hope here, but not a whole lot. The uucp "g" protocol is well tuned to the standard (i.e. your binary distribution) character I/O system. Increasing the window size requires kernel mods (TTYHOG>255) or hardware flow control. No "error free" modem link is really end-to-end error free without some additional software error checking, and protocols that assume error free links often end up sending the same file over and over again due to some pathological condition or the filesize being big enough that the probability of a hit approaches unity. Is there any hope? It's amusing to read the original uucp papers where they are pessimistic about gaining much from higher bit rates at all. Getting better thruput requires (1) faster modem technology, (2) real-world performance, (3) improvements in unix serial I/O support (h/w flow control, bigger raw buffer limits, more thruput), (4) better uucp link protocols, and (5) better uucp job/batch level protocols. While any of these can be addressed on a site-by-site basis, the process of building up a consensus base of compatible implementations tends to be rather slow. The conversion of the usenet news community to the Telebit modems was fast in comparison only because the solution managed to work within the common constraints and all that was required was plugging a better modem into equation. The bottom line is that modems that are really faster should yield incremental performance gains, but the era of doubling-speeds is over until ISDN or other medium not constrained by the analog phone channel is generally available. At that point, however there might well be be a shift to networking protocols CSLIP,PPP,TCP/IP) since these provide a multiplexed communications channel and avoid the bottlenecks of the current single threaded uucp model, not to mention extending a much more flexible array of services than batched file transfer/RJE. Where did this start? Oh yeah! For the moment, buying T2500's make a lot of sense, since they include V.32, MNP and now V.?? capabilities. The future depends a lot on whether Telebit has the resources/motivation to significantly enhance their proprietary capabilities and how the cost/upgradeability/performance of the telebit multi- standard products compares to other vendors products enanced V.32 or proprietary/multi-standard products. My personal feeling is that Telebit is going to lose it if they don't get moving one way or the other. I'm sure cell-blazers or net-blazers have much better margin than tranditional modem products, but they are far less effective at increasing overall market penetration than boosting Trailblazer speeds would be. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)