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 Message-ID: <19970810112741.XA51262@uriah.heep.sax.de> In-Reply-To: <199708100822.KAA17319@helbig.informatik.ba-stuttgart.de>; from Wolfgang Helbig on Aug 10, 1997 10:22:07 %2B0200 References: <19970810090528.OS10788@uriah.heep.sax.de> <199708100822.KAA17319@helbig.informatik.ba-stuttgart.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970810112741.XA51262>