do not use error correction or compression. (they will slow you down)
huh?!? my file transfer times would *double* if i turned off v.42bis (modem compression). *that* would slow me down. and you can't run v.42bis without running the error handling protocol (v.42), for obvious reasons. what's more, v.42 gives an immediate 20% (or so) increase in throughput, by eliminating start and stop bits. arguably, i could (and should) be running compression in my slip or ppp driver, but certainly it is false to say that v.42bis and v.42 slow me down -- the opposite is true.
and tcp does it's own error correction. as for 160ms round trip times that is acceptable for slip.
i don't much care about round-trip times, as i use my slip line principally for afs, which runs as a data stream. round-trip delays are amortized over file transfers. phil karn's points about modem buffering interfering with type-of-service queueing are the strongest condemnations of modern modems, in my view. i wish someone would build a modem that recognized ip packet framing. peter
do not use error correction or compression. (they will slow you down)
huh?!? my file transfer times would *double* if i turned off v.42bis (modem compression). *that* would slow me down. and you can't run v.42bis without running the error handling protocol (v.42), for obvious reasons. what's more, v.42 gives an immediate 20% (or so) increase in throughput, by eliminating start and stop bits.
I think there's a confusion here between the conflicting goals of low delay and high throughput. Depending on which is more important to your application, V.42bis will either "slow you down" or "speed you up". Unfortunately, most modems don't give the user any way to say whether delay or throughput is more important to you at the moment; the modems themselves try to infer this automatically from the data streams you send them. And they bias the decision in favor of greater throughput. This is right for most computer applications, but not so for real time voice. Phil
phil karn's points about modem buffering interfering with type-of-service queueing are the strongest condemnations of modern modems, in my view. i wish someone would build a modem that recognized ip packet framing.
This is why you'd really want to run your modems synchronously. You'd just send HDLC frames that encapsulated IP packets (fragmentation may be required). This is how most IP routers work over serial links.
This is why you'd really want to run your modems synchronously. You'd just send HDLC frames that encapsulated IP packets (fragmentation may be required). This is how most IP routers work over serial links.
Indeed. And because LAPM uses HDLC framing over the modem, you could be completely compatible with a regular (asynch DTE interface) V.42bis modem on the other end of the call. But by implementing V.42bis yourself, you would have complete control over when frames get sent, and how large they are. Phil
participants (3)
-
Eric Blossom -
karn＠qualcomm.com -
peter honeyman