Lowering Ping Latency of Analog-Modem PPP connections
PBruley
the ping times) of analog modem PPP connection (Linux Client to ISP) ?
1) Are there any options in PPP that can be tweaked to gain improvements?
2) Are there any options in "setserial" that can be tweaked to gain
improvements?
3) Is there any way to set the buffer size of the modem Transmit/Recieve
que ?
Thanks in advance
Peter
James Carlson
> Just wondering if any one know of any way to lower the latency (lower
> the ping times) of analog modem PPP connection (Linux Client to ISP) ?
Why do you care? (Note that ping uses ICMP Echo messages, and is
often given short-shrift by both hosts and routers. All other data is
more important than handling these messages.)
> 1) Are there any options in PPP that can be tweaked to gain improvements?
"it depends"
Running the serial link at as high a rate as is supported often
helps. In most cases, enabling data compression (CCP) helps. Making
sure the ACCM is as lean as possible helps.
Of course, the latter of those two are done by default on pppd, so
there's nothing special that you can (or should) do.
VJ compression doesn't help at all -- ping uses ICMP.
> 2) Are there any options in "setserial" that can be tweaked to gain
> improvements?
Likely not.
> 3) Is there any way to set the buffer size of the modem
> Transmit/Recieve que ?
Read your modem's manual and examine the AT command set for it
carefully. On some modems, it is possible to tell the modem's V.42
engine to forward V.42 frames based on reception of 'special'
characters. Setting this, if it exists, to hex 7E (decimal 126)
helps.
Sometimes, using a lower fixed data rate on the modulation (and
disabling rate renegotiation) makes latency more predicable -- and
occasionally even better.
Disabling V.42bis data compression in the modem often also helps link
latency. Disabling V.42 error correction can also help, but it also
almost always results in an unusable connection.
--
James Carlson, Solaris Networking <james.d...@east.sun.com>
SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
Clifford Kite
> PBruley <pbr...@highstream.net> writes:
>> Just wondering if any one know of any way to lower the latency (lower
>> the ping times) of analog modem PPP connection (Linux Client to ISP) ?
> Why do you care? (Note that ping uses ICMP Echo messages, and is
> often given short-shrift by both hosts and routers. All other data is
> more important than handling these messages.)
It occurred to me that he might really be interested in interactive
gaming rather than pings. In that case a certain person, whose advice
I've come to trust, might recommend lowering the PPP link MTU, and also
requesting a lower MRU. Say to 296 or even 168 for TCP, or 284 or even
156 for UDP, although the lower values have a larger percentage overhead
than the larger ones.
Be aware that this may not be a good stratgy except for gaming, and
that requesting a lower MRU may actually hurt if the ISP has a poorly
configured firewall, but certainly just lowering the MTU shouldn't hurt,
and should help - for gaming anyway.
--
Clifford Kite Email: "echo xvgr_yv...@ri1.arg|rot13"
PPP-Q&A links, downloads: http://users3.ev1.net/~ckite/public_html/
/* Speak softly and carry a +6 two-handed sword. */
James Carlson
> James Carlson <james.d...@sun.com> wrote:
> > PBruley <pbr...@highstream.net> writes:
> >> Just wondering if any one know of any way to lower the latency (lower
> >> the ping times) of analog modem PPP connection (Linux Client to ISP) ?
>
> > Why do you care? (Note that ping uses ICMP Echo messages, and is
> > often given short-shrift by both hosts and routers. All other data is
> > more important than handling these messages.)
>
> It occurred to me that he might really be interested in interactive
> gaming rather than pings. In that case a certain person, whose advice
> I've come to trust, might recommend lowering the PPP link MTU, and also
> requesting a lower MRU. Say to 296 or even 168 for TCP, or 284 or even
> 156 for UDP, although the lower values have a larger percentage overhead
> than the larger ones.
;-}
If the application is gaming (and not just ping), then you probably
also want to disable the modem's data compression and it'd be good if
you could turn off the modem's error control, though I doubt that the
latter is really feasible with a modern modem.
A significant portion of the latency over the link (at least something
like 40ms in each direction) is in the modulation itself. The
trade-off between modulation delay and data rate is probably pretty
hard to make for small packets. (I forget the actual numbers involved
here because it's been too many years since I worked on things such as
this. But suppose you ran over TCP with VJ compression and regularly
sent packets with just 4 bytes of user data. This would take roughly
42 milliseconds to cross a 2400bps link. If all you cared about was
end-to-end latency, you *might* do better by using a slower but less
complex modulation scheme.)
The same sort of problem shows up with initial connect time: it takes
so long for a V.90 (or even V.32) modem to train up that the fastest
way to do transaction processing (connect, send query, get answer,
hang up) is to use a lowly 1200bps modem. Faster isn't always better.
(Or even faster. :-/)
> Be aware that this may not be a good stratgy except for gaming, and
> that requesting a lower MRU may actually hurt if the ISP has a poorly
> configured firewall, but certainly just lowering the MTU shouldn't hurt,
> and should help - for gaming anyway.
Perhaps. The assumption there would have to be that you're
communicating with lots of peers and you don't want to have an update
from one peer serialized behind another. I don't know enough about
the architecture of games (are they peer-to-peer or client-server?) to
guess at whether this would help.
PBruley
James Carlson wrote:
>Clifford Kite <ki...@see.signature.id> writes:
>
>>James Carlson <james.d...@sun.com> wrote:
>>
>>>PBruley <pbr...@highstream.net> writes:
>>>
>>>>Just wondering if any one know of any way to lower the latency (lower
>>>>the ping times) of analog modem PPP connection (Linux Client to ISP) ?
>>>>
>>>Why do you care? (Note that ping uses ICMP Echo messages, and is
>>>often given short-shrift by both hosts and routers. All other data is
>>>more important than handling these messages.)
>>>
>>It occurred to me that he might really be interested in interactive
>>gaming rather than pings.
>>
Correct
UDP packet Client - Server Gaming
>> In that case a certain person, whose advice
>>I've come to trust, might recommend lowering the PPP link MTU, and also
>>requesting a lower MRU. Say to 296 or even 168 for TCP, or 284 or even
>>156 for UDP, although the lower values have a larger percentage overhead
>>than the larger ones.
>>
I always run 576 MTU/MRU but I will go smaller as you suggest and see if
it helps
>
>;-}
>
>If the application is gaming (and not just ping), then you probably
>also want to disable the modem's data compression
>
I have tried this but the link becomes unusable as the bandwidth seems
to become too small to handle the amount of traffice required.
I have read many articles stating that turning off the hardware
compression can lower your latency by 20-30ms. Too bad the band-width
doesn't stay the same. I think that if bsd_comp/deflate was supported at
my ISP server side that this would probably work. As it is my ISP only
supports VJcomp which doesn't help game play. (The UDP packets I am
sending do not get compressed by VJComp.)
I have found 2 more useful hints to help speed up on-line gaming:
1) Remove the transmit buffer queue for the ppp connection using ifconfig:
ifconfig ppp0 txqueuelen 0
2) Add the "low_latency" & "closing_wait none" options to the serial
port using setserial:
setserial /dev/modem low_latency closing_wait none
Clifford Kite
>> 3) Is there any way to set the buffer size of the modem
>> Transmit/Recieve que ?
> Read your modem's manual and examine the AT command set for it
> carefully. On some modems, it is possible to tell the modem's V.42
> engine to forward V.42 frames based on reception of 'special'
> characters. Setting this, if it exists, to hex 7E (decimal 126)
> helps.
This seems like it would help to some extent for gaming too, since the
modem would send data in it's buffer immediately upon receiving a PPP
frame separator, 7f, which never appears in the data within the frame
itself. The end (and possibly the beginning) of an incoming frame would
trigger the modem to send the data it has ready.
I have no idea how much it would help a gamer, but it would be rather
interesting to find out. To me - who has done no on-line gaming - it
certainly looks promising, and perhaps it could turn out to help enough
to be worth shopping for a modem with that feature.
-- Clifford Kite Email: "echo xvgr_yv...@ri1.arg|rot13"
PPP-Q&A links, downloads: http://users3.ev1.net/~ckite/public_html/
/* Slogan appropriate for a certain well-know software company:
FAILURE IS NOT AN OPTION - it is built into the operating system
and comes bundled with the software. */