General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Dave Collier-Brown <dave.collier-brown@indexexchange.com>
To: bloat <bloat@lists.bufferbloat.net>
Subject: [Bloat] What's a good non-intrusive way to look at bloat (and perhaps things like gout (:-))
Date: Wed, 3 Jun 2020 18:21:50 -0400	[thread overview]
Message-ID: <c8d8ed64-f6d1-31c7-2749-6c0f3bc4c33f@indexexchange.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]

We've good tools to measure network performance under stress, by the simple expedient of stressing it, but is there a good approach I could recommend to my company to monitor a bunch of reasonably modern links,  without the measurement significantly affecting their state?

I don't mind increasing bandwidth usage, but I'm downright grumpy about adding to the service time: I have a transaction that times out for gross slowness if it takes much more that an tenth of a second, and it involves a scatter-gather interaction with at least 10 customers in that time.

I'm topically interested in bloat, but really we should understand "everything" about our links. If they can get the bloats like cattle, they can probably get the gout, like King Henry the Eighth (;-))

My platform is Centos 8, and I have lots of Smarter Colleagues to help.

--dave

--
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dave.collier-brown@indexexchange.com<mailto:dave.collier-brown@indexexchange.com> |              -- Mark Twain



CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.

[-- Attachment #2: Type: text/html, Size: 2466 bytes --]

             reply	other threads:[~2020-06-03 22:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-03 22:21 Dave Collier-Brown [this message]
2020-06-03 22:30 ` Jonathan Morton
2020-06-04 10:56   ` Toke Høiland-Jørgensen
2020-06-04 12:25     ` Dave Collier-Brown

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=c8d8ed64-f6d1-31c7-2749-6c0f3bc4c33f@indexexchange.com \
    --to=dave.collier-brown@indexexchange.com \
    --cc=bloat@lists.bufferbloat.net \
    /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