From owner-freebsd-net@FreeBSD.ORG Wed Jan 16 18:02:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C91C16A419 for ; Wed, 16 Jan 2008 18:02:51 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.freebsd.org (Postfix) with ESMTP id 4152213C45A for ; Wed, 16 Jan 2008 18:02:51 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so496856pyb.10 for ; Wed, 16 Jan 2008 10:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=QyWI+EbjqNizzn4U+JOb3CmU1wEAZsl+AS2spRdBbFM=; b=kHIPT0+0q+XwoC1XBy8KFyiYoIDYzB8Vlk31DByMZhatz7eC/IrrMTU2GfDksNnpebYFJKTItZAd0NSlaSpVURWEqxQO1EFsbKyE//g5n0DBjmrUag/0TjqiN+NXLaXGW6MWU/1bpAKQb+E/l8f3f5EiU+HcSdWBNbUvL3XjWLs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=o6wHaBrD50LvJuxIHiDEgWdg8Th1lACqWYJ+Ml3RRVDDqO7FK4hX2ShI1CLcv7fQ3xLI6CdpFkSFZQRVQUD8LtW7gt4JjiQEwOQ2ctGKkgXhLPfzOfrLCE1XdG6mB7vq+XH3AupsmtjbiB8Bt1/g8ptnb9QTHuTEGiRKcba4K/Y= Received: by 10.65.233.16 with SMTP id k16mr2321207qbr.43.1200506569923; Wed, 16 Jan 2008 10:02:49 -0800 (PST) Received: by 10.64.179.20 with HTTP; Wed, 16 Jan 2008 10:02:49 -0800 (PST) Message-ID: Date: Wed, 16 Jan 2008 13:02:49 -0500 From: "Michael MacLeod" To: "Nikos Vassiliadis" In-Reply-To: <200801161204.23905.nvass@teledomenet.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <478DAF82.8010702@elischer.org> <200801161204.23905.nvass@teledomenet.gr> Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: Multilink PPP Download Speeds With Round-Robin Packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2008 18:02:51 -0000 On Jan 16, 2008 5:04 AM, Nikos Vassiliadis wrote: > On Wednesday 16 January 2008 09:44:05 Michael MacLeod wrote: > > On Jan 16, 2008 2:17 AM, Julian Elischer wrote: > > > 1/ when downloading, does the load on each incoming interface > use "netstat -I xl0 -w 1", "netstat -I xl1 -w 1" and "netstat -I tun0 -w 1" > or "systat -ifstat" for an interactive terminal display. Here's some sample output from netstat -I -w 1: input (xl0) output packets errs bytes packets errs bytes colls 226 0 337862 157 0 12911 0 219 0 325854 156 0 13040 0 232 0 344078 156 0 12696 0 226 0 337862 157 0 13063 0 input (xl1) output packets errs bytes packets errs bytes colls 224 0 334834 157 0 12931 0 223 0 336188 156 0 12992 0 225 0 336348 157 0 12971 0 input (tun0) output packets errs bytes packets errs bytes colls 447 0 658506 320 0 19148 0 457 0 669064 311 0 18440 0 454 0 667474 314 0 18500 0 442 0 648204 329 0 20044 0 According to systat -ifstat I'm getting approx 320kb a sec down each pipe, for a total throughput of approx 640kb. I was downloading several copies of the linux kernel from kernel.org in parallel, and maxing out the connection. > > > 2/ do the IP stats show a lot of out-of order packets? > > > (netstat -s -ptcp I think) > > > in fact ip reassembly problems might be of interest. > > > (netstat -s -pip (?)) > > > 3/are there many retransmissions? > Though it seems that most of the traffic is forwarded and thus the > FreeBSD host will not get much TCP. So, you wouldn't know much of > the retransmissions happening. You could use 2-3 instances of > "fetch ftp://somewhere/something" in parallel to fully utilize > your DSL lines from your FreeBSD box. # netstat -s -ptcp < snip > 396978 packets received 67065 acks (for 184666044 bytes) 11483 duplicate acks 0 acks for unsent data 296659 packets (405850084 bytes) received in-sequence 9171 completely duplicate packets (64530 bytes) 0 old duplicate packets 2 packets with some dup. data (1017 bytes duped) 20958 out-of-order packets (29976306 bytes) 0 packets (0 bytes) of data after window 0 window probes 1111 window update packets 4 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short < snip > # netstat -s -pip ip: 4622318 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 405541 packets for this host 0 packets for unknown/unsupported protocol 4198571 packets forwarded (0 packets fast forwarded) 4091 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 369718 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header So there are lots of out of order packets, but that's to be expected with round-robin multilink ppp. I ran these after downloading three copies of the linux kernel in parallel, and there are no packets that were reassembled. > [snip] > > > 5/ have you tried mpd? (in ports (multilink ppp daemon).) > > > it may have different operating characteristics.. (it does it all > > > in the kernel using netgraph). Sounds like you need to fix it > > > at the other end but mpd might trigger different behaviour > > > in the router. > > > > I looked into mpd first. I tried several of the ports (mpd, mpd4, and > > mpd5) all without much success. There isn't much documentation for mpd > > (at least compared to the standard userland ppp). > > No, mpd is adequately documented. /usr/local/share/doc/mpd* > > > Also, both of the > > individuals who I know have successfully used multilink ppp and > > TekSavvy are using userland ppp. I'd be happy to use mpd, except that > > I'm *almost* there with userland ppp, and I'm guessing it's something > > I've overlooked or misconfigered somewhere and once I find and correct > > it, it'll work like a charm. > > If you are willing to try mpd, you can find a multilink PPPoE setup here: > http://lists.freebsd.org/pipermail/freebsd-questions/2007-September/157110.html > > You can use the above example with mpd4. I tried mpd first, and did manage to find the above config and tried to use it. I was not successful unfortunately. When playing with mpd I even downloaded a local copy of the documentation you mentioned so I could easily browse it from work (I have a sweet job with plenty of downtime). Given that the other two freebsd users doing mutlilink ppp on the dslreports forums were using userland ppp, I decided to focus on that. If I can't get userland ppp working by this weekend, I'll try your mpd config once more, and see if I can make it work. However, when I was reading up on it, I seem to recall that mpd did not support either packet splitting or round-robin (I forget which, and I forget where I read it), and since my connection to TekSavvy uses both of these, it might be a non-starter. I'd really like to get userland ppp working however, since I know it's possible for it to work optimally. Thanks for your patience, Mike