gandrews@netcom.COM (Greg Andrews) (05/22/91)
In article <9105210700.AA14518@ucbvax.Berkeley.EDU> petty@ralvm31.vnet.ibm.com ("Jack Petty") writes: > >Have I read that for the Telebit proprietary modulation scheme it takes >about 1 second to turn the line around? > Yes, somebody said that on the net. Note that they are using the modems in the USSR, where phone lines aren't very good. His observations, while probably accurate for his line conditions are FAR from typical. Over clean lines the typical single-character turnaround time of PEP is around 140-160 milliseconds. Impaired lines will increase that time, and certain adjustments to the modem's S120 register can have a severe impact on the single-character turnaround time. That's one of the reasons the S120 register remains undocumented - trouble calls to tech support would triple as users twiddled the register unnecessarily, causing slow typing and file transfer throughput. Caveat net.user: Lots of info on the net is accurate and useful, but not all of it. >Jack Petty -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
petty@ralvm31.vnet.ibm.com ("Jack Petty") (05/22/91)
Greg Andrews writes: > Over clean lines the typical single-character turnaround time of PEP is > around 140-160 milliseconds. Many thanks Greg. If I understand you correctly, the round trip time for interactive use would be about 300 milliseconds. That would be quite consistent with what I have read here (some people complain and some do not). I think I remember there were some IBM System Journal articles long ago that indicated that programmer productivity was impacted if system response time was greater than 200-250 milliseconds. Jack Petty
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (05/23/91)
> >Have I read that for the Telebit proprietary modulation scheme it takes > >about 1 second to turn the line around? > Over clean lines the typical single-character turnaround time of PEP is > around 140-160 milliseconds. The single-character turn-around time is not what people notice. Switching among packet sizes takes a long time. For example, the ping command reports ICMP ECHO's over a SLIP line using PEP typically take >1.1 seconds. If you turn on the speaker, you can hear the modem laboriously switching between 7 and 18 baud (or whatever the exact numbers). I've long thought that Telebit missed a bet by not using a more hysteresis in their packet/baud switching. If they'd pick a speed and stick to it longer, much of the jerkiness of interactive traffic over PEP would go away. This is obviously the problem with ping's over PEP. It's the problem with control-L in a vi window. vjs
avg@hq.demos.su (Vadim Antonov) (05/23/91)
In article <9105210700.AA14518@ucbvax.Berkeley.EDU> petty@ralvm31.vnet.ibm.com ("Jack Petty") writes: >Have I read that for the Telebit proprietary modulation scheme it takes >about 1 second to turn the line around? In <1991May22.002144.2198@netcom.COM> gandrews@netcom.COM (Greg Andrews) writes: >Yes, somebody said that on the net. Note that they are using the modems in >the USSR, where phone lines aren't very good. His observations, while >probably accurate for his line conditions are FAR from typical. "Somebody" here is me; still I mentioned turnaround time of IP packets which does not fit into PEP micro-packets (10 bytes) and therefore Telebit packs it into small (256 bytes) or long packets. Moreover, using S120 to prohibit micro-packets actually increases the speed because if you've tuned it this way your modem will not switch from micro-packets to small packets at each IP packet! And the line we do use have a reasonable quality, though not the ideal. Thus I think both your and mine estimations are close to truth - simply we have measured different things! ("Steerman, figures!" "Six!" "Six of what?" "What figures?!") Still, I haven't heard any suggestions about leased line modems :-( Vadim Antonov DEMOS, Moscow, USSR
gandrews@netcom.COM (Greg Andrews) (05/24/91)
In article <105588@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > [vjs] >> >Have I read that for the Telebit proprietary modulation scheme it takes >> >about 1 second to turn the line around? > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Over clean lines the typical single-character turnaround time of PEP is >> around 140-160 milliseconds. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >The single-character turn-around time is not what people notice. Switching >among packet sizes takes a long time. For example, the ping command reports >ICMP ECHO's over a SLIP line using PEP typically take >1.1 seconds. If you >turn on the speaker, you can hear the modem laboriously switching between >7 and 18 baud (or whatever the exact numbers). > Well, you received a reply based on what you *said*, not what you *meant*. Sorry about that. Yes, an uncompressed implementation of SLIP will make PEP thrash between different sized packets. It's not a "baud" rate switch at all. It's a simple matter of packet size. Regarding ping: Yes, ping will show long amounts of delay over a SLIP link without the Van Jacobsen header compression. According to the info I have, ping usually uses a 64-byte datagram. Then the datagram is wrapped in a ~20-byte TCP envelope and another ~20-byte SLIP envelope, for a grand total of ~104 bytes of data. Definitely too large to fit into a PEP short packet. At best, the modem would simply switch up to a long packet and send it out at ~50% efficiency (longs handle around 250 bytes on clean lines). At worst, the modem may have only part of the data when it samples its buffer, so it puts that part into a short packet. When the rest of the data appears in the buffer, the modem puts it into the smallest packet it can. Unfortunately, a 100 byte SLIP packet will probably have enough left over to force the modem to use a long packet - even less efficient now that some of the data has already been sent in the previous short packet. Thus the packet thrashing you hear over the speaker. My understanding of compressed SLIP is that the SLIP overhead is reduced from ~40 bytes down to ~5 bytes. That would drop a ping to around 70 bytes, which may fit better into a pair of short packets. It would DEFINITELY help interactive response where the SLIP overhead would be reduced to fit inside a single short packet rather than two short packets. > >I've long thought that Telebit missed a bet by not using a more hysteresis >in their packet/baud switching. If they'd pick a speed and stick to it >longer, much of the jerkiness of interactive traffic over PEP would go >away. This is obviously the problem with ping's over PEP. It's the >problem with control-L in a vi window. > That might help standard SLIP, where there's a significant amount of overhead, but it is exactly the opposite of what you want for normal interactive work. You *DON'T* want the modems to stay in long packet mode for your keystrokes just because they used longs to send your last screen update. Someone who is using standard SLIP could experiment with forcing the modem into long packets only to see if the response gets better by reducing the modem's packet thrashing. (I'm just taking a shot in the dark here - I've never used SLIP myself...yet.) >vjs -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
gandrews@netcom.COM (Greg Andrews) (05/24/91)
In article <9105230658.AA29951@ucbvax.Berkeley.EDU> petty@ralvm31.vnet.ibm.com ("Jack Petty") writes: >Greg Andrews writes: > >> Over clean lines the typical single-character turnaround time of PEP is >> around 140-160 milliseconds. ^^^^^^^^^^^^^^^ > >Many thanks Greg. If I understand you correctly, the round trip time >for interactive use would be about 300 milliseconds. That would be >quite consistent with what I have read here (some people complain and >some do not). I think I remember there were some IBM System >Journal articles long ago that indicated that programmer productivity >was impacted if system response time was greater than 200-250 >milliseconds. > Well, that's not what I said. What you called "round trip time" I called "turnaround time", and was referring to the same thing. After you send a single character, you will get it back in 140-160 milliseconds with PEP over clean phone lines (modems are using micro packets). >Jack Petty -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (05/25/91)
In article <1991May24.060836.7247@netcom.COM>, gandrews@netcom.COM (Greg Andrews) writes: > If you > >turn on the speaker, you can hear the modem laboriously switching between > >7 and 18 baud (or whatever the exact numbers). > > Yes, an uncompressed implementation of SLIP will make PEP thrash between > different sized packets. It's not a "baud" rate switch at all. It's a > simple matter of packet size. I think it really is a "baud change." I understand from Telebit that while running micropackets they use something like 18.3 baud, but doing big packets they use about 7 baud. That is, the signal transmitted by the modem changes either 7+ or 18+ times/second. Of course, the instantaneous bit rate at the DTE-DCE interface never changes. (Yes, the old lecture that "buad" != "bps") > ... > Thus the packet thrashing you hear over the speaker. My understanding of > compressed SLIP is that the SLIP overhead is reduced from ~40 bytes down to > ~5 bytes. The "VJ compression" takes 3 or 4 bytes for TCP/IP plus one of SLIP framing. Thus, at best VJ-cslip replaces the 20 byte IP and 20 byte TCP headers with 4 bytes. Another commercially available scheme with slightly different checksum and compression trade-offs gets it down to 3 bytes including SLIP framing. The checksum difference is that Van Jacobson did not add a link-level checksum but did retain the TCP checksum. That's good if all of your traffic has TCP and UDP checksums (think of Sun's NFS) and if you don't trust router memories and buses. (Yes, I know people who run NFS over SLIP, tho with machines that do use the UDP checksum.) There's room for only 1 SLIP compression standard, so don't worry about the alternate. It was developed when there were restrictions on shipping the VJ code. Vernon Schryver, vjs@sgi.com