DMG4449@RITVAX.BITNET (10/04/88)
Beware! The 9600 bps CCITT standard has not been set yet. I hear its going
to be close between USR and Telebit, not Hayes. Hayes is overpriced -
it always has, and it always will be. What good is it to have a 9600 modem
when nobody else owns it- remember: you may be able to get it for $400,
but everyone else is spending more than I spent for my computer CPU. Many
home users will turn towards the USR HST because hundreds of boards
across the nation use HST's, not to mention they are half the price of Hayes.
I think this is a cheap and desperate ploy done much too late for Hayes
to regain the market and continue to be the leader...but I for one hope
it doesn't work.
Box # 1026 Daniel M. Greenberg
25 Andrews Memorial Drive Rochester Institute of Technology
Rochester, NY 14623 Computer Engineering Technology '92
BITNET : DMG4449@RITVAX
INTERNET : dmg4449%ritvax.bitnet@CORNELLC.CCS.CORNELL.EDU
UUCP : {psuvax1,mcvax}!ritvax.bitnet!dmg4449
Compuserve : 71641,1311 GEnie: D.GREENBERG2
PHONENET : [716] 475-4295pnelson@antares.UUCP (Phil Nelson) (10/09/88)
In article <8810081712.AA14615@ucbvax.Berkeley.EDU> DMG4449@RITVAX.BITNET writes: >Beware! The 9600 bps CCITT standard has not been set yet. I hear its going >to be close between USR and Telebit, not Hayes. Hayes is overpriced - etc. etc. deleted... There is a 9600 standard, it is V.32, which Tymnet, for one, supports for dial-up access. Note that the "V.32 compatibility" which Hayes was selling the last time I checked is not compatible with Tymnet at 9600 bps, or with any of several V.32 modems which are compatible with Tymnet at 9600 bps. I have read here and elsewhere that a >9600 bps standard has not yet been decided, but is being considered. Until it arrives, V.32 is the official standard for high-speed dial up. I don't have anything against Telebit's protocol, I just want to point out that there is an existing standard out there. >Box # 1026 Daniel M. Greenberg >25 Andrews Memorial Drive Rochester Institute of Technology >Rochester, NY 14623 Computer Engineering Technology '92 > >BITNET : DMG4449@RITVAX >INTERNET : dmg4449%ritvax.bitnet@CORNELLC.CCS.CORNELL.EDU >UUCP : {psuvax1,mcvax}!ritvax.bitnet!dmg4449 >Compuserve : 71641,1311 GEnie: D.GREENBERG2 >PHONENET : [716] 475-4295 Please note: I am NOT speaking for Tymnet. -- {ames|pyramid}oliveb!tymix!antares!pnelson | Parallel IQ (the IQ of a group) OnTyme: NSC.P/Nelson POTS: (408)922-7508 | may be easily calculated given Disclaimer: Not officially representing | the IQ of each member - use the McDonnell Douglas Corporation policy. | formula for parallel resistance.
jamesd@percival.UUCP (James Deibele) (10/10/88)
In article <8810081712.AA14615@ucbvax.Berkeley.EDU> DMG4449@RITVAX.BITNET writes: >Beware! The 9600 bps CCITT standard has not been set yet. I hear its going Actually, there are several, which is part of the problem. The V.29 standard is for 9600 bps one way, or for 4800 bps both ways. The V.32 standard is for 9600 bps both ways, and is the standard people knew was coming. (I'm speaking of bps rates over dial-up lines, as opposed to data lines. A typical dial-up line has two wires, a data line four.) The "bandwidth" of a typical voice line can vary dramatically, which is why Telebits, with their 512 channels and slow rate of fallback (if the line is bad, they start tossing out channels, lowering the bps. They keep testing the line to make sure they're getting the best rate. A typical 9600 like the Courier HST or V-Series Hayes drops from 9600 to 7200 to 4800 --- and doesn't adjust back up.) are popular on intercontinental hookups. The circuitry required to stuff 9600 bps down the line while getting it back at 9600 bps is expensive, with some recent V.32 modems finally reaching the $1300- $1500 price range. The latest wrinkle is compression schemes --- MNP claims 300% compression with their advanced MNP classes (7 or 9), but many of the manufacturers don't want to use them because of licensing fees. They use their own schemes. I've heard rumors of a "V.42" which will let the modems negotiate compression schemes, but haven't seen anything in print on it. Many modems which transmit at 9600 bps claim throughput of 14,000 bps (or higher) because they use such compression. The effectiveness of the compression varies with the type of data, and it's not a "true" faster bps, but if your data tends to get there in half the time it would if it wasn't compressed, who cares? >home users will turn towards the USR HST because hundreds of boards >across the nation use HST's, not to mention they are half the price of Hayes. I have to agree with you that the HST has become a "second standard" because of the USR sysop deal. Now that there seems to be the possibility of V.32 modems dropping under $1000 (street price) by the end of the year, however, I think competition will drive the price down fast. Not so fast as I'd like, but V.32's may become the standard by the end of next year. The real problem is what do you do with 9600 bps both ways? File transfers, the most common use of BBS modems, tends to be almost exclusively a one-way affair. Many people can't keep up with 2400 bps text, they're not going to be able to read 9600 bps text. Videotext applications, such as AppleLink or Prodigy, don't need the fast baud rate in both directions; many such systems use a 1200-bps channel to provide text and video to the viewer while providing a 75-bps channel for responses. An increasing (and logical) trend is to put the images on the disk, then send a control code that tells the software to "display menu A" or whatever, which creates the illusion of fast response time. Anyway, the Hayes modem offer, unless you get an iron-clad guarantee that you can upgrade to V.32, is simply the selling-off of a failed product. Buy it if you don't mind talking at 2400 bps to all the other 9600 bps modems out there. -- James S. Deibele jamesd@qiclab or jamesd@percival TECHbooks: The Computer Book Specialists (800) TECH-BKS 3646 SE Division Portland, OR 97202 (503) 238-1005 TECHbooks One BBS (#1:105/4.0); 3/12/24 (503) 760-1473
mhyman@cup.portal.com (10/11/88)
In article <8810081712.AA14615@ucbvax.Berkeley.EDU> DMG4449@RITVAX.BITNET says: > Beware! The 9600 bps CCITT standard has not been set yet. > ... > Box # 1026 Daniel M. Greenberg > 25 Andrews Memorial Drive Rochester Institute of Technology > Rochester, NY 14623 Computer Engineering Technology '92 The 9600 bps standard has been set for quite a while. It's the V.32 standard and modems are available from Codex, UDS, Concord, NEC and others. NEC's latest offering does not cost much more than the proprietary modems. V.32 is 9600 *full duplex*. It is not compatible with any of the proprietary half-duplex or slow speed reverse channel modems. --Marc .... Marco S. Hyman mhyman@cup.portal.com ...!sun!portal!cup.portal.com!mhyman
casey@admin.cognet.ucla.edu (Casey Leedom) (10/13/88)
| From: jamesd@percival.UUCP (James Deibele) | | The real problem is what do you do with 9600 bps both ways? File | transfers, the most common use of BBS modems, tends to be almost | exclusively a one-way affair. Many people can't keep up with 2400 bps | text, they're not going to be able to read 9600 bps text. Videotext | applications, such as AppleLink or Prodigy, don't need the fast baud rate | in both directions ... There are a *LOT* of applications that need as much bandwidth as you can muster in *BOTH* directions. The Austrailian equivalent to UUCP for one (ACS?) which transfers in both directions simultaneously; running a multiplexed communication channel across a dial up link is another (ex: SLIP). Don't let a low quality communication standard cloud your view. UUCP is nice because almost everyone talks it these days, but it's not that good. Until new modems came along that mirrored UUCP's half duplex nature, it was pathetic. The Austrailian communications standard was/is much better. Casey
brad@looking.UUCP (Brad Templeton) (10/13/88)
While there are full duplex applications, I feel it is important to note that 95% of modem use is half duplex. If you have fast turnaround and/or a slow speed reverse channel, it is much more useful to get twice the bit rate half duplex than a mostly wasted half bandwidth rate in full duplex. -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
henry@utzoo.uucp (Henry Spencer) (10/14/88)
In article <16738@shemp.CS.UCLA.EDU> casey@cs.ucla.edu (Casey Leedom) writes: > There are a *LOT* of applications that need as much bandwidth as you >can muster in *BOTH* directions. The Austrailian equivalent to UUCP for >one (ACS?) which transfers in both directions simultaneously... However, you can turn this argument around: the Australian networking stuff exploits both directions on the theory that both are usually there. That arguably was an artifact of the modem technology of the time. The biggest (in terms of volume) application for uucp et al is news transfer, which is usually *highly* asymmetrical and cannot fully use a symmetrical path. For that application, it is not merely okay but *better* to have a half-duplex channel running twice as fast. > running a >multiplexed communication channel across a dial up link... This again depends on how that channel is being *used*. The one significant win of a full-duplex path is in applications that care about response time rather than throughput. The obvious case is humans typing. A less obvious case is a lot of network protocols. But if what you're doing is bulk file transfer and your protocol is prepared to cope with long ack delays, there really is no advantage to full-duplex communication if it means that you take a factor-of-2 speed hit. >... Until new modems came along that mirrored UUCP's half duplex >nature, it was pathetic... I have news for you: fast half-duplex modems considerably pre-dated fast full-duplex modems, for quite fundamental reasons. They've only recently gotten popular in the uucp world, but occasional groups have (I'm told) been using them for uucp for a long time. -- The meek can have the Earth; | Henry Spencer at U of Toronto Zoology the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu
casey@admin.cognet.ucla.edu (Casey Leedom) (10/14/88)
| From: james@bigtex.cactus.org (James Van Artsdalen) | | Is the Australian driver a public domain thing that can be dropped into | existing uucico's in the US for use? It's not a driver, it's a system like UUCP. I'm not at all sure that it would even be possible to hack a driver together for UUCP that would support their protocol since ACS (again, I'm guessing at the name) transfers bidirectionally. At some point or another uucico would be forced to receive data while it was transmitting. I think you'd have to rip uucico up pretty badly ... But it would certainly be an interesting project. You can probably get information about ACS from Robert Elz (kre@munnari.oz.au). If he doesn't have it himself, he will certainly be able to point you at someone who can. Casey
casey@admin.cognet.ucla.edu (Casey Leedom) (10/14/88)
| From: brad@looking.UUCP (Brad Templeton) | | While there are full duplex applications, I feel it is important to note | that 95% of modem use is half duplex. If you have fast turnaround and/or | a slow speed reverse channel, it is much more useful to get twice the bit | rate half duplex than a mostly wasted half bandwidth rate in full duplex. So modems should automatically adapt to the amount of traffic flowing in *BOTH* directions rather than trying to enforce one model or the other. All you need is the ability to parameterize the hysteresis function for odd-ball applications. Most of the time this can be done automatically too. It seems to me that a modem like the Telebit which breaks the communication channel into a large number of sub-com channels would be perfect for this. Henry's follow up to my comments were as one sided as my original message. Half duplex is not the answer. Full duplex via dedicated half band width implementation is not the answer. Full duplex via adaptive channel bandwidth allocation is what you want. Casey -------- The American public wants to be lied to. They want to be told that they are the envy of the world. They want to be told that things are ok. Dukakis points at the serious problems that must be addressed and proposes some of the hard decisions that he thinks will be necessary. Bush tells us that everything is wonderful. Who's ahead in the polls?
brad@looking.UUCP (Brad Templeton) (10/15/88)
Unfortunately, it seems that full duplex through adaptive bandwidth splitting is hard. I think the best answer is quick switchable "mostly half" duplex, fast enough to simulate adaptive splitting. By "mostly half" duplex, I mean the scheme that is 18000 bps one way and about 300 bps the other way. -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
james@bigtex.cactus.org (James Van Artsdalen) (10/16/88)
In article <16738@shemp.CS.UCLA.EDU>, Casey Leedom writes: > There are a *LOT* of applications that need as much bandwidth as you > can muster in *BOTH* directions. Actually, I would not be so sure of this. Certainly human usage to call up BBSs or download/upload data don't require symetric transfers by any stretch of the imagination. As for machine to machine links, almost none of my uucp links on bigtex are symetric. It seems particularly clear that V.32 connections would be slower than PEP for all but two links, since only a couple of links ever show much symetry at all. For SLIP types applications I imagine things average out to make the data transfers more symetric (particularly given TCP/IP's high overhead), but even Internet applications such as rlogin, sendmail and ftp are fundementally very asymetric (even though I understand current implementations of these may not be). > Don't let a low quality communication standard cloud your view. UUCP > is nice because almost everyone talks it these days, but it's not that > good. Until new modems came along that mirrored UUCP's half duplex > nature, it was pathetic. Actually, UUCP 'g' does much better with normal 2400bps/1200bps modems than do Xmodem or Kermit. I assume this is also true on V.32 modems. It's not Zmodem and it's not a full-duplex protocol, but it seems to work well... Xmodem and Kermit are almost useless over PC Pursuit (which acts half duplex), whereas UUCP 'g' can get 50% throughput. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Home: 512-346-2444 Work: 338-8789 9505 Arboretum Blvd Austin TX 78759
dave@arnold.UUCP (Dave Arnold) (10/16/88)
james@bigtex.cactus.org (James Van Artsdalen) writes: > Actually, UUCP 'g' does much better with normal 2400bps/1200bps modems > than do Xmodem or Kermit. I assume this is also true on V.32 modems. > It's not Zmodem and it's not a full-duplex protocol, but it seems to > work well... Xmodem and Kermit are almost useless over PC Pursuit (which > acts half duplex), whereas UUCP 'g' can get 50% throughput. Okay, somebody tell me why Zmodem is better than UUCP's 'g'? Given a window size of 7, and large packet sizes, and 'g's small 6 bytes header... What makes Zmodem better than 'g'? Let's clear this up once and for all. -- Dave Arnold (dave@arnold.UUCP) Work: Volt Delta Resources Phone: (714) 921-7635 Home: 26561 Fresno street, Mission Viejo, Ca 92691
ron@hardees.rutgers.edu (Ron Natalie) (10/16/88)
Nope, full duplex via having enough bandwidth to push equal size channels in both directions is what I want. It's called V.32.
pozar@hoptoad.uucp (Tim Pozar) (10/17/88)
In article <218@arnold.UUCP> dave@arnold.UUCP (Dave Arnold) writes: >james@bigtex.cactus.org (James Van Artsdalen) writes: >> Actually, UUCP 'g' does much better with normal 2400bps/1200bps modems >> than do Xmodem or Kermit. I assume this is also true on V.32 modems. >> It's not Zmodem and it's not a full-duplex protocol, but it seems to >> work well... Xmodem and Kermit are almost useless over PC Pursuit (which >> acts half duplex), whereas UUCP 'g' can get 50% throughput. > >Okay, somebody tell me why Zmodem is better than UUCP's 'g'? >Given a window size of 7, and large packet sizes, and 'g's small >6 bytes header... What makes Zmodem better than 'g'? > >Let's clear this up once and for all. UUCP 'g' is NOT better. 64 byte packets, widowing of say at max 7, and with either satilite delays or funky modem turnarounds like HST or Telebits (UUCP spoofing turned off), ZMODEM is far better that UUCP 'g'. Zmodem can also pick up in the middle of a file if the connection was lost. Tim -- ...sun!hoptoad!\ Tim Pozar >fidogate!pozar Fido: 1:125/406 ...lll-winken!/ PaBell: (415) 788-3904 USNail: KKSF / 77 Maiden Lane / San Francisco CA 94108