From owner-freebsd-current Sat Jul 1 21:40:46 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA15485 for current-outgoing; Sat, 1 Jul 1995 21:40:46 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA15467 for ; Sat, 1 Jul 1995 21:40:17 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id OAA32241; Sun, 2 Jul 1995 14:36:51 +1000 Date: Sun, 2 Jul 1995 14:36:51 +1000 From: Bruce Evans Message-Id: <199507020436.OAA32241@godzilla.zeta.org.au> To: current@freebsd.org Subject: serial ip congestion Cc: bde@zeta.org.au Sender: current-owner@freebsd.org Precedence: bulk The system seems to be unable to handle more than one active line at 115200 bps. With 2 lines at 11500 bps, each line takes turns transmitting. There seems to be a problem with lost or delayed acks. tcpdump usually shows output something like this: 02:40:35.300351 a0.1023 > a4.cmd: . 0:1440(1440) ack 1 win 17280 [tos 0x8] 02:40:35.503441 a4.cmd > a0.1023: . ack 1440 win 15840 02:40:35.503892 a0.1023 > a4.cmd: . 1440:2880(1440) ack 1 win 17280 [tos 0x8] 02:40:35.512789 a0.1023 > a4.cmd: . 2880:4320(1440) ack 1 win 17280 [tos 0x8] 02:40:35.696198 a4.cmd > a0.1023: . ack 2880 win 15840 02:40:35.696636 a0.1023 > a4.cmd: . 4320:5760(1440) ack 1 win 17280 [tos 0x8] 02:40:35.696895 a0.1023 > a4.cmd: . 5760:7200(1440) ack 1 win 17280 [tos 0x8] 02:40:35.862330 a4.cmd > a0.1023: . ack 4320 win 15840 02:40:35.862889 a0.1023 > a4.cmd: . 7200:8640(1440) ack 1 win 17280 [tos 0x8] 02:40:35.863073 a0.1023 > a4.cmd: . 8640:9120(480) ack 1 win 17280 [tos 0x8] 02:40:36.020688 a4.cmd > a0.1023: . ack 5760 win 15840 02:40:36.021168 a0.1023 > a4.cmd: . 9120:10560(1440) ack 1 win 17280 [tos 0x8] dup acks: 02:40:36.343629 a4.cmd > a0.1023: . ack 5760 win 17280 02:40:36.390202 a4.cmd > a0.1023: . ack 5760 win 17280 long pause send again: 02:40:39.800301 a0.1023 > a4.cmd: . 5760:7200(1440) ack 1 win 17280 [tos 0x8] 02:40:39.987871 a4.cmd > a0.1023: . ack 10080 win 12960 OK now 02:40:39.988292 a0.1023 > a4.cmd: . 10080:11520(1440) ack 1 win 17280 [tos 0x8] 02:40:39.992211 a0.1023 > a4.cmd: . 11520:12960(1440) ack 1 win 17280 [tos 0x8] 02:40:39.992540 a4.cmd > a0.1023: . ack 10080 win 16416 02:40:40.289384 a4.cmd > a0.1023: . ack 12960 win 16608 02:40:40.289799 a0.1023 > a4.cmd: . 12960:14400(1440) ack 1 win 17280 [tos 0x8] 02:40:40.296508 a0.1023 > a4.cmd: . 14400:15840(1440) ack 1 win 17280 [tos 0x8] 02:40:40.296762 a0.1023 > a4.cmd: . 15840:17280(1440) ack 1 win 17280 [tos 0x8] 02:40:40.531287 a4.cmd > a0.1023: . ack 14400 win 17280 02:40:40.531670 a0.1023 > a4.cmd: . 17280:18720(1440) ack 1 win 17280 [tos 0x8] 02:40:40.722439 a4.cmd > a0.1023: . ack 15840 win 17280 02:40:40.722852 a0.1023 > a4.cmd: . 18720:20160(1440) ack 1 win 17280 [tos 0x8] 02:40:40.931900 a4.cmd > a0.1023: . ack 17280 win 17280 02:40:40.932352 a0.1023 > a4.cmd: . 20160:21600(1440) ack 1 win 17280 [tos 0x8] 02:40:41.132582 a4.cmd > a0.1023: . ack 18720 win 17280 02:40:41.133029 a0.1023 > a4.cmd: . 21600:23040(1440) ack 1 win 17280 [tos 0x8] 02:40:41.133325 a0.1023 > a4.cmd: . 23040:24480(1440) ack 1 win 17280 [tos 0x8] 02:40:41.331971 a4.cmd > a0.1023: . ack 20160 win 17280 02:40:41.332444 a0.1023 > a4.cmd: . 24480:25920(1440) ack 1 win 17280 [tos 0x8] short pause dup ack: 02:40:41.807865 a4.cmd > a0.1023: . ack 20160 win 17280 long pause send again: 02:40:44.300298 a0.1023 > a4.cmd: . 20160:21600(1440) ack 1 win 17280 [tos 0x8] --- Configuration: -current all on one system my new cy driver 8 ports on connected in pairs, 2 pairs active default mtu (1500) speed 115200 bps test: rcp /kernel a4:/tmp/k4 & rcp /kernel a5:/tmp/k5 & The following variations don't help: cslip instead of ppp 2 systems sio driver on one system, cy driver on other 2 ports on each system, both pairs active mtu = mru = 16384 The following variation helps: speed 57600 (even with 4 active pairs, there are no long pauses, although there are short pauses when the disk is written to, and throughput is on 4 * 4.4K/sec). No errors were reported by the drivers or by pppstats. I noticed many bugs in the man pages: pppstats.8: The `ip' field isn't documented. The `ip' field seems to be backwards. It seems to count udp packets. `connection' is spelled `connectoin' in one place. `pppstats' should be named `pppstat' slstat.8: `slstat' calls itself `vmstat' in one place. The documented default fields are in out pack comp uncomp unknwn toss other err search miss coll but the actual default fields are in pack comp uncomp unknwn out pack comp uncomp other. There is no cross reference to `pppstats'. Bruce