From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A13593B2A4 for ; Thu, 5 Oct 2017 01:41:45 -0400 (EDT) Received: by mail-qt0-x235.google.com with SMTP id z50so18370525qtj.4 for ; Wed, 04 Oct 2017 22:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=14I6GXL7yhP3jN/YodqqDcVmd+9BLdq0KBtlLh+rzm8=; b=P6G9FhPn4RxBGHmeADZH6wybtIAXFm9vR4/CAOBuUdRSG8YY6Jah2D3OexzN4usU7d Lb2JZuxTwPgYOR2q399mkmI3pZrB86N/bULSeOhc44uaIAwONTWONkqOBVQES8ygZP1X JcUk64sjnS6T/iGJPNdgUUuSB+nKqFvbXmL22L6lDjjANKABTpk3RBXFk5MSGW0CCICi PKaJtNHJNGEBPdSAbAB/yzVt+UmwdL8Ddsgrl2dh3j0NbrRy9lyu2F/LdavSezvJkEg8 5ohQY1D4QxUzZo6/o3yWm5jSdo36T26/QcDLEEv6HVqjj1+bSExoCJI1lyf4V00LgcuZ 0uLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=14I6GXL7yhP3jN/YodqqDcVmd+9BLdq0KBtlLh+rzm8=; b=D42mLTVWLcD0XA3jUUMM3AQ8pqLc1IJejMpPDxRZVjkm1gXw+miqCTixGFc+o0Fnrk VAcGJLn46mEIf9oSmGcQFqXNLEC1vKwgvKkSkxfwJr1/qIrrQBWG5oT+Joba3BZwtWik bRN2BC+kkcODGe8zYtut+stViOlmYuJZCYI21xW7zZqcOlJLBuTwYIEU3briDiCdNKg/ pde3tXPDFcDM+XQz+zD8PK/YnN7NrnEcq1g/kfOOWqWjvYjTx7a+IYdyGNrPpn4uePRx MQRgLGpaLuPu3paUO/moAek+mZxtEcLe2ScZ7Fx3JE2qwA0HlsHKc51eedzT+t7J2/1w wUZg== X-Gm-Message-State: AMCzsaWYwL4+348mTGwbqAFkupZHB+GJgw8fuVf9pXtmRYx8wQ8vDgN6 fnZcJ7ntAPnq+EWvyG/vphgDG/jVo5S9sxgdJzhG9KL5 X-Google-Smtp-Source: AOwi7QD2M5PypuNTSIhZl5Ofp1+vcFBeNU9U9t5BxWj1lXUsuYJz0y7ko5oWgePiIR5RTH1TUQNRLCmscH7/H0vVrsU= X-Received: by 10.237.63.248 with SMTP id w53mr31448134qth.290.1507182104852; Wed, 04 Oct 2017 22:41:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.170.149 with HTTP; Wed, 4 Oct 2017 22:41:44 -0700 (PDT) From: Aaron Wood Date: Wed, 4 Oct 2017 22:41:44 -0700 Message-ID: To: bloat Content-Type: multipart/alternative; boundary="001a1144ee6cf8bddf055ac62dd3" Subject: [Bloat] fremont flent node: what's the network setup there? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 05:41:45 -0000 --001a1144ee6cf8bddf055ac62dd3 Content-Type: text/plain; charset="UTF-8" I'm comparing some numbers between the fremont node and a friend's Droplet running netserver. We've previous noted that we don't see more than a 120Mbps download rate from the fremont node. Today I was able to confirm in multiple back-to-back runs that the fremont node was only giving me about 120Mbps of throughput, while both dslreports and the droplet were giving me ~180Mbps (and 500ms of latency in the cable head-end). However, I noticed when running without SQM on my router here at home that download latency from the fremont node was virtually non-existent, vs. the very large latency that I was seeing from both the droplet and dsl-reports. Box-plots: https://drive.google.com/file/d/0B1xfqN4OiFEPODI4cEZjZ1NGeGVtc3RKbGJQR3ltaHhyb1Bz/view That very, very low send latency from the fremont node makes me think that it might be running BBR as the default congestion control algorithm? If I run the cubic-reno test without any SQM, the results look pretty awful, but without specifying the TCP cc alg, it seems to behave very, very well (albeit not as much throughput as I think I should get). Re-enabling cake (at 170Mbps downstream, 12Mbps up), I can't seem to get much more than that 120Mbps from the router (even though I've tested it at 900Mbps as the netserver host itself). Am I running into a cpu limitation in the NAT/forwarding modules? -Aaron --001a1144ee6cf8bddf055ac62dd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm comparing some numbers between the fremont node an= d a friend's Droplet running netserver.

We've pr= evious noted that we don't see more than a 120Mbps download rate from t= he fremont node. =C2=A0

Today I was able to confir= m in multiple back-to-back runs that the fremont node was only giving me ab= out 120Mbps of throughput, while both dslreports and the droplet were givin= g me ~180Mbps (and 500ms of latency in the cable head-end).

<= /div>
However, I noticed when running without SQM on my router here at = home that download latency from the fremont node was virtually non-existent= , vs. the very large latency that I was seeing from both the droplet and ds= l-reports.

Box-plots:

That very, very low send lat= ency from the fremont node makes me think that it might be running BBR as t= he default congestion control algorithm?=C2=A0 If I run the cubic-reno test= without any SQM, the results look pretty awful, but without specifying the= TCP cc alg, it seems to behave very, very well (albeit not as much through= put as I think I should get).

Re-enabling cake (at= 170Mbps downstream, 12Mbps up), I can't seem to get much more than tha= t 120Mbps from the router (even though I've tested it at 900Mbps as the= netserver host itself).=C2=A0 Am I running into a cpu limitation in the NA= T/forwarding modules?

-Aaron
--001a1144ee6cf8bddf055ac62dd3--