S.PAE@DEEP-THOUGHT.MIT.EDU (Philip A. Earnhardt) (06/24/86)
> While it may be interesting to speculate over why MNP Class 3 and DDCMP > work slowly together, I've gotta ask, WHY BOTHER? I was using the DDCMP throughput as a metric for the effects of MNP. If I had had some sophisticated test equipment, I could have measured the exact latency for various-sized packets across the modems. Vadic should provide the exact technical information about MNP and their implementation of it. Using reverse engineering to get this information is a poor second. Why do manufactures make high-performance equipment and then fail to provide information on how to maximize its performance? > But running them both together is a waste, since DDCMP will correct the same > errors that MNP is trying to correct, so if you have MNP on, DDCMP will > never see an error (if MNP works as well). Wrong. Over an all-night transfer session, I lost 5 DDCMP packets while using MNP. Why? Probably because of inadequate buffering. Perhaps I had a marginal connection of one of my RS232 cables. Perhaps the night janitor accidentally unplugged a connection and then put it back. .... Anyone who simply trusts modem MNP to get their data across will eventually lose. Any competent network designer trusting modem MNP for file transfer data integrity should know better. > So turn off MNP when using DDCMP! Turn it back on when running async > terminals. One good data link layer at a time is enough. How about when I want to have an interactive connection to a remote machine then run a file transfer? Since MNP can only be turned on/off at the start of the connection, you're suggesting I should keep re-establishing the connection to alternate between interactive connection (with MNP) and DDCMP file transfer (without). I'd have enough headaches keeping it straight--never mind trying to train other people to do this. If MNP were optimally tuned, the loss in throughput for DDCMP would be much less. We could just leave MNP on all the time and forget about it. The 2400PA modems have about a 100ms delay for full-duplex echoing of a single character. Vadic claims the origional MicroCom modems they saw had a 100ms timeout, giving a latency of about 220ms! These delays are enough to really bother most typists. The crux of my problem with MNP is that such protocols could support quick-response and high throughput simultaneously. From what I've seen, MNP is optimized for high total throughput of continuous streams of data, particularly when line quality starts to degrade. I would be far more satisfied if they targeted for fast packet turnaround (which may imply a little faster performance dropoff if line quality is bad). I feel this would maximize the usefulness of error-correction for terminal users while minimizing the loss in throughput to the end-to-end file transfer programs. -------