From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.github.com (out-25.smtp.github.com [192.30.252.208]) by mail.toke.dk (Postfix) with ESMTPS id 218FB85AA75 for ; Thu, 24 Jun 2021 17:34:44 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key) header.d=github.com header.i=@github.com header.b=O5UGtUbC Received: from github.com (hubbernetes-node-6d0365b.ash1-iad.github.net [10.56.112.66]) by smtp.github.com (Postfix) with ESMTPA id 97916840591 for ; Thu, 24 Jun 2021 08:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1624548883; bh=k7lFW9NEbRecZcQa+QORmhOdHwwYKuoGiasemEwDtiw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=O5UGtUbCM5TmMGoCA7fp17zye4mQHHDyLBFlaIMBQMHDNY7491q70rVVp81YWJ1Vw O01gBmAQ0S6qWbfkumSHd7hHPvqh2wigf9P4Y19+DureCRbGBqPQGh5ym1ztcEvA4o SGrex9Ja6/rjwyPQ6u2FRzumOxphvrHSC6cZiVTY= Date: Thu, 24 Jun 2021 08:34:43 -0700 From: "Kirill Lukonin (EvilWirelessMan)" To: tohojo/flent Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_60d4a61393abf_5ac6fc105120"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: klukonin X-GitHub-Recipient: flent-users X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: flent-users@flent.org Message-ID-Hash: KACPBSI37TFBE6FK626IKP4OPCZXLYLL X-Message-ID-Hash: KACPBSI37TFBE6FK626IKP4OPCZXLYLL X-MailFrom: noreply@github.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Subscribed X-Mailman-Version: 3.3.4 Reply-To: tohojo/flent Subject: [Flent-users] Re: [tohojo/flent] Plots are broken somehow (#227) List-Id: Flent discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: ----==_mimepart_60d4a61393abf_5ac6fc105120 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @dtaht it's a BCM4359 with bcmdhd driver (amlogic fork). FullMAC architecture doesn't let us use airtime fairness. So we did some job to decrease buffering inside the driver, we turned off power_save, roaming, periodic scans, background scanning. We also use a combination of fq_codel qdisc for wlan0 interface and BBR tcp congestion algo. bcmdhd driver do some weird things. According to my limited understanding tx_glom and rx_glom work independently from kernel scatter-gather mechanism. So a bunch of tx frames would be splitted and aligned according to tx_glom bucket size every time we try to send something. This chip uses single queue for tx and rx, so according to it's architecture there is no way to achieve low delay with medium and heavy traffic scenarios. Nowadays many android devices use this driver without any optimizations. And it works awful with pfifofast qdisc which is default for android. So much to improve... P.S. It looks like the default fq_codel interval (100ms) is not enough for mobile devices in some scenarios. 300ms ought to be enough for everybody. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/tohojo/flent/issues/227#issuecomment-867736262 ----==_mimepart_60d4a61393abf_5ac6fc105120 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@dtaht

it's a BCM4359 with bcmdhd driver (amlogic fork).
FullMAC architecture doesn't let us use airtime fairness.
So we did some job to decrease buffering inside the driver, we turned off power_save, roaming, periodic scans, background scanning.
We also use a combination of fq_codel qdisc for wlan0 interface and BBR tcp congestion algo.

bcmdhd driver do some weird things. According to my limited understanding tx_glom and rx_glom work independently from kernel scatter-gather mechanism. So a bunch of tx frames would be splitted and aligned according to tx_glom bucket size every time we try to send something.
This chip uses single queue for tx and rx, so according to it's architecture there is no way to achieve low delay with medium and heavy traffic scenarios.
Nowadays many android devices use this driver without any optimizations. And it works awful with pfifofast qdisc which is default for android.
So much to improve...

P.S.
It looks like the default fq_codel interval (100ms) is not enough for mobile devices in some scenarios.
300ms ought to be enough for everybody.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

----==_mimepart_60d4a61393abf_5ac6fc105120--