All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sven Eckelmann <sven@narfation.org>
To: linux-wireless@vger.kernel.org,
	Johannes Berg <johannes@sipsolutions.net>
Cc: Johannes Berg <johannes.berg@intel.com>,
	Jan Fuchs <jf@simonwunderlich.de>
Subject: Re: [PATCH] nl80211: fix radio statistics in survey dump
Date: Tue, 02 Nov 2021 12:12:28 +0100	[thread overview]
Message-ID: <2007334.cWPf2AUjKI@ripper> (raw)
In-Reply-To: <2494935.OLRZgKR7aK@ripper>

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

On Friday, 29 October 2021 10:46:43 CET Sven Eckelmann wrote:
> If you just read the mvm->radio_stats.on_time_rf (in usec) then you see following:
[...]
>         channel active time:            8560 us
>         channel active time:            4295006989 us
>         channel active time:            4295020943 us
>         channel active time:            4295051766 us
>         channel active time:            4295086037 us
>         channel active time:            4295119851 us
>         channel active time:            4295157051 us
>         channel active time:            4295193488 us
>         channel active time:            4295247769 us
>         channel active time:            4295302615 us
>         channel active time:            4295315627 us
>         channel active time:            4295352876 us
>         channel active time:            45385 us
>         channel active time:            121871 us
>         channel active time:            142972 us
>         channel active time:            262344 us
>         channel active time:            418666 us
> 
> So it also jumps all over the place. This could be investigated further but I 
> just wanted to mention it here.

Sorry, wanted to write more about it last week but forgot about it. If I
basically filter out the upper 32 bit in mvm->radio_stats.on_time_rf then it 
didn't look that bad on a AX210. It seems like the upper bits is sometimes 
0x00000001 for unknown reasons. Like it would be some kind of flag which 
should indicate some kind of change/event. So maybe the firmware team could 
check what this means.

It is not really urgent - I just got interested in the problem :)

Thanks,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-11-02 11:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-29  7:25 [PATCH] nl80211: fix radio statistics in survey dump Johannes Berg
2021-10-29  8:46 ` Sven Eckelmann
2021-11-02 11:12   ` Sven Eckelmann [this message]
2021-11-02 12:03     ` 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=2007334.cWPf2AUjKI@ripper \
    --to=sven@narfation.org \
    --cc=jf@simonwunderlich.de \
    --cc=johannes.berg@intel.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.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.