root@zswamp.fidonet.org (Geoffrey Welsh) (10/13/90)
According to some info I've seen, the HST/ix is just an HST with some software (probably for SCO Xenix). Can anyone confirm this? Does anyone using the software know if perhaps it's as simple as a uucico replacement that implements UUCP-e? -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 No one pays me enough to represent any opinions but my own.
larry@nstar.uucp (Larry Snyder) (10/15/90)
root@zswamp.fidonet.org (Geoffrey Welsh) writes: > According to some info I've seen, the HST/ix is just an HST with some >software (probably for SCO Xenix). Can anyone confirm this? Consider it confirmed. According to USR, after installing this software, your machine will be able to talk to another Xenix machine running this "IX" software - but will no longer be able to communicate with machines running normal UUCP "g" protocol. This information was verified by one of USR's (actually the "IX" product was developed by a third company) beta testers.. The PEP is still the best modem for UUCP. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar!larry@ndmath.math.nd.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
mikes@iuvax.cs.indiana.edu (Michael Squires) (10/16/90)
In article <1990Oct15.120645.7065@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: > >Consider it confirmed. According to USR, after installing this software, ..stuff deleted... will no longer be able to communicate with machines >running normal UUCP "g" protocol. I've wondered why one couldn't just create a login for "hstuucp" with a shell of "/usr/lib/uucp/hstuucico"; then both systems would work. I've never seen a copy of the HST/IX stuff, but this would seem fairly simple to kludge together. -- Mike Squires (mikes@iuvax.cs.indiana.edu) 812 855 3974 (w) 812 333 6564 (h) mikes@iuvax.cs.indiana.edu 546 N Park Ridge Rd., Bloomington, IN 47408 Under construction: mikes@sir-alan@cica.indiana.edu
mjs@cbnews.att.com (martin.j.shannon) (10/17/90)
In article <1990Oct15.120645.7065@nstar.uucp>, larry@nstar.uucp (Larry Snyder) writes, in part: > > The PEP is still the best modem for UUCP. > And I contend that may be true if you use 'g' protocol, but if you (and your neighbor) can use 'e' protocol, any of the current (small) flock of 14400 b/s modems that support full error correction and flow control should perform similarly. Further, 'e' protocol *should* (I can't say for sure -- I don't have source available) use less CPU in the uucico process (no packet assembly/disassembly). Yes, Telebit has a very good product, but Telebit is *does* have competition. Please be very careful with blanket statements like the above from Larry. (Sorry, Larry, your article just happened to be at the wrong place at the wrong time. You aren't the only one who does it -- you're just the one who broke *this* camel's back!) -- Marty Shannon; AT&T Bell Labs; Liberty Corner, NJ, USA (Affiliation is given for identification only: I don't speak for them; they don't speak for me.)
larry@nstar.uucp (Larry Snyder) (10/19/90)
mjs@cbnews.att.com (martin.j.shannon) writes: >And I contend that may be true if you use 'g' protocol, but if you (and >your neighbor) can use 'e' protocol, any of the current (small) flock >of 14400 b/s modems that support full error correction and flow control >should perform similarly. Further, 'e' protocol *should* (I can't say >for sure -- I don't have source available) use less CPU in the uucico >process (no packet assembly/disassembly). 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)? -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar!larry@ndmath.math.nd.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
grr@cbmvax.commodore.com (George Robbins) (10/19/90)
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)
mjs@cbnews.att.com (martin.j.shannon) (10/20/90)
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)? Larry, for UUCP ('g' protocol), the Telebits have quite an advantage -- if both ends are Telebits -- in that the modems themselves "spoof" the uucp 'g' protocol. Between the modems, I suspect something like the 'e' protocol is used: just blast the bits, and let the normal error recovery do its thing. Well, it's a little more complicated than that, but probably not much. Be all that as it may, my guess (educated, but a guess nonetheless) is that you'll get worse than PEP if you use 'g' protocol, and at least comparable to PEP with 'e' protocol. Depending on the traffic contents, you may be able to do better than PEP using 'e' protocol. Let me (and the net!) know how that works; my HST DS hasn't been upgraded to V.42bis yet.... Also, if you get modems with V.32bis (not yet a standard, right, Toby?) and V.42bis, you should certainly be able to beat PEP with 'e' protocol (again, assuming an equivalently equipped neighbor, and an error-free uucico->uucico path). Did you say that you do or don't have 'e' protocol available to you? For non-Telebit-high-speed-modems, my recommendation is to use 'e' if you (and your neighbor) support it. Actually, even for 2400 baud, it might make enough of a difference (again, with the restriction that both sites *must* have hardware flow control (i.e., error free path from uucico to uucico)). I use the FAS driver and a 16550AFN uart (THANKS, Uwe!), and typically get 97% of the 14400 b/s available (according to uutraf, and after weeding out "very short" transfers -- less than 1k: they tend to report transfer rates greater than 38.4Kb/s (I lock interface speed to 38.4Kb/s)!). -- Marty Shannon; AT&T Bell Labs; Liberty Corner, NJ, USA (Affiliation is given for identification only: I don't speak for them; they don't speak for me.)
heiser@sud509.ed.ray.com (Bill Heiser - Unix Sys Admin) (10/22/90)
In article <15268@cbmvax.commodore.com> grr@cbmvax.commodore.com (George Robbins) writes: > >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. > I find that my inbound news averages (as shown by 'uutraf') a bit better than 1200cps. Outbound stuff, which is usually mail messages, news articles, etc, are around 1650-1670 cps. Do I have a configuration problem here, or is this typical? I'm also seeing "alarm x" messages when I try to do other stuff on the system while it's receiving news packets on the Telebit -- Do I need to install a 16550 on the serial port to reduce system load? -- Work: heiser@tdw201.ed.ray.com {decuac,necntc,uunet}!rayssd!tdw201.ed.ray.com!heiser Home: bill@unixland.uucp bill%unixland.uucp@world.std.com uunet!world!unixland!bill Public Access Unix (508)655-3848 [ Usenet News Online! ] Other: heiser@world.std.com (Public Access Unix)
datri@convex.com (Anthony A. Datri) (10/22/90)
>>If the uucp traffic is compressed new batches, the trailblazers can average >>around 12K-BPS >1200cps. Outbound stuff, which is usually mail messages, news articles, etc, >are around 1650-1670 cps. At a previous employer I set up a TB+ running off of a Sun 3/180's Systech MTI 1650. At the other end were an IBM PC clone of some kind and a Vax 11/780 with a TB+ attached to a dz11 at 9600. This was in the wastelands of southwestern Conn. Talking to the clone in either direction I routinely got 1500 cps in the uucp SYSLOG on compressed news. I don't know what he had for [d]uarts, but the Systech certainly isn't reknowned for its high aggregate throughput. Talking to the Vax was pretty dismal, since 9600 is one bottleneck, and the DZ11 (you Unibus guys are smirking knowingly) another. -- datri@convex.com
grr@cbmvax.commodore.com (George Robbins) (10/23/90)
In article <25@tdw205.ed.ray.com> heiser@world.std.com writes: > In article <15268@cbmvax.commodore.com> grr@cbmvax.commodore.com (George Robbins) writes: > > > >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. > > > > I find that my inbound news averages (as shown by 'uutraf') a bit better than > 1200cps. Outbound stuff, which is usually mail messages, news articles, etc, > are around 1650-1670 cps. Do I have a configuration problem here, or is this > typical? This sounds typical, the difference being due to incorrect measurement of the time required to send outgoing batches. The Telebit spoofing code tricks uucp into thinking the transmission is complete when it still has a complete buffer of data to send. It "catches" up during the next file protcol exchange. If you increase your news batch sizes to something reasonable like 128K you'll see this level out a lot. It is intereting to note that big news batches of 128K to 512K work quite reliably with the Trailblazer and drastically cut the uucp fuss and bother with dozens of little batches being spooled for each site. > I'm also seeing "alarm x" messages when I try to do other stuff on the system > while it's receiving news packets on the Telebit -- Do I need to install > a 16550 on the serial port to reduce system load? Sounds like a good bet - the alarm messages are often indicative of dropped characters, it's a timout before attempting to restart the conversation after things get confused. If the "alarm n" keeps increasing though, it probably means a lousey/dropped connection or other problems. -- 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)
larry@nstar.uucp (Larry Snyder) (10/24/90)
heiser@sud509.ed.ray.com (Bill Heiser - Unix Sys Admin) writes: >I find that my inbound news averages (as shown by 'uutraf') a bit better than >1200cps. Outbound stuff, which is usually mail messages, news articles, etc, >are around 1650-1670 cps. Do I have a configuration problem here, or is this >typical? is your news compressed (16 bit)? - and what are the packet sizes? mail is generally in smaller packets - so the cps rate usually is not very accurate >I'm also seeing "alarm x" messages when I try to do other stuff on the system >while it's receiving news packets on the Telebit -- Do I need to install >a 16550 on the serial port to reduce system load? yes - if you driver supports the fido buffer in the 16550 >-- >Work: heiser@tdw201.ed.ray.com > {decuac,necntc,uunet}!rayssd!tdw201.ed.ray.com!heiser >Home: bill@unixland.uucp > bill%unixland.uucp@world.std.com > uunet!world!unixland!bill > Public Access Unix (508)655-3848 [ Usenet News Online! ] >Other: heiser@world.std.com (Public Access Unix) -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar%larry@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
root@zswamp.fidonet.org (Geoffrey Welsh) (10/25/90)
In a message to All on Oct 23, Larry Snyder (larry@nstar.uucp ) wrote:
>yes - if you driver supports the fido buffer in the 16550
Slip of the finger, Larry? FIFO, not Fido! <grin>
--
UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent
Internet: root@zswamp.fidonet.org | Kitchener, Ontario
FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA
Data: (519) 742-8939 | (519) 741-9553
MC Hammer, n. Device used to ensure firm seating of MicroChannel boards