> Just at a guess (and I don't know ppp internals that well), it > might be PPP escaping the zero as a control character. If the > software had to handle the escape sequence for "N thousand" > nulls, it might bog it down a bit, and those escape sequences > might themselves take up more space, as they often do. Really, > though, I can't see that accounting for the difference on a > modem that does compression. The compression should be more of > a factor than escaping every character even, assuming it IS a > compressed link. > > I don't know if PPP even escapes nulls.
You set up what characters you want escaped (in the receive direction) in the /etc/ppp/options file (or ~/.ppprc) with the "asyncmap <map>" option. <map> is a 32 bit hex number with each bit representing a character to escape. "asyncmap 0x00000000" will escape no characters which is what one would want in the general case (8-bit clean line, hardware flow control). If you omit the asyncmap option, *all* control characters (0-31 decimal) are escaped. So forgetting to put in the asyncmap option will slow down your PPP connection by about 12.5% (if my math is correct) for random data. Transfering a file of all zeros should make your connection twice as slow if your modem is not doing hardware compression. Gerry
