Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <9e3f1db524321ac33a4aa79341e4e8165eb99189.camel@sipsolutions.net>
Subject: Re: poor beacon/scan reliability with mac80211_hwsim
From:   Johannes Berg <johannes@sipsolutions.net>
To:     James Prestwood <prestwoj@gmail.com>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Date:   Wed, 23 Mar 2022 21:13:50 +0100
In-Reply-To: <545f0fb3be911c4bed6a0dc81b0679a9824fe6c9.camel@gmail.com>
References: <928be46d97a3da3fd677c9d87f9be6a02f4d3277.camel@gmail.com>
         <a2c1706527d11312b504f8d445bcbba7738f9c8c.camel@sipsolutions.net>
         <545f0fb3be911c4bed6a0dc81b0679a9824fe6c9.camel@gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Wed, 2022-03-23 at 12:45 -0700, James Prestwood wrote:
> > Though I'm surprised the overhead and all is enough to make the jump
> > out
> > to userspace and back take 30+ milliseconds (which is the smallest
> > possible dwell time if you have hwsim hw-scan enabled, otherwise it's
> > slightly larger).
> 
> Yeah I'm surprised as well. I haven't _proven_ this is the case but its
> really all I can think of for why scan results are missing. 

Agree.

> I don't
> think hw-scan is being used, we don't set ATTR_USE_SCANCTX or
> ATTR_CHANNELS so I guess this is the best case scenario for dwell time,
> hmm.

Well in mac80211 it's HZ/33, which is about the same time.

> > Though if you can run tests under UML/time-travel that would get rid
> > of this problem ;-)
> 
> Yeah this has been in the back of my mind for a while since it could
> also speed stuff not having to wait for timeouts.

True.

> But with respect to this issue how could UML fix it? Pause time to
> allow the scheduler to catch up?

Well I should have said time-travel=inf-cpu, which is really the mode
I'd use for testing (and we have time-travel=ext of course for use with
multiple VMs).

In this case it simulates infinite CPU speed! Thus time only passes if
it passes *explicitly*. So a timeout of 30ms will only fire after
something else has slept 30ms, or nothing is actually doing anything at
all of course. The amount of time it takes the CPU to do the jump out to
userspace/wmediumd, come back, copy the frame, etc. is all completely
irrelevant in this case. It's just "sleep 30ms" and all the necessary
CPU expenditure is not accounted at all.

johannes