Date: Wed, 16 Jan 2008 13:02:49 -0500 From: "Michael MacLeod" <mikemacleod@gmail.com> To: "Nikos Vassiliadis" <nvass@teledomenet.gr> Cc: freebsd-net@freebsd.org, Julian Elischer <julian@elischer.org> Subject: Re: Multilink PPP Download Speeds With Round-Robin Packets Message-ID: <e8f0b580801161002q110459e8oca123a34776c9a75@mail.gmail.com> In-Reply-To: <200801161204.23905.nvass@teledomenet.gr> References: <e8f0b580801152214j63af04c0t693f4ed035d75b51@mail.gmail.com> <478DAF82.8010702@elischer.org> <e8f0b580801152344p3e6f6d45v4561f882f15443b9@mail.gmail.com> <200801161204.23905.nvass@teledomenet.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 16, 2008 5:04 AM, Nikos Vassiliadis <nvass@teledomenet.gr> wrote:
> On Wednesday 16 January 2008 09:44:05 Michael MacLeod wrote:
> > On Jan 16, 2008 2:17 AM, Julian Elischer <julian@elischer.org> 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 <interface> -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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e8f0b580801161002q110459e8oca123a34776c9a75>