Gene.Hastings@H.CS.CMU.EDU (05/31/87)
I remeber seeing discussion here months ago about 9600 bps dialup modems that were really half-duplex with fast turnaround. Has the game changed any since? I've seen an ad from US Robotics offering one that is full-duplex, but with split speed (9600/300), and turns around which channel gets to talk fast. I don't remeber if anyone said so before, but is there any sort of arbitration in these things to decide which direction gets the high speed? Thanks, Gene
W8SDZ@SIMTEL20.ARPA.UUCP (06/02/87)
The US Robotics HST 9600 modem is indeed full duplex. It uses a
return channel of 300 baud, which is plenty fast enough for hand
typing from a terminal.
The modem runs at a fixed speed on the RS232 line so the switching
between 300 and 9600 is transparent to your terminal. The end with
the most data to send gets the 9600, the other 300. The negotiation
between modems is fast and changes dynamicly.
I recently installed an HST modem on my Remote CP/M bulletin board
system. It is quite impressive in it's performance, handling both
interactive terminal sessions and XMODEM file transfers (using the
YMODEM 1k block size protocol). Those who predicted that the 300 baud
return channel would be unusable for data, claiming it would be used
only by the modem for MNP ack/nak's, were wrong!
I am very impressed by the USR HST 9600 and would not hesitate to
recommend it to anyone. I use one here at home to communicate with my
RCP/M which is located in the computer club President's home about 5
miles away. We have received long distance calls from several other
SysOps around the country who also have the HST. There have been no
problems with any of the calls.
It wouldn't surprise me if the HST becomes the defacto standard for
9600 bps. It beats those pseudo full duplex (really half duplex)
modems.
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZ
RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST)mgrant@MIMSY.UMD.EDU.UUCP (06/03/87)
>It wouldn't surprise me if the HST becomes the defacto standard for 9600 baud. >--Keith Petersen I would be surprised. Even though I usually don't require more than 300 baud to type at a terminal, my systems support UUCP which wouldn't work very well with 300 baud in one direction. Do these modems do some sort of flow analys and adjust the speed accordingly? I feel that the only good 9600 baud modem is one that provides at least a full 9600 baud in both directions, with NO egregious delays. -Mike p.s. the Microcom MNP level 6 comes close.
steckel@alliant.UUCP (06/03/87)
Advertisements for V.32 -->REAL 9600 BAUD FULL DUPLEX<-- modems have been appearing in the trade press. These cost (now) between US$1500-2500 each (not cheap! (:-) ) but should be extremely useful to high bandwith full duplex protocol users (e.g. UUCP mailers!). These units are made by large, presumably experienced companies who make modems that work. They use a CCITT standard, so are (one hopes) inter- compatible, as opposed to the consumer type 'fake' 9600s. My question - has anyone actually used a pair of these units over real dialup phone lines, and what happened? If they work, they could pay for themselves in about 3 months for a big UUCP site - even if the big site bought both ends of the connection! geoff steckel (steckel@alliant.com, gwes@wjh12.harvard.edu)
W8SDZ@SIMTEL20.ARPA.UUCP (06/03/87)
The USRobotics HST 9600 modem assigns the 9600 baud direction to the
end that is sending the most data. It should work fine with uucp.
Most file transfer protocols have the receiving end sending only some
kind of acknowledge or negative acknowledge (resent request) which
usually consists of only a few characters.
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZ
RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST)sl@van-bc.UUCP (06/04/87)
In article <8706030112.AA12502@mimsy.umd.edu> mgrant@MIMSY.UMD.EDU (Michael Grant) writes: >>It wouldn't surprise me if the HST becomes the defacto standard for 9600 baud. >>--Keith Petersen > >I would be surprised. Even though I usually don't require more than 300 baud >to type at a terminal, my systems support UUCP which wouldn't work very well >with 300 baud in one direction. Do these modems do some sort of flow >analys and adjust the speed accordingly? > >I feel that the only good 9600 baud modem is one that provides at least a >full 9600 baud in both directions, with NO egregious delays. > I disagree. Remember the total bandwitdh available to you must be subdivided into two channels for bi-directional use. So to get two times 9600 bps you must have an effective channel bandwitch of 19.2 kbps. Now for file transfers with 95 % of the total traffic in one direction. I would far rather take my 19.2 kpbs channel and have (for example) a 18 kbps channel for the file xfer, and 1.2 kbps for the return acks. This gives me almost double the throughput. There are very few file xfer protocols which allow simultanous bi-directional file transfers. So why waste all that bandwidth. If as I suspect, uucp acks get through on the 300 bps channel of the HST modem then it will provide about 880 cps throughput on file xfers. -- Stuart Lynne ihnp4!alberta!ubc-vision!van-bc!sl Vancouver,BC,604-937-7532
sl@van-bc.UUCP (06/04/87)
In article <521@alliant.UUCP> steckel@alliant.UUCP (Geoff Steckel) writes: >Advertisements for V.32 -->REAL 9600 BAUD FULL DUPLEX<-- modems have >been appearing in the trade press. These cost (now) between >US$1500-2500 each (not cheap! (:-) ) but should be extremely useful to >high bandwith full duplex protocol users (e.g. UUCP mailers!). > Unfortunately these are synchronous modems. I'm not sure if we can teach them to be async or uucp to be sync. -- Stuart Lynne ihnp4!alberta!ubc-vision!van-bc!sl Vancouver,BC,604-937-7532
rkh@mtune.UUCP (06/04/87)
In article <521@alliant.UUCP> steckel@alliant.UUCP (Geoff Steckel) writes: >Advertisements for V.32 -->REAL 9600 BAUD FULL DUPLEX<-- modems have >been appearing in the trade press. These cost (now) between >US$1500-2500 each (not cheap! (:-) ) but should be extremely useful to >high bandwith full duplex protocol users (e.g. UUCP mailers!). As a comparison example, the Telebit Trailblazer 'pseudo'-9600 baud modem retails for $1350 standalone. Comparison vs a V.32 modem: o It has been shown to give effective throughputs over 10Kbit/s over rather noisy lines. Fallback is in increments of < 100 bit/s, where a V.32 falls back by halving, i.e. 9600 -> 4800, etc. o The Trailblazer does internal error-correction, allowing use of lower-overhead, higher-throughput 'f' or 'e' protocols under UUCP. o The Trailblazer can act as a 103, 212, or V.22bis modem depending on the carrier received. o Hayes-compatible dialing mode allows most existing versions of UUCP to make use of it immediately. >These units are made by large, presumably experienced companies who make >modems that work. They use a CCITT standard, so are (one hopes) inter- >compatible, as opposed to the consumer type 'fake' 9600s. Since one would presumably make arrangements with one's peers for such a fast link, intercompatibility would presumably be less of an issue. Bob Halloran, Consultant, ATT ISL ========================================================================= UUCP: rutgers!mtune!rkh DDD: (201)251-7514 eve ET Internet: rkh@mtune.ATT.COM USPS: 19 Culver Ct, Old Bridge NJ 08857 Disclaimer: My opinions are my own. Quote: "No matter where you go, there you are." - Buckaroo Banzai
jackson@ttidca.UUCP (06/04/87)
We tested Concord V.32 dialup modems more than a year ago, when they were new, and they checked out clean (not very stressful tests). A bit later another group was "given" one to back up a transcontinental leased line (running bisync) and in the first week the Concords were in use continuously because (as one should plan for) the leased line had teething problems. The dialup circuit ran flawlessly. I have heard that when Codex tested their version and it proved not totally compatible with the Concord (because of an ambiguity in the CCITT spec), they actually got together and COOPERATED (!) and now at least these two vendors products will talk together. Hopefully the other vendors have followed suit (GDC, AJ, Milgo to name but a few). By the way the prices to my knowledge are in general over $3000, I think AJ is the cheapest (could be wrong of course). Some discussion about autodialler control might be in order. The vendors are going different ways. It seems to me that in an ideal world everyone would standardise on the CCITT V.25 bis standard, which covers autocalling through the (RS-232) interface for async, bisync and bit sync protocols -- but who supplies software support for this? Dick Jackson
davidsen@steinmetz.UUCP (06/04/87)
In article <8706030112.AA12502@mimsy.umd.edu> mgrant@MIMSY.UMD.EDU (Michael Grant) writes: >>It wouldn't surprise me if the HST becomes the defacto standard for 9600 baud. >>--Keith Petersen > >I would be surprised. Even though I usually don't require more than 300 baud >to type at a terminal, my systems support UUCP which wouldn't work very well >with 300 baud in one direction. Do these modems do some sort of flow Why? Are you using some huge ACK packets? 9600/300=32:1 directional bandwidth. As long as your data packets are 32 times larger than your ACK packets, you don't need 9600 both ways. Could you clarify why your uucp needs this? None of mine do. -- bill davidsen (wedu@ge-crd.arpa) {chinet | philabs | sesimo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
davidsen@steinmetz.UUCP (06/04/87)
In article <521@alliant.UUCP> steckel@alliant.UUCP (Geoff Steckel) writes: >Advertisements for V.32 -->REAL 9600 BAUD FULL DUPLEX<-- modems have >been appearing in the trade press. These cost (now) between >US$1500-2500 each (not cheap! (:-) ) but should be extremely useful to >high bandwith full duplex protocol users (e.g. UUCP mailers!). Say what? uucp (at least the sysV and BSD versions) don't seem to use bidirectional high speed. If you watch a modem running at a speed slow enough so you can see what's happening, the send channel is busy nearly 100% of the time, but the receive channel is used only for ACK packets. Because of this the USRobotics with 300 baud back channel works very nicely as far as I can see (I'm still waiting for mine). Am I missing something about uucp or are you? I'm told that using other window protocols that on long messages the line may actually turn around and send a buch of ACK packets back at 9600. This is invisible to the connected systems (except for a slight drop in throughput). The high speed to low speed bandwidth is 32:1, which should work as well as full duplex on any system which uses a reasonable packet size for send. Even window kermit, using 70 byte packets (or thereabouts) rarely turns the line around. The inherent delays at each end would leave a little slop. -- bill davidsen (wedu@ge-crd.arpa) {chinet | philabs | sesimo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
dave@lsuc.UUCP (06/05/87)
Following a review from someone on the net about 4 months ago,
I ordered a couple of Racal-Vadic 9600VP's to test. We're now
renting them and will likely purchase them shortly (most of the
rental goes against the purchase price if we do). I'm using them
right now.
From the descriptions I've read of the others on the market, none
are perfect in terms of turnaround time, which is crucial if you
need echo from your UNIX system (I do; I could run the modems in
half-duplex but I use too many applications which turn off echoing
and do their own for various reasons). The Racal-Vadics aren't
tremendous, but they're passable in this respect.
From what I understand, the R-V 9600VP, when it gets a character,
waits a bit to see if it's part of a fast stream. If it is, it
waits a bit more, then packets up and/or compresses the lot, and
then gives you a burst, which will continue if the stream keeps
coming. So "cat file", for a long file, results in a delay of
a second or two followed by real 9600-baud output without significant
subsequent delays.
Typing with UNIX echo is a bit like using a system which is thrashing
due to some kernel problem. Your character echo is a step behind you.
It takes a little adjusting to.
Where the modem is a big win is when you need to scan a lot of
material. Reading netnews is a classic example -- I can scan articles
FAR faster, though there's a delay before each article comes up in rn.
Reading email is also much more comfortable. And editing (I use qed,
an advanced line editor based on ed) is painful in some ways but
much better when it comes to filling the screen or skimming back and
forth in the material.
Conclusion: if your time is at enough of a premium and you are
willing to put up with echoing sluggishness (or run half-duplex),
the Racal-Vadic 9600VP is worth looking at. It sells for C$2000
here (before educational discount). Each.
David Sherman
The Law Society of Upper Canada
Toronto
--
{ seismo!mnetor cbosgd!utgpu watmath decvax!utcsri ihnp4!utzoo } !lsuc!davecsg@pyramid.UUCP (06/05/87)
Here's my by-now-somewhat-dated article on ultra-high speed modems, that I've sent out to various people from time to time. I hope it helps. I assume you are interested in what you can buy today for under $2000; Codex will sell you a marvelous V.32 9600 bps full duplex modem for $3500 or so.... Here's the four modems I'd suggest that you take a look at, in my order of preference. All have been demonstrated to provide dependable UUCP transfers at speeds of 750 characters per second or greater. All provide error correction. All have many quirks that are a direct consequence of their design: you really need hardware flow control; all use a packetizing strategy at high speed; you pretty much have to use the UUCP 'f' protocol or Zmodem; you must provide your own end-to-end error correction; most have gone through *many* firmware revs, so be sure to get the latest; all are incompatible with everything else. All support the Hayes command set and provide line progress monitoring. - Telebit Trailblazer ($1445). Provides Bell 103, Bell 212, V.22, V.22bis, and a proprietary multi-carrier modulation technique that dynamically adjusts the speed, based on line conditions; theoretical maximum is 18000 bps. High- speed is half duplex, with a turnaround delay that makes interactive sloppy but passable. Real data rate varies from 900 cps (California to New Jersey) to 1550 cps (locally). It can drop to 500 cps or less on really bad lines (which is still much better than the fallback of the other modems), but is otherwise generally unaffected by line noise. This is the only 9600bps voice-grade modem I've used that is dependable in- ternationally; works well to the Pacific Rim, poorly to Europe. Excellent performance with SLIP; Kermit unusable due to the packetizing. Reliable. The modem is also made by DCA under the name "Fastlink." Incidentally, the Trailblazer is also by far the best V.22bis modem I've ever tested -- even better than the AT&T 2224. Anyone looking for a really solid industrial V.22bis modem should look seriously at the Trailblazer. Telebit is also promising MNP Level 3 on the slow speeds Real Soon Now. - Racal-Vadic 9600VP ($1195). Provides Bell 103 and 212, plus 9600bps V.29 QAM half-duplex MNP level 3 (with Vadic mods). Fallback to 4800 and 2400 if line conditions are bad. In high-speed mode, the modem automatically switches be- tween 212 and V.29, depending on the amount of buffered data; interactive performance is exceptionally good. V.29 is still half duplex. Data rate is a very constant 740 cps with good lines. Sensitive to line noise. Excellent performance with SLIP, except poor with Telnet; Kermit unusable. Uucico 'g' protocol actually gets errors because of the modem's sloppy implementation of flow control. Reliable, although not as well built as the Trailblazer. - U.S. Robotics 9600HST ($999). I have not used one of these yet (I'm getting one soon) but the hearsay follows. Bell 103, 212, V.22, V.22bis; high-speed is V.32 trellis-coded 9600bps forward channel, with 7200, 4800, and 2400bps fallback, 300bps back channel, and MNP Level 3 for error correction. Inter- active performance is good. Data rate around 900cps. Extremely sensitive to line noise. Kermit is passable. Unreliable. This is a new product, and the initial units have been flakey. - Microcom AX9624 ($999). Again, I have not used one of these, although I've been satisfied with other Microcom products. Bell 103, 212, V.22, V.22bis, with MNP Level 6 that Microcom claims will get up to 19.2Kbps. Real data rates vary widely, being sensitive to the data passed, although I've never seen anyone do better than 900cps. Interactive is good. Somewhat sensitive to line noise. Kermit works OK, and even the 'g'-protocol will truck along at a reasonable clip. VERY UNRELIABLE. Every one of the half dozen people I know who have these report many DOAs (high as 75%) and many failures in use. It appears that they overheat and burn themselves out. Surprising, since the chassis is the same as for the AX2400, which was quite reliable. Possibly Microcom tried to stuff too much logic in their sealed metal box. Finally, I have a friend who swears by his Codex 208 synchronous half-duplex V.29 9600bps modems, with a $100 Inmac asynch protocol converter. Interactive is claimed to be as good as with conventional modems, since the turnaround is very fast and there is no packetizing. No error correction either, but a fair case can be made that error correction doesn't belong in the modem. These may be available used at bargain-basement prices (they list $1500 or so, but are widely used by IBM shops), so they could be just the thing for users dialing in from home. ______________________________________________________________________________ I you want to buy a modem today, I'd give the edge to Trailblazer. It is the fastest and most dependable of the ultra-high-speed modems, and also the most reliable. Interactive performance is its big weakness, although a sure typist will not be bothered. (Why the %@?&#! Telebit refuses to use just a little of that huge bandwidth for a reverse channel is beyond me.) If you insist on waiting for every character to echo, then you will be happier with the 9600VP; my *BIG* gripe with it is the lack of V.22bis. The USR 9600 HST looks like it will be good when the early production problems are shaken out, although it is much more affected by line conditions than the others. The suicidal tendencies of the AX9624 looks like a design flaw that may require major reworking by Microcom. For all these modems, there is no way of knowing whether or not they'll work from your location until you try them. These high-tech marvels are all subject to line problems and variations to which good ol' slow 1200bps modems are immune. The Trailblazer, the most technologically advanced modem anywhere, is by far the best on paper and appears to have the largest number of successes. Its design also allows most connection problems to be corrected in software, while the others may require hardware changes. (For example, our 9600VP would not work through our ROLM CBX until Vadic hand-tweaked the equalization.) In article <KPETERSEN.12307175225.BABYL@SIMTEL20.ARPA> (Keith Petersen) writes: >It wouldn't surprise me if the HST becomes the defacto standard for >9600 bps. It beats those pseudo full duplex (really half duplex) modems. Perhaps, but I doubt it and I certainly hope not. I'd really like to see modem manufacturers get off ancient analog standards and develop some modern digital encoding techniques like that used by the Trailblazer. Clearly this technology is in its infancy, but it holds great promise for all kinds of communications applications, if only a few more companies had the will to research it. What good are the current standards when different vendor's modems using allegedly identical standards won't talk to each other? Stuff 'em, and lets get on to the next generation. <csg>
ron@topaz.rutgers.edu (Ron Natalie) (06/05/87)
The 'g' protocol control packets which carry the ACK are 6 bytes long while full data packets are 70 bytes long which is just under 12:1. The real issue though is not the speed of the back channel as the ACK will cause the modem to attempt to reverse direction, hence the question really is 1. How long does it take to turn the channel around? 2. Will the delay, combined with the time it takes my system to process the data cause problems with the protocol? -Ron
beirne@chinet.UUCP (Michael G. Beirne) (06/05/87)
Sender:beirne@chinet.UUCP (Michael G. Beirne) In article <521@alliant.UUCP> steckel@alliant.UUCP (Geoff Steckel) writes: >My question - has anyone actually used a pair of these units over real >dialup phone lines, and what happened? If they work, they could pay for >themselves in about 3 months for a big UUCP site - even if the big site >bought both ends of the connection! > geoff steckel (steckel@alliant.com, gwes@wjh12.harvard.edu) The last company I worked for used the Telebit modems, which are pseudo 9600. The problem with these is that the kernal interrupts on each character received and a lot of systems cannot receive 9600 bps continously without dropping characters. When I had connected two machines together with a cable and transmitted several hundred thousand bytes overnight the throughput was ~2400 bps. The telebit modems only worked at all when we switched the interface speed down to 2400 bps. The modems packetize the data and then transmit it to the receiving modem very fast!, then check the packet on the receiving end for errors, and then spit out the data in a continous stream, then wait for the next packet. These types of modems were the only ones that we could have used, due to the time delay and line conditions between here and Japan. Any others would have caused uucp to abort due to errors. If your system can handle 1K of 9600 bps data incoming then you may have better luck than we did. Michael G. Beirne ihnp4!chinet!beirne
csg@pyramid.UUCP (06/06/87)
In article <1840@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes: >From what I understand, the R-V 9600VP, when it gets a character, >waits a bit to see if it's part of a fast stream. If it is, it >waits a bit more, then packets up and/or compresses the lot, and >then gives you a burst, which will continue if the stream keeps >coming. It is actually much simpler than that. The 9600VP idles in Bell 212A mode, full duplex. The interface is at 9600bps, though, so a burst of output will quickly fill up the modem's input buffer. When the buffer contains more than 150 characters, the modem switches to V.29 QAM half duplex, and stays there until the buffer drains. If the other modem's input buffer also fills up, they nogotiate turnarounds. The delay when "cat"ing a large file is the pause while the modem shifts gears. I don't see why David notices delays in echoing; I've experienced no such delays with our modems. <csg>
lauren@vortex.UUCP (Lauren Weinstein) (06/06/87)
Just to add a note to csg's summary of 9600 bps modems. In general, as available today in their current revisions, none of the split-speed 9600's nor the "turnaround" 9600's are currently really suitable for uucp 'g' protocol use. Other uucp protocols, such as 'x', 'f', etc., aren't really generally suitable either, since for reliable operation those protocols really want to run above other end-to-end (that's computer-to-computer, not just modem-to-modem) error checking and flow control at the hardware level, neither of which is usually present on the majority of serial port hardware and serial drivers. It is safe to assume that at least some of the modem manufacturers are aware of the "shortcomings" of their current revisions and are working toward both specific and general solutions, some of which may appear in the short term. This, combined with the general lack of compatibility between most makes of 9600 bps modems, implies that not rushing into purchases of 9600 bps modems at the present time might be the best course. --Lauren--
casey@vangogh.Berkeley.EDU.UUCP (06/07/87)
In article <KPETERSEN.12307439648.BABYL@SIMTEL20.ARPA> W8SDZ@SIMTEL20.ARPA (Keith Petersen) writes: >The USRobotics HST 9600 modem assigns the 9600 baud direction to the >end that is sending the most data. It should work fine with uucp. >Most file transfer protocols have the receiving end sending only some >kind of acknowledge or negative acknowledge (resent request) which >usually consists of only a few characters. As I understand, the Austrailian's have had a UUCP-like system (called "ASC" if I remember right - maybe someone can produce the right name for me) which tries to keep both halves of the communication channel running at speed when data is available. This of course is a big win over UUCP on communication channels which are full duplex, same speed both directions. (`ASC' apparently has/had several other features lacking in UUCP like restartable transfers) Now, a 9600/300 baud modem with the performance characteristics of the HST would probably be really nice for UUCP, but what about `ASC'? Or was ASC really just a protocol which took advantage of the hardware of the day? Or is the HST really just a modem which is taking advantage of the protocols of this day? (not including `ASC') Casey.
reid@decwrl.UUCP (06/07/87)
For about 4 years, decwrl has used Motorola/UDS 9600-A/B V.32 modems with a UDS EC-100 error controller added on. This combination gives us 9600-baud full-duplex asynchronous dialup over ordinary phone lines. I am typing this message to you over a such a modem. People in our lab have 9600-baud home terminals. We don't use them for uucp because none of our uucp partners have them, but they work beautifully and reliably and have done so for years. Brian
tankus@hsi.UUCP (06/08/87)
Hayes is now advertising a V.32 compatible modem that has ASYNCHRONOUS and
SYNCHRONOUS modes.
Cheers!
-- Ed.
Net : {noao!ihnp4!yale!}!hsi!tankus
Snail: Health Systems Int'l, 100 Broadway, New Haven, CT 06511
Bell : (203) 562-2101forrest@blia.UUCP (06/08/87)
In article <10270@decwrl.DEC.COM>, reid@decwrl.DEC.COM (Brian Reid) writes: [edited version] > > For about 4 years, decwrl has used Motorola/UDS 9600-A/B V.32 modems with a > UDS EC-100 error controller added on. This combination gives us 9600-baud > full-duplex asynchronous dialup over ordinary phone lines. > > They work beautifully and reliably and have done so for years. > > Brian I agree that these are very good modems. At a previous employee we used them for a DEC-net connection over leased lines from Santa Barbara (GTE) to San Diego (PacBell). We has absolutely no problems with them although the manuals could be clearer. I also had a very good experience with one of their support staff, Tim Blackman, who went out of his way to help solve a problem that turned out not to be caused by the modems. I should add that we didn't use the EC-100 in our application. Jon Forrest ucbvax!mtxinu!blia!forrest
stevel@dartvax.UUCP (06/09/87)
In article <KPETERSEN.12307175225.BABYL@SIMTEL20.ARPA> W8SDZ@SIMTEL20.ARPA (Keith Petersen) writes: >The US Robotics HST 9600 modem is indeed full duplex. It uses a >return channel of 300 baud, which is plenty fast enough for hand >typing from a terminal. ... >I am very impressed by the USR HST 9600 and would not hesitate to >recommend it to anyone. We tested the USR HST 9600, and came to a different conclusion. Since the return channel is only 300 bps, character echos come back at a speed that makes you think you're connected to a 600 bps line. That's running straight ASCII. Running a protocol that makes packets of characters gives you horrible echoing. The conclusion of our engineer was that a 2400 bps modem would be more useful. We're still looking for real 9600 bps modem. (So, I'll go read the rest of the articles now...) -- Steve Ligett stevel@dartmouth.edu or (astrovax cornell decvax harvard ihnp4 linus true)!dartvax!stevel
john@basser.UUCP (06/09/87)
In article <19269@ucbvax.BERKELEY.EDU>, casey@vangogh.Berkeley.EDU.UUCP (Casey Leedom) writes: > As I understand, the Austrailian's [sic] have had a UUCP-like system (called > "ASC" if I remember right - maybe someone can produce the right name for > me) which tries to keep both halves of the communication channel running at > speed when data is available. This of course is a big win over UUCP on > communication channels which are full duplex, same speed both directions. > (`ASC' apparently has/had several other features lacking in UUCP like > restartable transfers) > > Now, a 9600/300 baud modem with the performance characteristics of the > HST would probably be really nice for UUCP, but what about `ASC'? I am posting the abstract of the original USENIX article describing ACSnet below. Technical and licensing inquiries may be directed to <acsnet-request@basser.oz.AU>, seismo!munnari!basser.oz!acsnet-request. ACSnet does indeed provide restratable transfers, and as pointed out in the abstract, the software tries to use all available channel bandwidth in both directions. John Mackin, Basser Department of Computer Science, University of Sydney, Sydney, Australia john@basser.oz.AU (john%basser.oz@SEISMO.CSS.GOV) {seismo,hplabs,mcvax,ukc,nttlab}!munnari!basser.oz!john ACSnet - The Australian Alternative to UUCP Piers Dick-Lauder Basser Dept of Computer Science University of Sydney R.J. Kummerfeld Basser Dept of Computer Science University of Sydney Robert Elz Dept of Computer Science University of Melbourne ABSTRACT ACSnet is a network with goals to serve a function similar to that currently served by the UUCP network. Routing is implicit, and addressing absolute, with domains. The network daemons attempt to make use of full available bandwidth on whatever communication medium is used for the connection. Messages consist merely of binary information to be transmitted to a handler at the remote site. That handler then treats the message as mail, news, files, or anything else. Intermediate nodes need not consider the type of the message, nor its contents.
henry@utzoo.UUCP (Henry Spencer) (06/18/87)
Unfortunately, the most significant two facts about the ACSnet software
are: (1) it costs money, and therefore (2) the sites that you want to
talk to probably won't have it.
--
"There is only one spacefaring Henry Spencer @ U of Toronto Zoology
nation on Earth today, comrade." {allegra,ihnp4,decvax,pyramid}!utzoo!henry