From: cloneman <bufferbloat@flamingpc.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: bloat <bloat@lists.bufferbloat.net>, dave.taht@gmail.com
Subject: Re: [Bloat] unfixable bloat on Cable modem CODA-4680 (puma 7)
Date: Thu, 28 Mar 2019 16:44:52 -0400 [thread overview]
Message-ID: <CABQZMoKqNd0048S+MbPs1pgFRKGhOkYza+EbLEyZN4+V1JTf2A@mail.gmail.com> (raw)
In-Reply-To: <2F486932-0989-498D-A2CD-2E6EB520A758@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]
I have discovered the source of the confusion. This is different, but
similar to PUMA6 problems, I think.
Certain types of traffic are getting de-prioritized, especially small
packets under load.
Comparison:
Normal ping:
Minimum = 17ms, Maximum = 734ms, *Average = 202ms*
Large 1472-byte ping
Minimum = 18ms, Maximum = 229ms, *Average = 47ms*
TCP-Based ping via psping.exe
Minimum = 14.15ms, Maximum = 40.39ms, *Average = 25.88ms*
For more fun:
ICMP in a VPN, ping set to 13-bytes
Minimum = 36ms, Maximum = 602ms, *Average = 208ms*
ICMP in a VPN, 1300 bytes
Minimum = 24ms, Maximum = 72ms, *Average = 40ms*
This explains why certain synthetic bufferbloat benchmarks were passing
with flying colors but my basic ICMP ping was terrible under load. VPN does
not seem to help, so it's not packet inspection... it's failure of tiny
packets and success of larger, normal ones.
The problem only occurs during download stress, not upload stress. Anyway,
I guess this is mostly an FYI.
Perhaps a script that does variable packet sizes for the generated small
flow traffic could be useful to someone in the future.
On Thu, Mar 28, 2019 at 8:03 AM Sebastian Moeller <moeller0@gmx.de> wrote:
> HI cloneman,
>
> maybe have a look at http://www.dslreports.com/tools/puma6?
>
> > On Mar 28, 2019, at 12:00, cloneman <bufferbloat@flamingpc.com> wrote:
> >
> > I'm getting a weird problem with this new modem , it's Docsis 3.1
> >
> > latency/jitter measured via ping is about ~300ms during download
> pressure of 3 http transfers. The latency doesn't appear on synthetic
> bufferbloat benchmarks, though. (dslreports ; 20ms ("A")
> >
> > question: trying to figure out why I'm seeing this particular behavior,
> and determine if it'd a real issue or just an anomalie with ICMP traffic
> >
> > I've not seen ping do this with other modems.
> >
> > Perhaps I need to try some other traffic generation/ capture tools?
> >
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>
[-- Attachment #2: Type: text/html, Size: 3411 bytes --]
prev parent reply other threads:[~2019-03-28 20:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-28 11:00 cloneman
2019-03-28 11:10 ` Dave Taht
2019-03-28 12:02 ` Sebastian Moeller
2019-03-28 20:44 ` cloneman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABQZMoKqNd0048S+MbPs1pgFRKGhOkYza+EbLEyZN4+V1JTf2A@mail.gmail.com \
--to=bufferbloat@flamingpc.com \
--cc=bloat@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=moeller0@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox