All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Yibo Zhao <yiboz@codeaurora.org>, linux-wireless@vger.kernel.org
Cc: ath10k@lists.infradead.org
Subject: Re: [PATCH V3 3/4] mac80211: fix low throughput in multi-clients situation
Date: Mon, 23 Sep 2019 12:55:05 +0200	[thread overview]
Message-ID: <87impj5lkm.fsf@toke.dk> (raw)
In-Reply-To: <1569223201-1490-4-git-send-email-yiboz@codeaurora.org>

Yibo Zhao <yiboz@codeaurora.org> writes:

> Not long after the start of multi-clients test, not a single station is
> an eligible candidate for transmission since global virtual time(g_vt) is
> smaller than the virtual airtime(s_vt) of all the stations. As a result,
> the Tx has been blocked and throughput is quite low.
>
> This may mainly due to sync mechanism and accumulative deviation from the
> devision calculation of g_vt.
>
> For example:
> Suppose we have 50 clients in first round.
> Round 1:
> STA	weight	Tx_time_round  wt_sum	s_vt	g_vt  valid_for_next_Tx
> 1	256	2048		12800	2048	2000	N
> 2	256	2048			2048		N
> .	.	.			.		.
> .	.	.			.		.
> .	.	.			.		.
> 50	256	2048			2048		N
>
> After this round, all the stations are not valid for next transmission due to
> accumulative deviation.
>
> And if we add a new #51,
> STA	weight	Tx_time_round  wt_sum	s_vt	g_vt  valid_for_next_Tx
> 1	256	2048		13056	2048	2020	N
> 2	256	2048			2048		N
> .	.	.			.
> .	.	.			.
> .	.	.			.
> 50	256	2048			2048		N
> 51	256	1024			2524		N

That's better :)

> Sync is done by:
> max(g_vt of last round - grace period, s_vt)
> and s_vt of #51 = max(2000 - 500, 0) + 1024 = 2524, and it is more than the final
> g_vt of this round.
>
> After this round, no more station is valid for transmission.
>
> The real situation can be more complicate, above is one of the extremely case.
>
> To avoid this situation to occur, the new proposal is:
>
> - Increase the airtime grace period a little more to reduce the
>   unexpected sync
>
> - If global virtual time is less than the virtual airtime of any station,
>   sync it to the airtime of first station in the red-black tree
>
> - Round the division result

I can see why we need the second part (basically, this happens because I
forgot to add a check for "no eligible stations" in may_transmit(), like
the one in next_txq()). And rounding up the division result doesn't
hurt, I guess. But why does it help to change the grace period if we're
doing all the other stuff?

-Toke


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Yibo Zhao <yiboz@codeaurora.org>, linux-wireless@vger.kernel.org
Cc: ath10k@lists.infradead.org, Yibo Zhao <yiboz@codeaurora.org>
Subject: Re: [PATCH V3 3/4] mac80211: fix low throughput in multi-clients situation
Date: Mon, 23 Sep 2019 12:55:05 +0200	[thread overview]
Message-ID: <87impj5lkm.fsf@toke.dk> (raw)
In-Reply-To: <1569223201-1490-4-git-send-email-yiboz@codeaurora.org>

Yibo Zhao <yiboz@codeaurora.org> writes:

> Not long after the start of multi-clients test, not a single station is
> an eligible candidate for transmission since global virtual time(g_vt) is
> smaller than the virtual airtime(s_vt) of all the stations. As a result,
> the Tx has been blocked and throughput is quite low.
>
> This may mainly due to sync mechanism and accumulative deviation from the
> devision calculation of g_vt.
>
> For example:
> Suppose we have 50 clients in first round.
> Round 1:
> STA	weight	Tx_time_round  wt_sum	s_vt	g_vt  valid_for_next_Tx
> 1	256	2048		12800	2048	2000	N
> 2	256	2048			2048		N
> .	.	.			.		.
> .	.	.			.		.
> .	.	.			.		.
> 50	256	2048			2048		N
>
> After this round, all the stations are not valid for next transmission due to
> accumulative deviation.
>
> And if we add a new #51,
> STA	weight	Tx_time_round  wt_sum	s_vt	g_vt  valid_for_next_Tx
> 1	256	2048		13056	2048	2020	N
> 2	256	2048			2048		N
> .	.	.			.
> .	.	.			.
> .	.	.			.
> 50	256	2048			2048		N
> 51	256	1024			2524		N

That's better :)

> Sync is done by:
> max(g_vt of last round - grace period, s_vt)
> and s_vt of #51 = max(2000 - 500, 0) + 1024 = 2524, and it is more than the final
> g_vt of this round.
>
> After this round, no more station is valid for transmission.
>
> The real situation can be more complicate, above is one of the extremely case.
>
> To avoid this situation to occur, the new proposal is:
>
> - Increase the airtime grace period a little more to reduce the
>   unexpected sync
>
> - If global virtual time is less than the virtual airtime of any station,
>   sync it to the airtime of first station in the red-black tree
>
> - Round the division result

I can see why we need the second part (basically, this happens because I
forgot to add a check for "no eligible stations" in may_transmit(), like
the one in next_txq()). And rounding up the division result doesn't
hurt, I guess. But why does it help to change the grace period if we're
doing all the other stuff?

-Toke


  reply	other threads:[~2019-09-23 10:55 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-23  7:19 [PATCH V3 0/4] Enable virtual time-based airtime scheduler support on ath10k Yibo Zhao
2019-09-23  7:19 ` Yibo Zhao
2019-09-23  7:19 ` [PATCH V3 1/4] mac80211: Switch to a virtual time-based airtime scheduler Yibo Zhao
2019-09-23  7:19   ` Yibo Zhao
2019-09-23  7:19 ` [PATCH V3 2/4] mac80211: defer txqs removal from rbtree Yibo Zhao
2019-09-23  7:19   ` Yibo Zhao
2019-09-23 10:56   ` Toke Høiland-Jørgensen
2019-09-23 10:56     ` Toke Høiland-Jørgensen
2019-09-24  2:55     ` Yibo Zhao
2019-09-24  2:55       ` Yibo Zhao
2019-09-23  7:20 ` [PATCH V3 3/4] mac80211: fix low throughput in multi-clients situation Yibo Zhao
2019-09-23  7:20   ` Yibo Zhao
2019-09-23 10:55   ` Toke Høiland-Jørgensen [this message]
2019-09-23 10:55     ` Toke Høiland-Jørgensen
2019-09-24  8:22     ` Yibo Zhao
2019-09-24  8:22       ` Yibo Zhao
2019-09-24  8:48       ` Toke Høiland-Jørgensen
2019-09-24  8:48         ` Toke Høiland-Jørgensen
2019-09-24  8:58         ` Yibo Zhao
2019-09-24  8:58           ` Yibo Zhao
2019-09-23  7:20 ` [PATCH V3 4/4] mac80211: Sync airtime weight sum with per AC synced sta airtime weight together Yibo Zhao
2019-09-23  7:20   ` Yibo Zhao
2019-09-23 11:00   ` Toke Høiland-Jørgensen
2019-09-23 11:00     ` Toke Høiland-Jørgensen
2019-09-24  3:19     ` Yibo Zhao
2019-09-24  3:19       ` Yibo Zhao
2019-09-24  7:27       ` Toke Høiland-Jørgensen
2019-09-24  7:27         ` Toke Høiland-Jørgensen
2019-10-01 10:19 ` [PATCH V3 0/4] Enable virtual time-based airtime scheduler support on ath10k Johannes Berg
2019-10-01 10:19   ` Johannes Berg
2019-10-01 10:59   ` Yibo Zhao
2019-10-01 10:59     ` Yibo Zhao
2019-10-01 11:05     ` Toke Høiland-Jørgensen
2019-10-01 11:05       ` Toke Høiland-Jørgensen

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=87impj5lkm.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=ath10k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=yiboz@codeaurora.org \
    /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.