From owner-freebsd-hackers Sun Aug 24 04:14:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA27834 for hackers-outgoing; Sun, 24 Aug 1997 04:14:25 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA27824 for ; Sun, 24 Aug 1997 04:14:16 -0700 (PDT) Received: from awfulhak.org (dev.lan.awfulhak.org [10.0.1.5]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id LAA28362; Sun, 24 Aug 1997 11:52:12 +0100 (BST) Received: from dev.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.org (8.8.7/8.8.6) with ESMTP id LAA19878; Sun, 24 Aug 1997 11:52:12 +0100 (BST) Message-Id: <199708241052.LAA19878@awfulhak.org> X-Mailer: exmh version 2.0zeta 7/24/97 To: The Hermit Hacker cc: hackers@FreeBSD.ORG Subject: Re: PPP 'Bursts' with newest 3.0-CURRENT... In-reply-to: Your message of "Sat, 23 Aug 1997 22:18:49 -0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Aug 1997 11:52:12 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Hi... > > I'm really curious as to whether anyone has experience with this. I'm > running 3.0-CURRENT, and have just upgraded to the newest source tree (as of > today) in the hopes of reducing/eliminating the following 'hills and > valleys': > > ================= > # netstat -nr > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 127.2.2.2 UGSc 12 0 tun0 > 127.0.0.1 127.0.0.1 UH 1 44 lo0 > 206.231.247.114 206.231.248.173 UH 0 0 tun0 Let me guess that your ppp.conf contains: set ifaddr x.x.x.x 127.2.2.2 add 0 0 127.2.2.2 And your ppp.linkup *doesn't* contain delete all add 0 0 hisaddr If this is the case, I'd add the linkup lines. They'll remove the above default and add the correct one. Also, if it's any help, the -current ppp allows you to use hisaddr in ppp.conf too. > # ping 206.231.247.114 > PING 206.231.247.114 (206.231.247.114): 56 data bytes > 64 bytes from 206.231.247.114: icmp_seq=0 ttl=64 time=244.708 ms > 64 bytes from 206.231.247.114: icmp_seq=1 ttl=64 time=260.234 ms > 64 bytes from 206.231.247.114: icmp_seq=2 ttl=64 time=2310.207 ms > 64 bytes from 206.231.247.114: icmp_seq=3 ttl=64 time=1320.183 ms > 64 bytes from 206.231.247.114: icmp_seq=4 ttl=64 time=1730.196 ms > 64 bytes from 206.231.247.114: icmp_seq=5 ttl=64 time=2390.181 ms > 64 bytes from 206.231.247.114: icmp_seq=6 ttl=64 time=1390.230 ms > 64 bytes from 206.231.247.114: icmp_seq=7 ttl=64 time=490.176 ms > 64 bytes from 206.231.247.114: icmp_seq=8 ttl=64 time=240.180 ms > 64 bytes from 206.231.247.114: icmp_seq=9 ttl=64 time=2100.158 ms > ================= > > This is just me talking to the other end of my PPP link, with the only > load on the link being the ping session. No ftp, no telnet, no nothing. > > Now, the other end of the link is: > > ============ > Aug 23 22:13:15 thelab ppp[181]: Phase: PapInput: ACK > Aug 23 22:13:15 thelab ppp[181]: Phase: Received PAP_ACK (Welcome to NetBlazer) ============ > > A NetBlazer. > > Has anyone ever noticed this when talking to a Netblazer? I remember back > in the UUCP days that talking ??->Telebit would give bad 'interactive' response > times, but still? What sort of sustained throughput do you get with ftp ? That's usually a good indication of how the line's really behaving. I'm no expert on this though. My ISP is drifting into another phase of lousy service (doing big commits scares me 'cos I don't know if I'm going to lose the line due to a 300 second timeout). > Thanks... > > Marc G. Fournier > Systems Administrator @ hub.org > primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org > -- Brian , Don't _EVER_ lose your sense of humour....