Path: utzoo!attcan!uunet!bywater!scifi!njs From: njs@scifi.UUCP (Nicholas J. Simicich) Newsgroups: comp.dcom.modems Subject: Re: V.32 will dominate the marketplace (Was: Re: Which is best?) Summary: Trailblazers vs. V.32 Message-ID: <422@scifi.UUCP> Date: 12 Nov 88 00:29:48 GMT References: <407@telly.UUCP> <1245@nusdhub.UUCP> Organization: Nick Simicich, Peekskill, NY, USA Lines: 154 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)