From owner-freebsd-hackers Sun Aug 10 02:51:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA14011 for hackers-outgoing; Sun, 10 Aug 1997 02:51:05 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id CAA14002 for ; Sun, 10 Aug 1997 02:50:58 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA05921 for hackers@FreeBSD.ORG; Sun, 10 Aug 1997 11:50:56 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id LAA01377; Sun, 10 Aug 1997 11:27:42 +0200 (MET DST) Message-ID: <19970810112741.XA51262@uriah.heep.sax.de> Date: Sun, 10 Aug 1997 11:27:41 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: ISDN drivers/cards References: <19970810090528.OS10788@uriah.heep.sax.de> <199708100822.KAA17319@helbig.informatik.ba-stuttgart.de> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199708100822.KAA17319@helbig.informatik.ba-stuttgart.de>; from Wolfgang Helbig on Aug 10, 1997 10:22:07 +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Wolfgang Helbig wrote: > Just for your information, these are the ping statistics for Teles > 16/0 and BISDN on both sides. I am using raw IP over HDLC. Data > transfer rate is always 7.5 KB/s. At least that is what fetch(1) > says. As you can see from the first two turn around times, it > takes about 1.1s to dial and connect. > > PING terminator (141.31.11.23): 56 data bytes > 64 bytes from 141.31.11.23: icmp_seq=0 ttl=255 time=1115.342 ms > 64 bytes from 141.31.11.23: icmp_seq=1 ttl=255 time=111.464 ms > 64 bytes from 141.31.11.23: icmp_seq=2 ttl=255 time=30.495 ms For me, it takes a little longer: j@uriah 100% /sbin/ping uriah-gw.interface-business.de PING uriah-gw.interface-business.de (193.101.57.161): 56 data bytes 64 bytes from 193.101.57.161: icmp_seq=3 ttl=60 time=36.169 ms 64 bytes from 193.101.57.161: icmp_seq=4 ttl=60 time=36.223 ms 64 bytes from 193.101.57.161: icmp_seq=5 ttl=60 time=36.053 ms 64 bytes from 193.101.57.161: icmp_seq=6 ttl=60 time=36.239 ms ^C --- uriah-gw.interface-business.de ping statistics --- 7 packets transmitted, 4 packets received, 42% packet loss round-trip min/avg/max/stddev = 36.053/36.171/36.239/0.073 ms That makes 3 packets being lost, or ~ 3 seconds connection setup time. The lost packets are an artifact of my PPP implementation. I'm already using a second higher-priority queue for the PPP control protocol traffic, and don't serve the regular queues at all before LCP is up. Anyway, in the time between LCP is up and IPCP is being negotiated (but not yet up), the first three ping packets will already be sent, and ignored by the remote peer (since IPCP is not yet ready). The only solution for this would be to use separate queues for the various network protocols, and serve them only once the corresponding NCP is up. This IMHO wasn't worth the while, so i'm only using the two `standard' network traffic queues (slow and fast queue), and as a compromise, enable them as soon as LCP is ready. The connection setup time is one second more than it used to be, due to a braindead remote implementation that wants to negotiate a non- empty asyncmap. So now, these negotiation attempt continue until my end overruns the max_error counter, and stops negotiating asyncmap at all. This costs about one second (ten failed attempts). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)