From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 27AF421F1FA for ; Fri, 19 Jun 2015 17:47:05 -0700 (PDT) Received: by obpn3 with SMTP id n3so1351868obp.0 for ; Fri, 19 Jun 2015 17:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=fgNQmkHKLxE+nDHfvf5mpEDQt83tKK6oSGNPCM2kHAw=; b=xpmTbpDma4k4x+ONiZV8f8BOVEbzXFhOvAvDlJ/FXif7C+TAM3w3N1pYHLnzdKQS8t dgjtzkyh2r+yMaI1nHJ0pY++o0ixK56AqzoPqtH77i2mPFfOPGpDUkor2m/qF4JYGUoQ Hda4s5fPDFZV7zcouimhlWoZEBqR/8dYAzFbN+zTMBu9TN26jVs+yz71/M9js/pcIvnI 6AsRSDT8ixfBhaane4wXjRGcdGK+XxzEhJl3WVoF199naz+kqAb8Z4FBvbBqA44iztX7 BSJGRZ/V6DGOzoecvixwpC4GhZZbz8LV/TJEh48j92wYQqabMpvm/ucF1L824ejfF0w8 3vYg== MIME-Version: 1.0 X-Received: by 10.182.230.67 with SMTP id sw3mr15944631obc.0.1434761225214; Fri, 19 Jun 2015 17:47:05 -0700 (PDT) Received: by 10.202.105.129 with HTTP; Fri, 19 Jun 2015 17:47:05 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Jun 2015 17:47:05 -0700 Message-ID: From: Dave Taht To: "aqm@ietf.org" , bloat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] tackling torrent on a 10mbit uplink (100mbit down) X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 00:47:34 -0000 sometimes I pick the wrong week to actually try to benchmark a protocol in the wild. https://torrentfreak.com/popular-torrents-being-sabotaged-by-ipv6-peer-floo= d-150619/ On Fri, Jun 19, 2015 at 9:01 AM, Dave Taht wrote: > I just downloaded and seeded 4 popular torrents overnight using the > latest version of the transmission-gtk client. I have not paid much > attention to this app or protocol of late (about 2.5 years since last > I did this), I got a little sparked by wanting to test cdg, but did > not get that far. > > Some egress stats this morning (fq_codel on the uplink) > > bytes 32050522339 > packets 3379478 > dropped 702799 > percent 20.80% > maxpacket 28614 > > Some notes: > > 1) The link stayed remarkably usable: > > http://snapon.lab.bufferbloat.net/~d/withtorrent/vs64connectedpeers.png > > This graph shows what happened when one of the 4 torrents completed. > > The percentage of bandwidth the uplink on this test got was a bit > larger than I expected. > > Subjectively, web browsing was slower but usable, and my other normal > usages (like ssh and mosh and google music over quic) were seemingly > unaffected. (latency for small flows stayed pretty flat) > > 2) even with 69 peers going at peak, I generally did not get anywhere > near saturating the 100mbit downlink with torrent alone. > > 3) Offloads are a pita. Merely counting "packets" here does not show > the real truth of what's going on (max "packet" of 28614 bytes!?), so > linux, benchmarkers, and so on, should also be counting bytes dropped > these days. (cake does peeling of superpackets but I was not testing > that, and it too does not return bytes dropped) > > 4) *All* the traffic was udp. (uTP) Despite ipv6 being enabled (with > two source specific ipv6 ips), I did not see any ipv6 peers connect. > Bug? Death of torrent over ipv6? Blocking? What? > > 5) transmission-generated uplink traffic seemed "bursty", but I did > not tear apart the data or code. I will track queue length next time. > > 6) Although transmission seems to support setting the diffserv bytes, > it did not do so on the udp marked traffic. I think that was a tcp > only option. Also it is incorrect for ipv6 (not using IPV6_TCLASS). I > had figured (before starting the test) that this was going to be a > good test of cake's diffserv support. Sigh. Is there some other client > I could use? > > 7) transmission ate a metric ton of cpu (30% on a i3) at these speeds. > > 8) My (cable) link actually is 140mbit down, 11 up. I did not much > care for asymmetric networks when the ratios were 6x1, so 13x1 is way > up there.... > > Anyway, 20% packet loss of the "right" packets was survivable. I will > subject myself to the same test on other fq or aqms. And, if I can > force myself to, with no aqm or fq. For SCIENCE! > > Attention, DMCA lawyers: Please send takedown notices to > bufferbloat-research@/dev/null.org . One of the things truly > astonishing about this is that in 12 hours in one night I downloaded > more stuff than I could ever watch (mp4) or listen to (even in flac > format) in several days of dedicated consumption. And it all just got > rm -rf'd. It occurs to me there is a human upper bound to how much > data one would ever want to consume, and we cracked that limit at > 20mbit, with only 4k+ video driving demand any harder. When we started > bufferbloat.net 20mbit downlinks were the best you could easily get. > > > > -- > Dave T=C3=A4ht > worldwide bufferbloat report: > http://www.dslreports.com/speedtest/results/bufferbloat > And: What will it take to vastly improve wifi for everyone? > https://plus.google.com/u/0/explore/makewififast --=20 Dave T=C3=A4ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast