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: <260e581ad38850276177bb4dde011de251cff1d5.camel@gmail.com>
Subject: Re: poor beacon/scan reliability with mac80211_hwsim
From:   James Prestwood <prestwoj@gmail.com>
To:     Johannes Berg <johannes@sipsolutions.net>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Date:   Wed, 23 Mar 2022 14:02:58 -0700
In-Reply-To: <9e3f1db524321ac33a4aa79341e4e8165eb99189.camel@sipsolutions.net>
References: <928be46d97a3da3fd677c9d87f9be6a02f4d3277.camel@gmail.com>
         <a2c1706527d11312b504f8d445bcbba7738f9c8c.camel@sipsolutions.net>
         <545f0fb3be911c4bed6a0dc81b0679a9824fe6c9.camel@gmail.com>
         <9e3f1db524321ac33a4aa79341e4e8165eb99189.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.4 (3.40.4-3.fc34) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

> 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.

Sounds magical :) I'll have to look into this again. 

> 
> johannes