root@conexch.UUCP (Larry Dighera) (11/02/88)
In article <10711@cup.portal.com> David@cup.portal.com (David Michael McCord) writes: >I don't know why this conference isn't named comp.dcom.telebit-lovers. It >ought to be. Until now, the Telebit modem has been the only _inexpenxive_ high speed modem available that would support the uucp protocol. I see that as the chief reason for it being embraced so keenly here. >The Telebit >product does not even support synchronous transmission, not to mention the >disadvantages of getting yourself locked into a modem vendor's proprietary >modulation technique. Agreed. Being locked into a proprietary modulation scheme is a mistake. Sites with Trail Blazers will find the high speed capability of their modems useful only for communication with others who jumped at the Telebit half price offer. Now that the new Rockwell V.32 chipset is available, there is little doubt that cheap _Full-Duplex_ 9600 bps modems will begin to dominate the marketplace. Better technology always supplants inferior technology, if it is affordable. (have you noticed the price of 300 baud modems today.) Unfortunately, Half-duplex Trail Blazers are the defacto standard for moving news. That is going to retard the rate of acceptance of V.32 modems among UNIX (tm) usenet sites. >if you invest in Telebit or USR, you are throwing your money away. Although this is a bit of an over simplification of the situation, I basically agree. The exception being the site which pays long distance telephone charges and dedicates the Trail Blazer to moving news. Those sites have probably paid for their Trail Blazers in lower phone charges. But, the sites which intend to user their Trail Blazers for general world wide communications are going to be disappointed. >Speaking as a data and voice telecommunications professional with many years >of experience and the salary to back it up, I say that V.32 modems are going >to smash the vendor-proprietary types in the marketplace within a year. Why? > >if you invest >in V.32, you are still going to be able to use it five years from now; long >after the HST and Telebit schemes fade away and disappear due to lack of >market support. Agreed. I hear Fastcomm has recently introduced a V.32 modem with a list price of ~$700. That should start the V.32 ball rolling. >The USENET community has done itself a disservice to let itself fall into the >trap it is now in. It should be fun to watch as you netadmin types have to >replace your equipment with new modems, be they V.32 or whatever PEP >variation is officially adopted by the CCITT (hint: it will not be compatible >with your current Trailblazers). I am glad I am not going to have to stand >up in front of my managers and ask for more money to redress my past bad >decisions. I would be very interested in a more detailed explaination of this "hint". I have heard that Telebit and USR are jointly proposing one standard to the CCITT which will support both of their modulation schemes. I hadn't heard that it wouldn't be compatible with current PEP modulation, as you imply. Larry Dighera -- USPS: The Consultants' Exchange, PO Box 12100, Santa Ana, CA 92712 TELE: (714) 842-6348: BBS (N81); (714) 842-5851: Xenix guest account (E71) UUCP: conexch Any ACU 2400 17148425851 ogin:-""-ogin:-""-ogin: nuucp UUCP: ...!uunet!turnkey!conexch!root || ...!trwrb!ucla-an!conexch!root
brad@looking.UUCP (Brad Templeton) (11/05/88)
I would rather a modem that is 1400 bytes/second one direction and 100 bytes/second in the reverse direction than one that is 960 bytes/second in both directions. (Is V.32 error free at 9600 bps, or are the error protocols layered on top of a 9600 bps base rate?) I have never had an application that called for 9600 bps in both directions. Many people are in the same boat. Rather than V.32 supplanting PEP, it might be the other way around. People will eventually go to whatever is fastest. And what about PEP with echo suppression? What could *that* do? -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
ssd@sugar.uu.net (Scott Denham) (11/05/88)
In article <11136@conexch.UUCP>, root@conexch.UUCP (Larry Dighera) writes: > In article <10711@cup.portal.com> David@cup.portal.com (David Michael McCord) writes: > >The Telebit > >product does not even support synchronous transmission, not to mention the > >disadvantages of getting yourself locked into a modem vendor's proprietary > >modulation technique. > > Agreed. Being locked into a proprietary modulation scheme is a mistake. > Sites with Trail Blazers will find the high speed capability of their > modems useful only for communication with others who jumped at the > Telebit half price offer. Now that the new Rockwell V.32 chipset is > >if you invest in Telebit or USR, you are throwing your money away. > In all this discussion of getting "locked in" to a proprietary modulation scheme, I don't think much attention is being paid to the MANY commercial sites that use dial-up links to connect specific offices at irregular intervals for relatively short periods of time. We don't really CARE who else is compatible with the modem we are using - in fact in one sense a proprietary modulation scheme serves as an additional security level. We have used a TB+ set up to work ONLY at PEP speeds for exactly that reason. As long as the vendor still supports the product (or at least the modulation scheme), and the performance is comparable to that of a "standard" scheme (at least in the mode you intend to use it, E.G. traffic that is essentially one-way) there is no DISadvantage to using the TB or whatever, so if there are price or performance or availablitly advantages to a proprietary scheme, nobody's going to get fired or even criticized for choosing the product best suited to the task at hand at the time. I suspect there are enough applications like this to keep the TB happily afloat regardless of what might happen in the "standards" world. Remenmber not ALL modems are used for BBS's or big networks!! Scott Denham Western Atlas International **** Anything above resembling an opinion is purely coincidental, and is the sole responsibility of the author ***
David@cup.portal.com (David Michael McCord) (11/05/88)
First of all, I knew that I was going to get flamed by posting opinons rather divergent to the opinions of the majority in this group. Some of the flames were rather amusing, such as the non sequitur character aspersions because I post from Portal, the conclusion I work for ROLM (not true), confusing higher-level applications such as MNP with modulation techniques, etc. However, I see no need to encourage such behavior and will refrain from responding to it in the future, even in the subdued fashion represented by this paragraph. Second, the stated purpose of my original posting was to express a dissenting (and admittedly minority) opinion about "Which is Best?", and that is all I have done. I am suprised and pleased by the quantity of insightful commentary (and unfortunately, useless drivel) that has been generated. Third, I can see how my first posting could give the impression that my point was something like "Don't EVER use Telebit or HST!". That is not exactly correct. I can and will concede that there may be adequate business cases for using vendor-proprietary hardware in certain situations. However, such a business case also carries with it significant disadvantages related to interoperability and market support. These disadvantageous factors do not easily translate into dollars and cents, and when they do, their value will vary depending on circumstances. In a small business or closed-end applications, the value of global interoperability and market support may be virtually nil; in a large multinational corporation or public access application the value of these same items will be very high. In my opinion, USENET news distribution is obviously a global, public access application. The negative dollars and cents value of using a nonstandard medium for distribution is being ignored if all that is compared is the price of the modems. The same is true of bulletin boards, Telenet, etc. I still think you guys have made a big mistake. David@cup.portal.com
lindsay@dscatl.UUCP (Lindsay Cleveland) (11/06/88)
One of the reasons people want the V.32 synchronous 9600-baud
capability is for multiplexing purposes, i.e. one phone line used
to support ~4 or more terminals. Well, it seems the Trailblazer's
PEP mode *can* be used in a multiplexing setup!
I have not played with the hardware, merely done some checking
around. Here are the numbers:
"Usual" MUX environment:
$1800 2 4-port MUX'es
$3200 2 v.32 synchronous modems
$ 200/month leased line
Using TB+
$3200 2 5-port MUX'es
$4400 2 TB+'s
no monthly leased line charge
The folks with the multiplexers who have actually run them using
TB+'s are:
Backus Data Systems
(408) 279-8711
The fellow I spoke with at Backus was Jim Tramalini. He seemed to
know what he was talking about.
The prices above are obviously going to be different for each
site...especially the TB+ prices if you got yours already in the
special 2-for-1 deal from Telebit.
(disclaimer: I'm in no way connected with Telebit or Backus...just
a happy Trailblazer user)
Cheers,
Lindsay
Lindsay Cleveland Digital Systems Co. Atlanta, Ga
gatech!dscatl!lindsay (404) 497-1902
(U.S. Mail: PO Box 1140, Duluth, GA 30136)evan@telly.UUCP (Evan Leibovitch) (11/07/88)
In article <11136@conexch.UUCP>, root@conexch.UUCP (Larry Dighera) writes: > > Until now, the Telebit modem has been the only _inexpenxive_ high speed modem > available that would support the uucp protocol. I see that as the chief > reason for it being embraced so keenly here. If you had looked much beyond Usenet, you'd also see that most non-Unix BBS systems have also decided against V.32, but instead of the Telebit chose the USRobotics HST. USR, apparently, did a deal for FidoNet similar to the one Telebit did for us. Though I don't have the numbers, it appears that these two modems, between them, have a very strong hold on on-line services. Buy a V.32 modem, and see how many public services you can talk to at >2400 baud. > Now that the new Rockwell V.32 chipset is > available, there is little doubt that cheap _Full-Duplex_ 9600 bps modems > will begin to dominate the marketplace. Better technology always > supplants inferior technology, if it is affordable. (have you noticed > the price of 300 baud modems today.) The jury is still out on whether these yet-non-existant cheap V.32 modems will have superior specs to the 'Blazer. How can you be so cocky touting the merits of modems which nobody has seen? In the meantime, the T1000 has dropped the PEP admission fee significantly. > Unfortunately, Half-duplex Trail Blazers are the defacto standard for > moving news. That is going to retard the rate of acceptance of V.32 modems > among UNIX (tm) usenet sites. Until you can prove how V.32 is NOW a better way of moving Usenet news, I see no reason to consider this unfortunate. And with Telebit and USR working on a CCITT proposal for a standard which would include BOTH the PEP and HST ways of moving data, we could have a "standard" which would have not only good technology, but a far bigger installed base than anything else. > >if you invest in Telebit or USR, you are throwing your money away. > > Although this is a bit of an over simplification of the situation, I > basically agree. The exception being the site which pays long distance > telephone charges and dedicates the Trail Blazer to moving news. Those > sites have probably paid for their Trail Blazers in lower phone charges. > But, the sites which intend to user their Trail Blazers for general > world wide communications are going to be disappointed. Many of the other sites I wanted to talk to already had Telebits. I wanted to talk to them at high speeds. I have not been disappointed. It is the V.32 modem which would have left me isolated had I chosen one. Sites which want to talk to my site are buying Telebits. Telebits let me talk to the sites I need to talk to at high speeds. Tell me how V.32 will change that for the better. > >The USENET community has done itself a disservice to let itself fall into > >the trap it is now in. It should be fun to watch as you netadmin types have > >to replace your equipment with new modems, be they V.32 or whatever PEP > >variation is officially adopted by the CCITT(hint: it will not be compatible > >with your current Trailblazers). As long as the sites I talk to don't trash their Telebits, I won't be trashing mine. A "trap" I can live with quite nicely, thank you. > I would be very interested in a more detailed explaination of this "hint". From what I've heard from a couple of sources (including someone at the Telebit booth at UNIXExpo last week), I think the HST-Telebit proposal would make the HST scheme mandatory and PEP optional, with connect-time negotiation to determine which one is to be used. I am told that current Trailblazers will NOT be ROM-upgradable to handle the combined standard, though they will be able to talk to any new modems which have the PEP support. I believe Telebit may also be close to pushing PEP >22,000 pre-compression bps. Where is the V.32 superior technology? P.S. I do not speak for Telebit. I am, however, tired of consultants telling me my equipment is obsolete when they haven't seen the replacement. Old end-user joke: How can you tell when a consultant is lying? His lips are moving. -- Evan Leibovitch, SA of System Telly If Jesus was a Jew Located in beautiful Brampton, Ontario, Canada how come he had evan@telly.on.ca -or- uunet!attcan!telly!evan a Mexican name?
jpdres10@usl-pc.usl.edu (Green Eric Lee) (11/08/88)
In article <10881@cup.portal.com> David@cup.portal.com (David Michael McCord) writes: >First of all, I knew that I was going to get flamed by posting opinons rather >divergent to the opinions of the majority in this group. Some of the flames OPINIONS is the operative word. Opinions can be held by many, but facts are a rare bird indeed. >higher-level applications such as MNP with modulation techniques, etc. The PEP modulation technique used by Telebit automatically adjusts to line quality, which V.32 does not. I believe this is what people were referring to when they noted the superior error handling of the Telebit when compared to current V.32 modems. >business case also carries with it significant disadvantages related to >interoperability and market support. These disadvantageous factors do not Interoperability: "Will it work with the systems that I want to call?" For dedicated UUCP file-transfer use, the answer is "Yes" for Telebit, and "No" for V.32. For other applications (e.g. general telecommunications use, dial-in modems, etc.), the answer may very well be different. Market support: Many large corporations put large emphasis on "market support", even to the extent that they will only buy IBM equipment because IBM is the largest computer company. Never mind that the equipment is useless for the suggested application. Buy it. In large part, that's how the University of SW Louisiana ended up with a godaweful IBM 3090 mainframe. Don't get me wrong, the 3090 is a nice machine -- for its intended application (large databases, medium-scale scientific applications). But as an instructional machine, it is a nightmare, to such extent that the majority of classes are conducted on Unix-based machines such as the Pyramid 90x that I'm typing this from. There is rarely more than 40 people logged into the 3090. Of course, one reason for our problems with IBM is interoperability -- all our machines are accessed via a campus-wide network, meaning that one has to use a 7171 protocol converter and ordinary ASCII terminals with the 3090. That is extremely painful. Using Xedit, one has to do all sorts of alt-cokebottle-foo combinations, and 9600 baud page refreshes crawl. But market support, y'know... who cares if it's not easily interoperable with the majority of solutions used for the intended application? In any event, this is a typical example of corporate-style thinking about market support ("The majority of applications are on IBM, so we'll get the biggest baddest IBM machine possible") resulting in an inappropriate choice for the intended application (research and instruction). Such thinking is one of the reasons that U.S. corporations are going down the drain compared with their Japanese equivalents... new technology doesn't have "market support", so obsolete or inappropriate technology is substituted instead. >In my opinion, USENET news distribution is obviously a global, public access >application. The negative dollars and cents value of using a nonstandard >medium for distribution is being ignored if all that is compared is > the price >of the modems. The same is true of bulletin boards, Telenet, etc. USENET news distribution is inherently different from bulletin boards, Portal, Telenet, etc. Modems for USENET news distribution are generally dedicated to that single purpose. Modems which do UUCP spoofing and which allow speeds of up to 19,200 baud are quite useful for this single purpose (UUCP file transfers). Thus, the majority of 9600-baud-or-faster UUCP sites are running Telebit (or equivalent) modems (thus smashing your "interoperability" argument to pieces). If such modems cost half of what slower 9600 baud modems cost, that is only an additional argument in favor of what is simply the most appropriate technology for the application. >I still think you guys have made a big mistake. Only if they put Telebit modems on dial-ups... interoperability, y'know (most people are using HSTs or, soon, V.32, for such general-purpose applications). Using Telebit modems for a single dedicated application, on the other hand (UUCP file transfer), makes quite a bit of sense. -- Eric Green {ames,mit-eddie,osu-cis,...}!killer!elg, killer!usl!elg, etc. P.O. Box 92191, Lafayette, LA 70509
mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield) (11/09/88)
In article <11136@conexch.UUCP>, root@conexch.UUCP (Larry Dighera) writes: > Now that the new Rockwell V.32 chipset is > available, there is little doubt that cheap _Full-Duplex_ 9600 bps modems > will begin to dominate the marketplace. Better technology always > supplants inferior technology, if it is affordable. (have you noticed > the price of 300 baud modems today.) Oh yeah? Then why are we all still stuck with brain-dead intel chip archetectures. Reason - Itsey Bitsey Machine Corp made it the overwelming defacto standard inspite of better technology (and NO I AM NOT just harping on the old 68xxx arguement). > Unfortunately, Half-duplex Trail Blazers are the defacto standard for > moving news. That is going to retard the rate of acceptance of V.32 modems > among UNIX (tm) usenet sites. Why should any usnet administrator (and yes I am one for a large LAN) stoop to degrading his network performance, increase his phone bills, and reduce his connectivity just for the sake of the almighty "v.32" standard. I think I'm no exeception in saying that my Telebit doesn't owe me a nickel! Even if the thing died today I would be still miles ahead in operating costs and I would buy another in a heartbeat! BTW: I also have a HAYES v9600 on site. While it does nothing to improve my network news performance it does improve my connectivity to some select sites. So, I'm not a "Telebit" fanatic it's just that the Telebit is vastly superior to anything on the market today or in the forseable future for getting MY JOB DONE. Until the "standard" can improve upon what we have, there is no sense in changing. Even if v.32 can equal the Trailblazer+ (which has yet to be proven and is hottly disputed) I can hardly see where v.32 is going to be cost justifiable anytime soon. i.e. It's going to cost me money and give me nothing!). --- Michael H. Warfield (The Mad Wizard) | gatech.edu!galbp!wittsend!mhw (404) 270-2123 / 270-2098 | mhw@wittsend.LBP.HARRIS.COM An optimist believes we live in the best of all possible worlds. A pessimist is sure of it!
rwhite@nusdhub.UUCP (Robert C. White Jr.) (11/10/88)
in article <407@telly.UUCP>, evan@telly.UUCP (Evan Leibovitch) says: > The jury is still out on whether these yet-non-existant cheap V.32 modems > will have superior specs to the 'Blazer. How can you be so cocky touting > the merits of modems which nobody has seen? > > Telebits let me talk to the sites I need to talk to at high speeds. > Tell me how V.32 will change that for the better. > Where is the V.32 superior technology? Having seen/dealt with the V.32 modem at this years TCA convention (which was held in San Diego last month or so) I will now degin to discorse (;-) what the V.32 technology will get you over the Trailblaizer Technology (and vice versa.) V.32 is real(tm) full-time-full-duplex while the PEP system is "negotiated" (my word) full-duplex. In order to get the full 19.2 capacity of a PEP modem you must be able to drop full >3K data streams into the modem all at one time. If you do not drop these huge packets into the modem (or stream many small packets through a large verify window) you will pay turnaround penalities for each packet. To address this, Trailblaizer et. al. started something called protocol-spoofing (most of you know this, but that is for those who didn't). By spoofing a protocol, the modem at each end pretends that it is the distant computer (as far as the protocol is concerned) and simply varifies each packet, and then loads up its own buffer with the data and transmits it using its own protocol. Both ends of the line preform in the same manner. Without spoofing, you might as well have a 1200 (your mileage may vary ;-) baud modem for small packet protocols. Spoofing has several major drawbacks to PEP. 1) Both modems must be programmed to spoof the desired protocol. This implies that "new protocol => new ROM" which can cost you big time, or not be available. 2) Complex pick-up-where-you-left-off type protocols may fail (depending on the spoofing implementation) completely around connect interrupts because computer A knows that packet 2346 got through while computer B never even got 2331, so second call recovery will have a bitch of a time re-sync(ing). 3) Because of point 1, the modem's longevity is tied directly to the manufacturers support and longevity. Why the same draw-backs do not apply to V.32. 1) V.32 is full-time-full-duplex. The same preformance is provided to transporting 1 character as 1,000,000 (per capita) 2) Point 1 makes any protocol concerns (as far as the modem is concerned) moot. e.g. if your software will do it your modem will do it. 3) V.32 contains satalight silencing and crosstalk compensation consistent with international standards. 4) V.32 modems are "transparent, non-intrusive" carriers so they will not interfere with real-time opperations. (encoding and such) NONE of these points will bother any installed base of PEP modems, but the installed base of PEP modems will have its growth stunted. Many large institutions have avioded PEP modems and simply waited for V.32. (Yes, like us, the third largest private instutition of higher learning in the state of california). PEP 19.2 vs V.32 9600 only apears to be a 2-to-1 speed difference, agregate throughput discounts the PEP substancially (for many applications I can think of) towards V.32. Since V.32 does not lock us into any one company or into current technology. If you look to the immeadite future, you will see the re-working of many protocols threatening your horizions. (see "tar wars" and uucp "e" protocol, and "dart," and "gossip," and ...) You may see (depending on who you are) that buying a PEP modem is buying into a dead end street (now). Your installed base may go beyond a "growth slowdown" and start to actually shrivel up. Can't you see the promotions now. . . . [ (in my best political/beer-comercial voice: "Turn in that old PEPless horse, and go with a *standard*, catch the (square) wave; V.32"] ;-) Disclaimer: Ignore the typos and spelling errors; I am being harried right now and this disclaimer is "more expedient" (faster? now where have I heard that before?) than a proofread. Rob.
ron@ron.rutgers.edu (Ron Natalie) (11/10/88)
If we are talking about the 8088 when you mentioned brain damaged Intel chips, the reason you're stuck with it is because IBM pushed it not Intel. Intel has one of the weakest marketing strategies I've ever seen. -Ron
rwhite@nusdhub.UUCP (Robert C. White Jr.) (11/11/88)
in article <2261@looking.UUCP>, brad@looking.UUCP (Brad Templeton) says: > I would rather a modem that is 1400 bytes/second one direction and 100 > bytes/second in the reverse direction than one that is 960 bytes/second > in both directions. (Is V.32 error free at 9600 bps, or are the error > protocols layered on top of a 9600 bps base rate?) The problem is that the 1400/100 must REVERSE on directive reversal of base data. Any protocol not "spoofed" which "waits for ACK" will trigger TWO FULL TURNAROUNDS PER PACKET. (what is that under PEP? 20 carriers? twice.) The turnaround delay (with retraining?) will introduce more of a delay than the 960/960 standing rate. The equation is aproximately: ( PACKETS / WINDOW SIZE) * 2 turnarounds per transfer, with accuracy of the above increasing proportionally to the decrease in backet size. Mind you, this is only for non-spoofed protocols. > I have never had an application that called for 9600 bps in both > directions. Many people are in the same boat. Rather than V.32 > supplanting PEP, it might be the other way around. People will > eventually go to whatever is fastest. Not so true as you might think; to whit: (non spoofed of course) Any small packet protocol. Any truely intelegent workstation. (just picture yourself at home with a DMD/programable terminal preforming emacs-style functions at home. downloading huge files for editing while the ones you just finished with are being uploaded back, etc.) Any "open-channel" bridging. Any environment server (X-windows? NeWS?). Any "secure" connection. Any real-time remote service. (remote lab monitors et. al.) or any other high-density biderectional traffic you can care to think of, which requires a protocol. True, uucp and usenet, as they exist today (and most hobbiest-level bbs up- down-load type transactions) do not take advantage of high-density bidirectional traffic to remote sites (simply because it didn't exist). Having seen the future in these areas, and knowing that someone will eventually decide that dialup connections which move large data-groups should be made concurent to reduce connect time. Things like mikenet will become practical over X.25 international links; and inter-backbone (not necessarily usenet!) transfers over dialup lines (think insurance companies and auto clubs and ...) I think you may be unpleasantly supprised in the not so distant future. > And what about PEP with echo suppression? What could *that* do? What?? (I may be wrong about this one, but...) If I recall corectly there are aproximately the same type of carrier matrx involve in both PEP and V.32. (both are obviously echo-supressed, and the use about the same number of carriers. V.32 simply has had the troublesome turnaround whathaveyou excluded, and implements different carrier frequencies so as to pass through international systems with less friction. This may be a dreadful over-simplification, but it does apply in essence.) Rob.
dlr@daver.UUCP (Dave Rand) (11/11/88)
In article <1245@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: > PEP 19.2 vs V.32 9600 only >apears to be a 2-to-1 speed difference, agregate throughput discounts >the PEP substancially (for many applications I can think of) towards >V.32. This is the difference between a $500/mo and a $1,000/mo. Or $50 and $100. Or whatever you want to make it. I _know_ my telebits have paid for themselves. Even if I scrap them, like the (multiple) 300 bps modems I had. And the (multiple) 1200 bps modems. And the (multiple) 2400 bps modems. Technology continues, and we will _all_ scrap these modems, sooner or later. -- Dave Rand {pyramid|hoptoad|sun|vsi1}!daver!dlr
prc@ERBE.SE (Robert Claeson) (11/11/88)
In article <1245@nusdhub.UUCP>, rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: > PEP 19.2 vs V.32 9600 only > apears to be a 2-to-1 speed difference, agregate throughput discounts > the PEP substancially (for many applications I can think of) towards > V.32. I've got some info on the new V.32 modem from Microcom. It has MNP Class 9, and can give a throughput of c. 30 kbit/sec. -- Robert Claeson EUnet: rclaeson@erbe.se Smart ARPAnet: rclaeson@erbe.se Dumb ARPAnet: rclaeson%erbe.se@uunet.uu.net
mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield) (11/12/88)
In article <Nov.10.07.42.52.1988.10788@ron.rutgers.edu> ron@ron.rutgers.edu (Ron Natalie) writes: >If we are talking about the 8088 when you mentioned brain damaged Intel >chips, the reason you're stuck with it is because IBM pushed it not Intel. >Intel has one of the weakest marketing strategies I've ever seen. Of course - That's why I refered to Itsey Bitsey Machine Corp ( >I<tsey >B<itsey >M<achine ). And I was including its successors as well (286 & 386). --- Michael H. Warfield (The Mad Wizard) | gatech.edu!galbp!wittsend!mhw (404) 270-2123 / 270-2098 | mhw@wittsend.LBP.HARRIS.COM An optimist believes we live in the best of all possible worlds. A pessimist is sure of it!
mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield) (11/12/88)
In article <1245@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >....... PEP 19.2 vs V.32 9600 only >apears to be a 2-to-1 speed difference, agregate throughput discounts >the PEP substancially (for many applications I can think of) towards >V.32. Yeah is probably closer to 3-1 than 2-1. Whatever arguements you want to come up with, the bottom line is that the MEASURED agregate through-put for uucp is substantially higher with uucp spoofing. Without it your pissing into the wind at any baud rate. And full duplex doesn't buy uucp anything. You're right about the protocol spoofing requiring match-ups at both ends and enhancements being a hassle, BUT at 2-4 Meg per link per day on uucp I don't want that trailblazer screwing around with anything else. Let it do it's job doing what it does best. I would never buy one for a BBS or for interactive use but you still can't beat it in a fair fight on uucp (or even an unfair fight). >....... that buying a PEP modem is buying into a >dead end street (now). Your installed base may go beyond a "growth >slowdown" and start to actually shrivel up. What is a dead end street is wasting money waiting for a promise that has yet to appear. Even if something new came along today and totally blew away the Trailbazers so completely that all of usnet changed over, this one is still totally paid for! The dead end street would be to continue to pay higher phone bills waiting for a pipe dream to come true. Ignoring state of the art now (current Trailbazers) just because you see something better down the road is a never ending death trap. There will always be something better down the road. As far a my installed base going into a "growth slowdown", my limiting factor is the power of my mini not my modem capacity. I can feed more data down that Trailblazer than I can store in my spool directories. I have opennings on GALBP for more news sites but I won't lose any sleep if I don't get another. I have enough work as it is that I get paid for, I really don't need to be donating more, thank you. ---- Michael H. Warfield (The Mad Wizard) | gatech.edu!galbp!wittsend!mhw (404) 270-2123 / 270-2098 | mhw@wittsend.LBP.HARRIS.COM An optimist believes we live in the best of all possible worlds. A pessimist is sure of it!
njs@scifi.UUCP (Nicholas J. Simicich) (11/12/88)
In article <1245@nusdhub.UUCP>, rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: (portions deleted...) > V.32 is real(tm) full-time-full-duplex while the PEP system is > "negotiated" (my word) full-duplex....... Interesting point. Now, there are two reasons that a modem like a Trailblazer is slower in "negotiated" full duplex mode. One is the fact that if it is transmitting, it can't be receiving (hmmm...I think the same is true of my Unix application, unless I do complex things with multiple processes and IPC) while the other thing is that when you write to the modem it must wait a short period of time before it decides that no more characters are coming and closes the packet with a CRC. Furthermore, there is an additional effect. Modems running MNP at any speed must collect a full MNP packet, internally, and decide that they have it correctly before they can transmit any of it to the attached computer. At least, this seems to be true through level 3. You might tell me that MNP is optional for a V.32 modem. I consider this to be a drawback, not a benefit. Because all MNP negotiation is done in band, and because we still have modems that are not MNP, and are attached to programs that get confused by the MNP protocol, I have to keep it turned off for all calls we make. If it were not optional, or if the negotiation was done out of band as the PEP protocol does, I'd be a lot happier. (For all I know, the PEP negotiation is done in band. But since every modem does it, it might as well be out of band.) This effect also slows the PEP modem, and is one of the reasons that you want to stream your data, because the modem can be filling again while the last hunk was transmitted. Does this not apply to MNP modems? I thought I saw effects of this last time I tried hooking up an MNP modem where the interface was at 9600 and the exchange speed was at 2400. > In order to get the full 19.2 > capacity of a PEP modem you must be able to drop full >3K data streams > into the modem all at one time. If you do not drop these huge packets > into the modem (or stream many small packets through a large verify > window) you will pay turnaround penalities for each packet. To > address this, Trailblaizer et. al. started something called > protocol-spoofing (most of you know this, but that is for those who > didn't).... > ..... > Spoofing has several major drawbacks to PEP. > 1) Both modems must be programmed to spoof the desired > protocol. This implies that "new protocol => new ROM" > which can cost you big time, or not be available. Admittedly, this is true. And I'll think up a good reason for a new protocol, so help me. Let's see: We already have protocols that assume reliable transfer, protocols that dump the entire file through and do one checksum at the end, protocols that are optimized for slow modems, protocols that do 7 bit over Telenet, and that is just UUCP. What do we need? I know? A protocol that is optimized for 1200 BPS modems over Private satellite links? :-) No? :-( Darn...I wanted to get my nose in lights..... > 2) Complex pick-up-where-you-left-off type protocols may fail > (depending on the spoofing implementation) completely > around connect interrupts because computer A knows > that packet 2346 got through while computer B never > even got 2331, so second call recovery will have a > bitch of a time re-sync(ing). Sorry, but I want the complex pick up where you left off protocol to have the sending computer ask the receiving computer what it actually has. This might be 20 minutes, and there could have been a reboot, with not all of the file flushed to disk, for example. > 3) Because of point 1, the modem's longevity is tied directly > to the manufacturers support and longevity. Or to the longevity of the protocols that are already spoofed. > Why the same draw-backs do not apply to V.32. > 1) V.32 is full-time-full-duplex. The same preformance is > provided to transporting 1 character as 1,000,000 > (per capita) Only if you ignore MNP. And noise effects. > 2) Point 1 makes any protocol concerns (as far as the modem > is concerned) moot. e.g. if your software will do > it your modem will do it. Good. My software will transmit 1200+ characters per second, after compression (less with compression enabled in the modem) using UUCP g protocol. Can I have a V.32 modem that will do that? > 3) V.32 contains satalight silencing and crosstalk > compensation consistent with international standards. This may be true. And international acceptance may be one of the places that V.32 is a big win, in that whereas you can import a modem, hook it up and get away with it, a vendor can't bid it to you. How many international dial up calls do you make? > 4) V.32 modems are "transparent, non-intrusive" carriers so > they will not interfere with real-time opperations. > (encoding and such) Once again, MNP! And if not MNP, the Garbled data! V.32 modems are not as good with noise... > > NONE of these points will bother any installed base of PEP modems, but > the installed base of PEP modems will have its growth stunted. Many > large institutions have avioded PEP modems and simply waited for V.32. > (Yes, like us, the third largest private instutition of higher > learning in the state of california). PEP 19.2 vs V.32 9600 only > apears to be a 2-to-1 speed difference, agregate throughput discounts > the PEP substancially (for many applications I can think of) towards > V.32. > > Since V.32 does not lock us into any one company or into current > technology. Hmmm...several companies sell PEP, probably all relabeled 'blazers. Last time I talked to V.32 modem salesmen, they admitted that not all brands talked to each other. So you have to be careful and insure that one will talk to each other. But that is unfair, I'm sure. But you do have to clarify one point. Is V.32 current technology or not? If V.32 is not current, I can't buy them. But I can, so they are current. Are you trying to say that your follow on modems will have V.32 the same way that current modems still have Bell 103? Personally, I'm not sure about this one. Bell 103 is a nit, no? Maybe in the future, V.32 would be a nit. But I wonder about that one a little. > > If you look to the immeadite future, you will see the re-working of > many protocols threatening your horizions. (see "tar wars" and uucp > "e" protocol, and "dart," and "gossip," and ...) You may see > (depending on who you are) that buying a PEP modem is buying into a > dead end street (now). Your installed base may go beyond a "growth > slowdown" and start to actually shrivel up. Can't you see the > promotions now. . . . > > [ (in my best political/beer-comercial voice: > "Turn in that old PEPless horse, and go with a *standard*, > catch the (square) wave; V.32"] ;-) > This is your best point yet. And you can apply this to many things. Why buy a 286 machine now when a 386 is better? (although we are still arguing about better, on the modems, at least). Why buy a 386 machine when you will be able to get a 486 machine next year? Why buy V.32 when next year (or the year after) there will be V.128 that uses relativistic effects to cause the transmitting modem to receive your data before you send it? ;-) (I could go on, but good taste intervenes..) > Disclaimer: Ignore the typos and spelling errors; I am being harried > right now and this disclaimer is "more expedient" (faster? > now where have I heard that before?) than a proofread. > > Rob. Ditto. And I'm speaking for myself, as an individual. -- Nick Simicich --- uunet!bywater!scifi!njs --- njs@ibm.com (Internet)
brad@looking.UUCP (Brad Templeton) (11/12/88)
What I said was misunderstood. I thought 1400/second in one direction, 100 in the reverse was clearly a description of simultaneous transmission, something the trailblazer doesn't do at this time. If I had meant turnaround, I would have said, 1400/second in one direction, 1400/second in the reverse, but not at the same time. It should be possible to get a modem that is significantly greater than 960/second in one direction and SIMULTANEOUSLY something like 50 or 100 bytes/second in reverse. (Clearly it must also be able to reverse.) This would be superior to V.32 for almost every application I have ever encountered. The counter examples are far from common. As long as V.32 is not the limit, it will not rule the world. -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
rwhite@nusdhub.UUCP (Robert C. White Jr.) (11/12/88)
in article <7337@daver.UUCP>, dlr@daver.UUCP (Dave Rand) says: > > In article <1245@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >> PEP 19.2 vs V.32 9600 only >>apears to be a 2-to-1 speed difference, agregate throughput discounts >>the PEP substancially (for many applications I can think of) towards >>V.32. > > This is the difference between a $500/mo and a $1,000/mo. Or $50 and $100. > Or whatever you want to make it. Common guy, READ THE GOD DAMN POSTINGS INSTEAD OF JUST PUKING OUT SELF- JUSTIFICATION!!! The thought began with was that "for non spoofed protocols..." and ended the same way! For non-spoofed protocols the numbers are more like $1000 for a PEP vs. $650 for a V.32. If your protocol is not spoofed you dont even get 9600 out of a PEP. Sometimes it is suprisingly less than 9600! I have never made claim that the Telebit modems were a bad choice, nor that thery were in effective. I have not attacked you choice of a Telebit, as a mater of fact I tried to obtain one about three months ago. We did not chose to purchase at that time because we knew that V.32 was comming out. For our useage, and need for flexibility (we use modem pools on ISN(s) to front for an extreemly hetrogoneus <sp?> async and sync network, which has need for overseas traffic) we would be total fools if we were to aquire a PEP modem. My only real value judgment on the subject was that buying one now (IF YOU INTEND TO USE IT FOR ANY PROTOCOL IT DOES NOT SPOOF, OR WHICH MAY BE EXPANDED IN THE NEAR FUTURE (like uucp)) would be a mistake. > I _know_ my telebits have paid for themselves. Even if I scrap them, like > the (multiple) 300 bps modems I had. And the (multiple) 1200 bps modems. > And the (multiple) 2400 bps modems. The question is not now, nor was it ever "did your Telebit(s) pay for themselves?" OF COURSE TEY DID! The question is: WHY SHOULD I (editorial) BUY ONE TODAY? You have said that for two (really one *is* a special case of the other, but we will give you credit for two (2) here) applications it has been cost effective; and barring some change in technology those applications wuold still be superiorly served by a Telebit. I have given six or seven *groups* of application types which would be best served by true 9600 (V.32) comunications paths, for which a PEP modem would be nothing short of a disaster. You have not seen fit to refute my aledged facts with aledged facts of you own, nor have you chosen to add any concrete numbers (though we are assuming your esitmates are accurate), nor have you offered up any other applications for which a telebit would be superior, nor have you speculated on any future applications, nor have you provided any rumors about future products and directions as you see them, nor have you offered any suggestions on how any of these ideas/products could be improved, YOU (aparently) ARN'T EVEN READING WHAT HAS BEEN GOING ON HERE! In fact, you havn't made much of a contribution to anything on this subject at all! If you do not intend to provide anything of substance to this conversation (except local color in the form of mindless, rabbid self-justification for a perfectly reasonable decision which nobody is disputing) perhaps you should start saving the rest of the world that $1000 a month (each) expenditure by posting your articles directly to your own /dev/null. I look forward to your !*VALUABLE*! future comments, or some mindless ego-centric counter-flame, with equal intrest; one for content, and one for entertainment value. If it is going to be a counter-flame though, perhaps you should mail it to me as I am shure it will have limited apeal. > Technology continues, and we will _all_ scrap these modems, sooner or later. (wow, a truisim! how impressive! Perhaps your next post will have something equally valuable!) > Dave Rand > {pyramid|hoptoad|sun|vsi1}!daver!dlr Rob.
rick@pcrat.UUCP (Rick Richardson) (11/12/88)
In article <422@scifi.UUCP> njs@scifi.UUCP (Nicholas J. Simicich) writes: >Interesting point. Now, there are two reasons that a modem like a Trailblazer >is slower in "negotiated" full duplex mode. One is the fact that if it is >transmitting, it can't be receiving (hmmm...I think the same is true of my >Unix application, unless I do complex things with multiple processes and IPC) >while the other thing is that when you write to the modem it must wait a short >period of time before it decides that no more characters are coming and closes >the packet with a CRC. There are some clever ways to minimize the packet forwarding delay, not blessed by the CCITT, but in AT&T's ISDN terminal adapters. You can get the delay down to just a few milliseconds. > >Furthermore, there is an additional effect. Modems running MNP at any speed >must collect a full MNP packet, internally, and decide that they have it >correctly before they can transmit any of it to the attached computer. At least, >this seems to be true through level 3. You might tell me that MNP is optional >for a V.32 modem. I consider this to be a drawback, not a benefit. Because This delay dominates in protocols, such as X.25 used in ISDN, when the (user, file transfer, transport layer, what have you) protocol is not windowed (Such as XMODEM, YMODEM, old kermits). End to end, you see total delays of approximately: For an XMODEM data packet: PL * Tx RS-232 character time 132*.52ms (19.2kbps) Tx Forwarding delay 5ms PL * Tx Comm. Medium character time 132*.125ms (64kbps) PL * Rx RS-232 character time 132*.52ms (19.2kbps) For the return acknowledgement: PL * Tx RS-232 character time 1*.52ms Tx Forwarding delay 5ms PL * Tx Comm. Medium character time 1*.125ms PL * Rx RS-232 character time 1*.52ms TOTAL: 165ms Thats only about 6 packets/second or 768 characters/second. To get decent speed, you either have to change the file transfer protocol (users resist this), or change the underlying protocol between the terminal adapters (be they modems, or ISDN TE's). In the V.32 world, you "send and pray". In AT&T's ISDN world, you choose DMI Mode 2, a rate adaption scheme that makes the 64k channels look like pieces of wire. Also "send and pray", but with very low claimed bit error rates. Of course, the file transfer protocol will recover from errors, anyway (hopefully), so no great loss. The point is, your "drawback" can be of significant economic benefit. I *am* happy with the 'blazer. The spoofing is one way to minimize these problems. But it isn't a panacea, nor are V.32 or ISDN. -- Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2 PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2 uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/. |submission forms. jetroff Wk2200-0300,Sa,Su ACU {2400,PEP19200} 12013898963 "" \r ogin: jetuucp
chris@mimsy.UUCP (Chris Torek) (11/13/88)
>In article <2261@looking.UUCP> brad@looking.UUCP (Brad Templeton) notes: >>I would rather a modem that is 1400 bytes/second one direction and 100 >>bytes/second in the reverse direction than one that is 960 bytes/second >>in both directions. In article <1248@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >The problem is that the 1400/100 must REVERSE on directive reversal of >base data. This is true, but the point is that directional reversals need not be (and in fact are not) frequent. >Any protocol not "spoofed" which "waits for ACK" will >trigger TWO FULL TURNAROUNDS PER PACKET. Not necessarily. UUCP's `g' protocol runs into trouble not because of reversals---the 6-byte ack packets fit in the reverse channel---but rather because its packet size (64 bytes * 3 = 192 bytes) is just large enough to convince the TB+ to send a large data packet (1024 bytes) to the other modem, but not large enough to fill the large packet. Streaming protocols and large-packet protocols whose acks fit in the reverse channel would run at full speed. (Alas, IP acks sent over SLIP do not fit, although Van Jacobson is trying to change that. Widening the reverse channel would also do the trick.) >Not so true as you might think; to whit: (non spoofed of course) > >Any small packet protocol. >Any truely intelegent workstation. > (just picture yourself at home with a DMD/programable > terminal preforming emacs-style functions at home. > downloading huge files for editing while the ones > you just finished with are being uploaded back, etc.) >Any "open-channel" bridging. >Any environment server (X-windows? NeWS?). >Any "secure" connection. >Any real-time remote service. (remote lab monitors et. al.) Many of these actually have predominately unidirectional data flow. Consider the smart editor, for instance. I type edit foo The first screen's worth of `foo' is loaded into my workstation and displayed; more of `foo' is sent as I begin to examine the text. (Flow is all host->workstation.) I decide I want to start at the end and work backwards, and type some command. Only about 4 kB (2 `pages') of `foo' have reached the workstation, so the workstation sends a command saying `preempt: send the last page'. This message fits in the reverse channel. The last screenful comes over and is displayed, and then the last 2 kB of the file flow over. (Flow is still all host->workstation.) As I look backward through the last 2 kB, the second-to-last 2 kB come over. (The theory goes that the region loaded into the workstation should always be that that is closest to surrounding the current location, with a slight forwards bias.) I make a few changes. Most of the commands required to make those changes on the host fit in the reverse channel. (Never said we had to delay sending them!) A few do not; those require reversals. No matter; the region I am editing is in fact already on my workstation, and the changes are made in parallel. Whenever I am idle, more of the file `foo' flows over. Only the changes I make must be sent back to the host, and most of them fit in the reverse channel (just as what I am now typing fits in the reverse channel on the TB+ I am using at the moment). See the pattern? >or any other high-density biderectional traffic you can care to think >of, which requires a protocol. There *are* some. The strange thing is that, for most of us, there are so few. >True, uucp and usenet, as they exist today (and most hobbiest-level bbs >up- down-load type transactions) do not take advantage of high-density >bidirectional traffic to remote sites (simply because it didn't exist). All the way from 300 bps to 2400 bps, we had full duplex available. We did not make use of it not because it was not available, but because it was either unnecessary or hard to use. Only the latter is likely to change. Traffic patterns probably *will* change, but not as much as, nor as quickly as, the pro-full-duplex crowd is suggesting. In the meantime we are making merry with our half-duplex patterns on our half-duplex modems. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
james@bigtex.cactus.org (James Van Artsdalen) (11/13/88)
In <325@maxim.ERBE.SE>, prc@ERBE.SE (Robert Claeson) wrote: > I've got some info on the new V.32 modem from Microcom. It has MNP > Class 9, and can give a throughput of c. 30 kbit/sec. That's hoping for a 3x compression ratio within the modem, which I think is highly optimistic. If nothing else, it is better to do the compression before sending the data to the modem than to send all of that data and have the modem compress it. In addition, I shudder at the thought of trying to convince uPort unix/386 to talk to a modem at 56.8Kbps or whatever the interface rate would be. If their compression scheme *does* get a ratio of 3x, imagine what a PEP modem could do: 42Kbps around town... -- 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
james@bigtex.cactus.org (James Van Artsdalen) (11/13/88)
In <1250@nusdhub.UUCP>, rwhite@nusdhub.UUCP (Robert C. White Jr.) wrote: > Common guy, READ THE GOD DAMN POSTINGS INSTEAD OF JUST PUKING OUT SELF- > JUSTIFICATION!!! Calm down. Take your own advice. > If your protocol is not spoofed you dont even get 9600 out of a PEP. That's a wildly broad claim. Try Zmodem under PEP sometime. You get much better than 10Kbps if it's a good line (that's 10Kbps before compression). > For our useage, [...] sync network, which has need for overseas > traffic) we would be total fools if we were to aquire a PEP modem. Quite likely. I would be interested in knowing how you deal with the noise problem (just curious: no one using V.32 has actually posted here how it works in the real world with noise). As an aside, is it legal to use V.32 in England, Germany or France? Some of those PTTs apparently have laws against fast modems, reminiscent of AT&T in the bad old days. I have need of an error-free link to all of those countries, be it PEP, V.32 or 2400bps (with MNP). -- 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) (11/14/88)
In article <2952@sugar.uu.net>, ssd@sugar.uu.net (Scott Denham) writes: > not ALL modems are used for BBS's or big networks!! ^ The USENET/UUCP mail network is one of the largest NOTABLE computer networks in the world. -- Dave Arnold (dave@arnold.UUCP) Work: Volt Delta Resources Phone: (714) 921-7635 Home: 26561 Fresno street, Mission Viejo, Ca 92691
prc@ERBE.SE (Robert Claeson) (11/14/88)
In article <10504@bigtex.cactus.org>, james@bigtex.cactus.org (James Van Artsdalen) writes: > That's hoping for a 3x compression ratio within the modem, which I > think is highly optimistic. The brochure says 300% compression ratio. > In addition, I shudder at > the thought of trying to convince uPort unix/386 to talk to a modem at > 56.8Kbps or whatever the interface rate would be. It's 38.2 Kbps. Or you can set it to any lower speed you'd like. -- Robert Claeson EUnet: rclaeson@erbe.se Smart ARPAnet: rclaeson@erbe.se Dumb ARPAnet: rclaeson%erbe.se@uunet.uu.net
chris@mimsy.UUCP (Chris Torek) (11/14/88)
`OOPS' Corrections (as pointed out by Don Speck): In article <14515@mimsy.UUCP> I claimed: >Not necessarily. UUCP's `g' protocol runs into trouble not because of >reversals---the 6-byte ack packets fit in the reverse channel---but Point 1: The TB+ does not have a `reverse channel'; it has an `interactive mode'. (See recent technical details posting from Telebit.) I believe (based on personal observation) that one modem can be sending big packets while the other is sending little interactive packets, which means that the g protocol acks fit in the small packets; the small packets *act* like a reverse channel but are not in fact the same. So: `1,$s/reverse channel/periodic small packet/g' :-). >rather because its packet size (64 bytes * 3 = 192 bytes) is just large >enough to convince the TB+ to send a large data packet (1024 bytes) to Ack! I do not know where I came up with 1024 bytes. Large packets are 256 bytes. (Also, I forgot the 6-byte headers this time. A 3 packet window gives 70*3 = 210 bytes out of the 256 that would fit in a large packet.) >the other modem, but not large enough to fill the large packet. >Streaming protocols and large-packet protocols whose acks fit in the >reverse channel would run at full speed. I should emend this: not `would' but `could': the TB+ should delay somewhat before sending a 256-byte packet if you have fed it only 210 bytes, in the hope that it could fill the remaining 46 bytes. It would be a bad thing for performance if, every time the host connected to the modem hiccuped with a slow interrupt, the TB+ had to send a partial packet. This delay appears (personal observation again) to exist and to be on the order of ten milliseconds. This could be fixed by having the tty driver speak a protocol with the modem, so that the modem knows when to send immediately and when to wait. (This is, of course, the moral equivalent of spoofing.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (11/14/88)
> >The problem is that the 1400/100 must REVERSE on directive reversal of >base data. Any protocol not "spoofed" which "waits for ACK" will >trigger TWO FULL TURNAROUNDS PER PACKET. (what is that under PEP? 20 >carriers? twice.) The turnaround delay (with retraining?) will >introduce more of a delay than the 960/960 standing rate. What we really need is a modem that dynamically adjusts the size of the reverse channel. If you are doing a one-way transfer, you get all of your bandwidth used for one direction. Bidirectional transfers would split it 50/50 (or whatever). -- Jon Zeeff Support ISO 8859/1 umix!b-tech!zeeff zeeff@b-tech.ann-arbor.mi.us
amanda@lts.UUCP (Amanda Walker) (11/14/88)
In article <14533@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > [stuff about TB+] > ... to be on the order of ten milliseconds. This could be fixed by having > the tty driver speak a protocol with the modem, so that the modem > knows when to send immediately and when to wait. (This is, of course, > the moral equivalent of spoofing.) > -- > In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) > Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris Thins brings up an interesting point. There seems to be some disagreement about the "moral value" :-) of protocol spoofing. Some people think it's the best thing since invention of the modem. Some people think it's a grody hack that allows modem companies to squeeze money out of unsuspecting customers (this is simplified, but seems to be the gist of it). It seems to come down to the fact that different people see the concept of "what a modem should do" differently. There are those that think a pair of modem should be a "virtual wire;" they tend to like full-time full-duplex schemes like V.32. The only problem is that, at least for a while yet, the phone connection *between* the modems isn't much like a virtual wire, and things that work well over a few hundred feet of copper don't work so well over couple of satellite hops. Even so, this approach does let them work, if poorly--most computers know how to talk to a wire, after all. There are those that think a pair of modems should be pair of experts on how to get bits from point A to point B. Now, there isn't (that I know of) any standard "smart communications controller protocol," but protocol spoofing isn't too bad of an approximation. Any protocol imposes a structure on the data, which the modem can then use to get better performance than it could if it had to pretend to be one end of a wire. Thanks to the multiplicity of protocols, this does make life interesting for the engineers at places like Telebit. However, if they cover the most common ones (at least, the most common ones for the markets they want to tackle), then a large number of people can benefit. I take position number two, if you couldn't guess :-). One thing that I would love to see in a modem, whether the underlying technology is a full-duplex scheme like V.32 or a fast half-duplex scheme like PEP is to be able to tell the modem what you want. Right now the protocol spoofing in a TB+ infers this from the protocol you are using. What I'd like to see is the ability to say someething like "OK, I want this fraction of the channel for this direction, and this fraction for the other direction." It's not as good as understanding the protocol, but it's better than trying to be a wire. For example, this would make things like SLIP (that fall just off the edge of the TB+' s interactive mode) much happier, and would in general make the modems more useful to people who aren't using supported protocols. It's sort of like a group of people working on a project: the more they tell each other what they are doing and what they need, the more smoothly things tend to go... Comments? -- Amanda Walker InterCon Corporation, 11732 Bowman Green Drive, Reston, VA 22090 ...!uunet!lts!amanda / lts!amanda@uunet.uu.net
David@cup.portal.com (David Michael McCord) (11/15/88)
James Van Artsdalen asked about suitable high speed modems (dial up) for England (UK), France, and Germany. In the UK things are fairly deregulated. You may use non-PTT equipment but I am not sure if there is a program similar to FCC registration in effect. My company uses Codex v.32's. In Germany, you have no alternative to PTT equipment. At the last check (a few months ago), the highest speed available from the Bundespost was v.22bis. However, a PTT v.32 modem is expected Real Soon Now. I am not sure about France, but I believe the situation is similar to Germany. Note that it is probably not a good idea to simply ship domestic US modems overseas and connect them. In most cases, the AC power differs, for starters.
les@chinet.chi.il.us (Leslie Mikesell) (11/15/88)
In article <14533@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >[partial packet delay].... This could be fixed by having >the tty driver speak a protocol with the modem, so that the modem >knows when to send immediately and when to wait. (This is, of course, >the moral equivalent of spoofing.) Or it could just be the moral equivalent of being reasonable. A protocol that used end-of-packet characters that could be configured to match the transport packet drivers (or the reverse) would be nice. Adjustable fixed sized packets would be another approach but the transport would have to allow different packet sizes in each direction to work well. Les Mikesell
joel@arizona.edu (Joel Snyder) (11/15/88)
Amanda's comments on the two philosophies of modems are particularly well put. As a user support person, I prefer the "it's really a long wire" idea, since I don't get random users complaining that their mmmm bps modem actually delivers mmmm/2 bps performance when they're using xyz protocol. However, in my previous life working for a large network, the exact opposite was our preference---bandwidth was the most precious thing on earth (except maybe for memory), and if we could get smart modems that made the bandwidth better, we sure as hell were going to do it. In fact, there was a company I don't remember that had a product that predated the "protocol spoofing" which Telebit does by several years. They came to our site, put a datascope on several transmission lines for a couple of hours, got a lecture on the underlying protocol from some of our engineers, and promised that they'd build "custom" modems (V.29 flavored) which scratched out 20Kbps on channels we'd only ever been able to get 9.6Kbps out of before (remember, this was before the new class of modems came out--- this seemed incredible at the time!). There is room for both in this world. It all depends on your application. jms
caf@omen.UUCP (Chuck Forsberg WA7KGX) (11/16/88)
In article <14533@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
:`OOPS'
:
:Corrections (as pointed out by Don Speck):
:
:In article <14515@mimsy.UUCP> I claimed:
:>Not necessarily. UUCP's `g' protocol runs into trouble not because of
:>reversals---the 6-byte ack packets fit in the reverse channel---but
:
:Point 1: The TB+ does not have a `reverse channel'; it has an
:`interactive mode'. (See recent technical details posting from
:Telebit.) I believe (based on personal observation) that one
:modem can be sending big packets while the other is sending little
:interactive packets, which means that the g protocol acks fit in
:the small packets; the small packets *act* like a reverse channel
:but are not in fact the same. So: `1,$s/reverse channel/periodic
:small packet/g' :-).
:
:>rather because its packet size (64 bytes * 3 = 192 bytes) is just large
:>enough to convince the TB+ to send a large data packet (1024 bytes) to
:
:Ack! I do not know where I came up with 1024 bytes. Large packets are
:256 bytes. (Also, I forgot the 6-byte headers this time. A 3 packet
:window gives 70*3 = 210 bytes out of the 256 that would fit in a large
:packet.)
:
:>the other modem, but not large enough to fill the large packet.
:>Streaming protocols and large-packet protocols whose acks fit in the
:>reverse channel would run at full speed.
:
:I should emend this: not `would' but `could': the TB+ should delay
:somewhat before sending a 256-byte packet if you have fed it only 210
:bytes, in the hope that it could fill the remaining 46 bytes. It would
:be a bad thing for performance if, every time the host connected to the
:modem hiccuped with a slow interrupt, the TB+ had to send a partial
:packet. This delay appears (personal observation again) to exist and
:to be on the order of ten milliseconds. This could be fixed by having
:the tty driver speak a protocol with the modem, so that the modem
:knows when to send immediately and when to wait.
Unimportant in the case of ZMODEM and TrailBlazer modems.
Whether or not a "short block" goes out at first, the sending
modem's buffer will continue to accept characters at full
speed. As this buffer is 4k or more, the modems will be
operating at full tilt for the remainder of the file.
With UUCP-g, Sliding Windows Kermit, WXMODEM, and SEAlink, the
frequent ACK packets are the problem, forcing frequent line
turnarounds unless spoofing is used.
:(This is, of course, the moral equivalent of spoofing.)
Adding a modest delay to data transmission is not the moral
equivalent of spoofing. Spoofing creates its own data and
eats some data, all in the name of efficiency.
Telebit's XMODEM and Kermit spoofing bollixes protocols the
spoofing does not understand. Sliding Windows Kermit and
possibly Long Packet Kermit don't mix with Kermit spoofing.
XMODEM and XMODEM-1k transfers that use the full protocol have
problems. YMODEM gets into trouble before the first file gets
through.
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406
TeleGodzilla BBS: 621-3746 CIS: 70007,2304 Genie: CAFsteckel@Alliant.COM (Geoff Steckel) (11/16/88)
One reason the 'I want a wire' camp exists is that I have yet to see a "smart" (= special protocol) modem provide an adequate 'there were errors' signal to the host. This is also a problem with many of the ISO protocols, though they are getting smarter. It really doesn't help, of course, that RS-232 does not provide error signalling, so hosts aren't equipped with any way the logical hardware could send the message upwards. Result: people run TCP/IP, X.25, uucp, kermit, [xyzabcdef]modem, etc., etc. to get guaranteed delivery and error recovery. With a 'dumb' modem I get errors, but the connection stays in place. The higher level program will (it had better!) detect errors, retry, and log success or failure. This is relatively soft degradation. With a "error correcting" modem, I get catastrophic degradation - it hangs up. Real useful. That was X.25's solution until recently as well. "Smart" systems should be integrated with error handling all the way to the user. What we REALLY need is a standard host-to-modem protocol with error recovery and error signalling. This way the modems could be as smart as they dared, and the user would have some way to figure out what's going on. Until then, I want a wire. geoff steckel (steckel@alliant.COM)
chris@mimsy.UUCP (Chris Torek) (11/17/88)
In article <725@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) includes everything (sigh) from article <14533@mimsy.UUCP>, in which I noted that >>This [small delay, hoping to fill a packet] could be fixed by having >>the tty driver speak a protocol with the modem, so that the modem >>knows when to send immediately and when to wait. >Unimportant in the case of ZMODEM and TrailBlazer modems. Yes. But not in the case of generic interactive traffic, or indeed any other generic sort of traffic that does not involve long streams of data (the ratio of traffic-where-it-matters to traffic-where-it- does-not depends very much on your application; spoofed UUCP, or unspoofed ZMODEM, transmission of netnews leans very far in the does-not direction, for example). >>(This is, of course, the moral equivalent of spoofing.) >Adding a modest delay to data transmission is not the moral >equivalent of spoofing. Spoofing creates its own data and >eats some data, all in the name of efficiency. It is not the *delay* that is equivalent: it is the speaking of a protocol directly with the modem. If I reprogram my modem to speak SLIP with my host, I have moved the `SLIP spoofing' up to the level of a direct interaction with the modem. The modem is no longer spoofing per se, but the effect is the same: the action has merely been `legitimised'. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
henry@utzoo.uucp (Henry Spencer) (11/17/88)
In article <2628@alliant.Alliant.COM> steckel@alliant.Alliant.COM (Geoff Steckel) writes: >With a 'dumb' modem I get errors, but the connection stays in place. The >higher level program will (it had better!) detect errors, retry, and log >success or failure. This is relatively soft degradation. With a "error >correcting" modem, I get catastrophic degradation - it hangs up. Real useful. Of course, with an error correcting modem, as opposed to an "error correcting" modem, what happens is that the data rate goes down momentarily but nothing else unpleasant happens. I've never used an "error correcting" modem, but we make heavy use of an error correcting modem -- the Trailblazer. -- Sendmail is a bug, | Henry Spencer at U of Toronto Zoology not a feature. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu