guest@brix4:/mt/scratch/tmp/fpga/linux/programs$ ping -s 77 192.168.5.7 PING 192.168.5.7 (192.168.5.7) 77(105) bytes of data. 85 bytes from 192.168.5.7: icmp_seq=1 ttl=64 time=56.2 ms 85 bytes from 192.168.5.7: icmp_seq=2 ttl=64 time=1117 ms 85 bytes from 192.168.5.7: icmp_seq=3 ttl=64 time=84.6 ms 85 bytes from 192.168.5.7: icmp_seq=4 ttl=64 time=55.4 ms
root@buildroot:~# ping 22.214.171.124 PING 126.96.36.199 (188.8.131.52): 56 data bytes 64 bytes from 184.108.40.206: seq=6 ttl=54 time=62.658 ms 64 bytes from 220.127.116.11: seq=15 ttl=54 time=66.016 ms ... root@buildroot:~# cat ppp.sh #!/bin/sh stty raw pppd \ asyncmap 000A0000 \ escape 0,FF \ mru 1492 mtu 1492 \ noauth local debug dump nodefaultroute nocrtscts \
root@buildroot:~# ping -s 88 www.google.com PING www.google.com (18.104.22.168): 88 data bytes 76 bytes from 22.214.171.124: seq=0 ttl=54 time=59.833 ms 76 bytes from 126.96.36.199: seq=1 ttl=54 time=61.755 ms 76 bytes from 188.8.131.52: seq=2 ttl=54 time=58.294 ms ^C --- www.google.com ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 58.294/59.960/61.755 ms root@buildroot:~# ping -s 89 www.google.com PING www.google.com (184.108.40.206): 89 data bytes ^C --- www.google.com ping statistics --- 20 packets transmitted, 0 packets received, 100% packet loss
actually strange - google responds with same packet length but still saxon doesn't hear it - maybe after sending longer packet to google, serial port needs a time for "recovery" in order to listen?
Maybe not strange. When sending, if the UART outbound queue is full Linux will wait for it to empty again. When receiving, if the inbound UART queue is full characters get dropped, i.e. packet loss. 88 bytes of payload + 24 bytes of IP & ICMP header is 112 bytes - very close to the 128 buffer size, especially if some bytes need to be escaped into a 2 byte sequence. Have you tried with h/w flow control on the inbound queue?
Another option could be to reduce the mtu/mru to 75 bytes or so. TCP should be able to overcome the packet loss as long as at least some packages get through.