smb@ulysses.att.com (Steven Bellovin) (07/01/91)
I recently tried using some V.32 modems for dial-up PPP connections between two Suns. Round-trip time was *not* what I calculated; packets were taking far too long to arrive. A few simple tests showed that I was getting reasonable throughput, but there was a large constant offset that I couldn't account for. I ran some timing tests on the raw hardware. If I looped back the transmit lead to the receive lead, and had one process writing a byte at a time (at intervals) while another read it, it took about 20 ms. Not great, but far from the 150 ms round trip overhead I was seeing. Next, I tried talking between two separate Suns. We run NTP, so the clocks were very closely synchronized; that let me make meaningful comparisons between high-resolution time stamps on the different machines. Results were what I expected: a slightly lower figure, since there weren't two different processes to deal with. (And in that test, one of the machines was an SS2, which could account for some of the reduction.) I was being led to the conclusion that the problem was the modems. But I found that hard to believe. Nevertheless, I switched from a Telebit 1600 to a UDS V.3225. Both were configured not to use any form of error correction or compression -- for interactive traffic, I *don't* want the extra delays waiting for end-of-packet. And flow control is turned off. To my great surprise, the overhead dropped by ~40 ms. In other words, the Telebit modem was delaying my bytes by 40 ms more than the UDS unit was. (In fact, I can't figure out why a modem should want to delay any character by that much -- it's several times the single-byte transmission time.) Alerted, I ran a few more tests. First, I hooked up the two modems to separate phone lines, with a loopback connector attached to one of them. I saw a round-trip time of a whopping 120 ms! (No, I did not route my call by way of Japan, nor do I think that any satellite hops are involved in my local loop.) Hooking the second modem to ttyb and reading from there while sending on ttya cut the time to a mere 80 ms. I forget which modem was doing the transmitting in that test -- I think it was the Telebit -- but with numbers that appalling, does it matter? So -- what's going on here? Is there something inherent in the V.32 modulation technique which requires such delays? Do I have something configured wrong? I have the Telebit configured to use ``direct'' mode rather than buffered -- my problem seems to be too much buffering, not too little. Obviously, some modems are better than others; which are the best? Will using compression help in any way? I'd doubt it -- my problem is delay, not throughput. Does V.32bis solve the problem? Again, while the extra bandwidth is nice, that's not my problem. --Steve Bellovin