bert@helix.nih.gov (Bert Tyler) (02/27/91)
A few days ago, I posted a few questions concerning high-speed modem connections between the UK and the US. I received many helpful replies. Some specific points that were made, most by several responders independently: Many people pointed out that there are both legal and practical problems with purchasing a modem in the US, shipping it to the UK, and then using it in the UK. Several people pointed out that it could be done with a small amount of technical expertise, but that little niceties like repair service and modem upgrades would be problems for the life of the modem. It turns out that the folks in the UK had not realized all that was involved, and you've apparantly convinced them to purchase their US-bound modem in the US and their UK-bound modem in the UK. Several of you also had [bad] experience with V.32 connections and overseas calls, particularly those to and from the UK. This being primarily a Unix-based conference, most of you who suggested using alternate high-speed protocols recommended Telebit and its PEP protocol (most of those who responded to a similar question on the BBS networks suggested a USR and its HST protocol). They may go with one of the "multiple-standard" (has that phrase been copyrighted yet?) modems that include both V.32 (or V.32/V.32bis) and a proprietary protocol, so that they can make both high-speed connections to the general business world and clean connections in the UK<->US calls. Apparantly I did not emphasize enough that these folks will be using MS-DOS machines and MS-DOS-based software (in fact, the US office just found out yesterday that they will be using a package called TRAX, which is sold in the UK and is something like Close-up/Carbon-Copy) for their file transfer. I received several responses about the advantages of Telebit's "spoofing" capability. While V.42bis compression looks like a very handy feature for this application, Telebit modems won't find any protocol to "spoof". (BTW, which software will be used was [note the tense] a decision made in the home office in the UK - suggestions about switching software would be met with a "just get this package working, thank you very much". The software they have chosen may be fantastic, and it may be abysmal - either case is beside the point, and good consultants know when it's time to just get the $#@%&! thing working.)
todd@toolz.uucp (Todd Merriman) (03/01/91)
bert@helix.nih.gov (Bert Tyler) writes: >A few days ago, I posted a few questions concerning high-speed >modem connections between the UK and the US. I received many >helpful replies. I just finished setting up a system for a client with a very similar configuration. Unfortunately, he insisted on using Procomm Plus, which is not very robust nor does it have a very sophisticated scripting language. My personal favorite is HyperAccess, but my client was concerned they would not be able to find expertise for it in the UK. We used Racal-Vadic 2400 MNP modems, and they worked fine. Procomm, on the other hand, will *never* work to my satisfaction. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Todd Merriman - Software Toolz, Inc. * Maintainer of the * * 8030 Pooles Mill Dr., Ball Ground, GA 30107-9610 * Software * * ...emory.edu!toolz.uucp!todd * Entrepreneur's * * V-mail (800) 869-3878, (404) 889-8264 * mailing list * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
pat@rwing.UUCP (Pat Myrto) (03/03/91)
In article <1018@nih-csl.nih.gov> bert@helix.nih.gov (Bert Tyler) writes: > > ...[ deleted ] ... > >Apparantly I did not emphasize enough that these folks will be >using MS-DOS machines and MS-DOS-based software (in fact, the US >office just found out yesterday that they will be using a package >called TRAX, which is sold in the UK and is something like >Close-up/Carbon-Copy) for their file transfer. I received several >responses about the advantages of Telebit's "spoofing" capability. >While V.42bis compression looks like a very handy feature for this >application, Telebit modems won't find any protocol to "spoof". Oh, yes there ARE protocols to "spoof" in the MSDOS world - virtually all the non-streaming (ACK-NAK, or 'send and wait') file transfer protocols take a big performance hit with the hi-speed modems, even with non-PEP modem protocols, probably because of the packet-type nature of the error-correction schemes, such as MNP. The Telebits "spoofing" feature improves the performance of the XMODEM type protocols such as XMODEM, XMODEM-1K, and Batch YMODEM; the various flavors of Kermit, as well as the UUCP "spoofing". When I use the T2500 to make an interactive connection, I arrange things so it connects with XMODEM type spoofing turned on. For normal interactive use or streaming protocol usage, like ZMODEM, it has no effect that I can tell, but if I have to use XMODEM 1K, or Batch YMODEM, it helps quite a bit. If the other end only supports regular XMODEM (128 byte packets), performance is dismal without the spoofing active. While I haven't tested this, I suspect a 9600 bps link using V.32 and MNP would have poorer performance with XMODEM or YMODEM than PEP would using its spoofing, assuming the modems at each end are hooked to 9600 bps ports. On the other hand, if one isn't going to be transferring files, or only using the streaming type protocols, such as ZMODEM, then the spoofing feature won't result in any gain performance-wise. Another point to consider with PEP is its reputation to hang in there with lousy lines - it will not only reduce its speed if line conditions are bad, but if during the call the conditions improve, it will move its speed back up again - it adjusts dynamically for the line condition. Other schemes will often fall back to a lower speed if line condition deteriorates, but will not 'fall forward' when conditions improve. PEP changes in 100 bps increments, if I recall but V.32 9600 drops to 4800 in one step and stays there if it has to re-adjust. Telebits and PEP may not be what is best for your application, I don't really know what your software supports, etc. All the schemes and modems have their good and not-so-good points - personally I use the T2500 and find it quite robust at the hi speeds, with both PEP and V.32. I also notice that I can have a connection with some other make of modem over a less-than-great line, and the other end will be getting garbage characters in their reception, but my end (receiving with the T2500) will be totally clean. Once or twice one could attribute it to differences in the quality of the paths taken by each direction, but I find this to be consistant. Getting garbage characters on my screen or file xfer errors is a rare occurance for me, with or without an MNP type connection. Perhaps I have an exceptional unit, but the modem at work seems to show the same quality (though its usage over noisy lines has been much more limited). The Telebits offer great flexibility in setup, some folks find this to be a drawback, since they have difficulty in setting up the large number of S registers and options. With a little testing (use a terminal hooked directly to the modem) to get a feel how options affect things, and careful reading of the manual, I find the flexibility extremely useful in adapting to the quirks one finds in different communication packages - especially when reliable unattended operation is desired. I have no connection with Telebit, other than being a happy customer. Perhaps I am easy to please ... :-) -- pat@rwing (Pat Myrto), Seattle, WA ...!uunet!pilchuck!rwing!pat ...!uw-beaver!uw-entropy!dataio!/ WISDOM: "Travelling unarmed is like boating without a life jacket"
casey@gauss.llnl.gov (Casey Leedom) (03/04/91)
/ From: bert@helix.nih.gov (Bert Tyler) | | Apparently I did not emphasize enough that these folks will be using | MS-DOS machines and MS-DOS-based software ... I received several | responses about the advantages of Telebit's "spoofing" capability. ... \ Telebit modems won't find any protocol to "spoof". / From: pat@rwing.UUCP (Pat Myrto) | | Oh, yes there ARE protocols to "spoof" in the MSDOS world - virtually all | the non-streaming (ACK-NAK, or 'send and wait') file transfer protocols | take a big performance hit with the hi-speed modems, even with non-PEP | modem protocols, probably because of the packet-type nature of the \ error-correction schemes, such as MNP. MNP and V.42 packetization is only one source of latency in the overall communications link. There's the time necessary for the application to turn an ACK around, time to get the bits in and out of serial ports, possibly even terminal servers and Ethernet links, etc. Fundamentally the bug is in the non-streaming protocol. Anyone who develops a protocol now that doesn't support sliding windows should be removed from the gene pool. It's just stupid not to support sliding windows when the algorithms are now so well known. Unfortunately there are a lot of older protocols and, yes, stupid newer protocols, that some people have to use. It's unreasonable to expect Telebit or any modem company to support spoofing of every such protocol in the universe. They can only afford to go after the more popular ones. Therefore, if you have to use one of those stupid protocols and no modem is available to spoof it, you'd better look around for the combination of equipment and lower layer protocols that minimize your latency in order to boost your over all performance. From a practical standpoint, I've noticed that my Telebit T2500 seems to over a lower latency path when using V.42/V.42bis than with MNP5 -- both over a V.32 carrier. I suspect that this is probably because I've heard that the default packet size for MNP5 is 256 bytes and the default packet size for V.42 is 128 bytes. This reduces the streaming throughput rates for V.42 but also decreases the round trip latency for non-streaming protocols like XMODEM. Some modems may allow you to set the packet size in MNP or V.42. The T2500, as far as I can see, does not have any way of doing this. (By the way, I can hardly wait till we see modems whose link layers dynamically negotiate their packet sizes based on a combination of Nagle algorithm methods and analysis of burst error rates (BERTS) on the link.) Also from a practical standpoint, Telebit's PEP protocol is going to give you very large latency. This will be especially true if the protocols your are using have large ACK packets or allow data transmission in both directions at once. Casey
root@zswamp.fidonet.org (Geoffrey Welsh) (03/04/91)
Pat Myrto (pat@rwing.UUCP ) wrote: >Oh, yes there ARE protocols to "spoof" in the MSDOS world - >virtually >all the non-streaming (ACK-NAK, or 'send and wait') file >transfer >protocols take a big performance hit with the hi-speed >modems, even >with non-PEP modem protocols, probably because of the >packet-type >nature of the error-correction schemes, such as MNP. You are correct that any non-streaming protocol will suffer at high speeds, but packetizing via MNP or X.25 simply make the problem worse, not cause it. Think of XMODEM: send a block, get the ACK, send the next block. At 300 baud, the 128-byte block takes several seconds to transmit, the pause while waiting for the ACK only a fraction of a second, therefore the fraction of transmitter time which remains unused is small. Now go to 38,400 bps, where the pause for the ACK is longer than the time it takes to send a block... the result is that XMODEM will usually remain below 1000 CPS, *no matter how high the baud rate goes* You can use larger blocks, getting more data through for a fixed wasted time, but that only reduces the overhead as a percent of the available transmit time and does not solve the problem. You can use windowed protocols, but you must impose an arbitrary limit on the size of the window and, when the baud rate reaches a certain point, a full window will be transmitted before the first ACK comes back, making the protocol functionally equivalent to XMODEM, but with an effective block size equal to the maximum window size. The long term solution is the streaming protocol, and spoofing is an effective conversion of a non-streaming protocol to a streaming protocol for the physical transport and then back again at the other side. -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 The mile is traversed not by a single leap, but by a procession of coherent steps; those who insist on making the trip in a single element will be failing long after you and I have discovered new worlds. - me
rdippold@maui.qualcomm.com (Ron Dippold) (03/06/91)
In article <1991Mar01.043029.1712@toolz.uucp> todd@toolz.uucp (Todd Merriman) writes: >I just finished setting up a system for a client with a very >similar configuration. Unfortunately, he insisted on using >Procomm Plus, which is not very robust nor does it have a very >sophisticated scripting language. My personal favorite is >HyperAccess, but my client was concerned they would not be able >to find expertise for it in the UK. You might want to fix him up with Procomm 2.0 (commercial) which was just recently released, I believe. It's still not as good as Telemate or Telix, but they've beefed up many things, including the scripting.