kernel or ppp problem?
I am seeing an abnormal delay in packets passed over a PPP link
(a null modem cable between two Linux systems) and would post a
formal bug report if I were more confident which package maintainer
to report to.
It might be in the pppd process or it might be in the compiled
kernel ppp support code. I can do the "reportbug" program to get
this properly entered in the bug tracking system so just tell me
which seems to be the appropriate package.
Here is a brief description:
---
When a single packet is received from the serial port there is
approx. a 60% probability that it will NOT be passed thru to the
application for approx. 3.75 SECONDS. Or, until another packet
arrives and (apparently) "pushes" it throught the pipe.
This effect is seen in ping tests, in ftp transactions, and in
tcp (html) sessions passing over this PPP path. I've used tcpdump
to capture time information simultaneously at both ends of the PPP
path to verify that the delayed packet was, in fact, sent from one
end but not released by the ppp process at the other end.
--------------------------------------------------------------
Here are more details:
Linux kernel 2.6.18; ppp 2.4.4. (System upgraded to Etch release)
EXAMPLE 1: Normal ping response. Given serial baud rate and packet
size, a 150 ms. response can be considered "immediate"
[ping -c 1 192.168.100.7]
PING 192.168.100.7 (192.168.100.7) 56(84) bytes of data.
64 bytes from 192.168.100.7: icmp_seq=1 ttl=255 time=147 ms
--- 192.168.100.7 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 147.635/147.635/147.635/0.000 ms
EXAMPLE 2: Delayed ping response, I'm calling it 3.75 seconds
delay, i.e. measured 3.937 - minimum 0.150
[ping -c 1 192.168.100.7]
PING 192.168.100.7 (192.168.100.7) 56(84) bytes of data.
64 bytes from 192.168.100.7: icmp_seq=1 ttl=255 time=3937 ms
--- 192.168.100.7 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3937.058/3937.058/3937.058/0.000 ms
EXAMPLE 3: Used default ping interval, 1 second. Last ping
appears "lost" but I believe ping process exited
before the reply was seen. (see example 4)
[ping -c 5 192.168.100.7]
PING 192.168.100.7 (192.168.100.7) 56(84) bytes of data.
64 bytes from 192.168.100.7: icmp_seq=1 ttl=255 time=1074 ms
64 bytes from 192.168.100.7: icmp_seq=2 ttl=255 time=159 ms
64 bytes from 192.168.100.7: icmp_seq=3 ttl=255 time=159 ms
64 bytes from 192.168.100.7: icmp_seq=4 ttl=255 time=1080 ms
--- 192.168.100.7 ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4004ms
rtt min/avg/max/mdev = 159.995/618.713/1080.111/458.722 ms, pipe 2
EXAMPLE 4: Used 5 second ping interval, long enough for delayed
replies to be passed through.
[ping -c 5 -i 5 192.168.100.7]
PING 192.168.100.7 (192.168.100.7) 56(84) bytes of data.
64 bytes from 192.168.100.7: icmp_seq=1 ttl=255 time=149 ms
64 bytes from 192.168.100.7: icmp_seq=2 ttl=255 time=3939 ms
64 bytes from 192.168.100.7: icmp_seq=3 ttl=255 time=149 ms
64 bytes from 192.168.100.7: icmp_seq=4 ttl=255 time=139 ms
64 bytes from 192.168.100.7: icmp_seq=5 ttl=255 time=3939 ms
--- 192.168.100.7 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 20008ms
rtt min/avg/max/mdev = 139.997/1663.749/3939.866/1858.443 ms
Reply to: