All of lore.kernel.org
 help / color / mirror / Atom feed
From: "John W. Linville" <linville@tuxdriver.com>
To: Nathaniel Smith <njs@pobox.com>
Cc: linux-wireless@vger.kernel.org,
	bloat-devel@lists.bufferbloat.net, johannes@sipsolutions.net,
	nbd@openwrt.org
Subject: Re: [RFC v2] mac80211: implement eBDP algorithm to fight bufferbloat
Date: Mon, 21 Feb 2011 13:47:17 -0500	[thread overview]
Message-ID: <20110221184716.GD9650@tuxdriver.com> (raw)
In-Reply-To: <AANLkTikJeN=CG20PAj-n1ZoaiJLbsiG=jfZnbu4Or3KS@mail.gmail.com>

On Fri, Feb 18, 2011 at 07:44:30PM -0800, Nathaniel Smith wrote:
> On Fri, Feb 18, 2011 at 1:21 PM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > +       /* grab timestamp info for buffer control estimates */
> > +       tserv = ktime_sub(ktime_get(), skb->tstamp);
> [...]
> > +               ewma_add(&sta->sdata->qdata[q].tserv_ns_avg,
> > +                        ktime_to_ns(tserv));
> 
> I think you're still measuring how long it takes one packet to get
> from the end of the queue to the beginning, rather than measuring how
> long it takes each packet to go out?

Yes, I am measuring how long the driver+device takes to release each
skb back to me (using that as a proxy for how long it takes to get
the fragment to the next hop).  Actually, FWIW I'm only measuring
that time for those skb's that result in a tx status report.

I tried to see how your measurement would be useful, but I just don't
see how the number of frames ahead of me in the queue is relevant to
the measured link latency?  I mean, I realize that having more packets
ahead of me in the queue is likely to increase the latency for this
frame, but I don't understand why I should use that information to
discount the measured latency...?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

  reply	other threads:[~2011-02-21 19:00 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-13 17:56 [PATCH 0/5] iwlwifi: Auto-tune tx queue size to maintain latency under load Nathaniel J. Smith
2011-02-13 17:56 ` [PATCH 1/5] iwlwifi: Simplify tx queue management Nathaniel J. Smith
2011-02-14  9:57   ` Johannes Berg
2011-02-14 22:17     ` Nathaniel Smith
2011-02-14 22:45       ` wwguy
2011-02-15  0:15         ` Dave Täht
2011-02-16  9:16         ` Stanislaw Gruszka
2011-02-16 14:41           ` John W. Linville
2011-02-16 15:13             ` wwguy
2011-02-15 12:11       ` Johannes Berg
2011-02-14 15:33   ` wwguy
2011-02-13 17:56 ` [PATCH 2/5] iwlwifi: Convert the tx queue high_mark to an atomic_t Nathaniel J. Smith
2011-02-14 12:16   ` Johannes Berg
2011-02-14 22:35     ` Nathaniel Smith
2011-02-15 12:08       ` Johannes Berg
2011-02-15 17:37         ` Nathaniel Smith
2011-02-13 17:56 ` [PATCH 3/5] iwlwifi: Invert the sense of the queue high_mark Nathaniel J. Smith
2011-02-13 17:56 ` [PATCH 4/5] iwlwifi: auto-tune tx queue size to minimize latency Nathaniel J. Smith
2011-02-14 12:17   ` Johannes Berg
2011-02-14 21:58     ` Nathaniel Smith
2011-02-15 12:13       ` Johannes Berg
2011-02-15 15:03         ` John W. Linville
2011-02-16  8:59           ` Johannes Berg
2011-02-15 17:31         ` Nathaniel Smith
2011-02-14 15:46   ` wwguy
2011-02-13 17:56 ` [PATCH 5/5] iwlwifi: make current tx queue sizes visible in debugfs Nathaniel J. Smith
2011-02-14  0:32 ` [PATCH 0/5] iwlwifi: Auto-tune tx queue size to maintain latency under load Julian Calaby
2011-02-14  3:28   ` Nathaniel Smith
2011-02-16 15:50 ` John W. Linville
2011-02-16 23:08   ` Nathaniel Smith
2011-02-16 23:42     ` wwguy
2011-02-17  1:49 ` [RFC] mac80211: implement eBDP algorithm to fight bufferbloat John W. Linville
2011-02-17  3:31   ` Ben Greear
2011-02-17  4:26   ` Nathaniel Smith
2011-02-17  8:31   ` Johannes Berg
2011-02-18 21:21   ` [RFC v2] " John W. Linville
2011-02-19  3:44     ` Nathaniel Smith
2011-02-21 18:47       ` John W. Linville [this message]
2011-02-21 23:26         ` Nathaniel Smith
2011-02-23 22:28           ` John W. Linville
2011-02-25 18:21             ` Nathaniel Smith
2011-02-25 18:27               ` Nathaniel Smith
2011-02-20  0:37     ` Nathaniel Smith
2011-02-21 18:52       ` John W. Linville
2011-02-21 15:28     ` Johannes Berg
2011-02-21 19:06       ` John W. Linville
2011-02-21 20:26         ` Tianji Li
2011-02-28 13:07         ` Johannes Berg

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110221184716.GD9650@tuxdriver.com \
    --to=linville@tuxdriver.com \
    --cc=bloat-devel@lists.bufferbloat.net \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=nbd@openwrt.org \
    --cc=njs@pobox.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.