On Wed, 2018-10-17 at 13:05 +0300, Lior David wrote:
>
> On 10/11/2018 1:05 PM, Johannes Berg wrote:
> >
> > > Thanks for the explanation. The send to same socket does sound more
> > > efficient.
> > > (In our internal implementation with vendor commands we were forced
> > > to send the results
On 10/11/2018 1:05 PM, Johannes Berg wrote:
>
>> Thanks for the explanation. The send to same socket does sound more
>> efficient.
>> (In our internal implementation with vendor commands we were forced
>> to send the results as broadcast...)
>
> I suppose we can fix that, in the sense that
On Sun, 2018-10-07 at 21:58 +0200, Johannes Berg wrote:
>
> > > + * @partial: indicates that this is a partial result for this type
> >
> > Is partial set to false for the last result of this measurement type? This
> > may
> > be useful, for example if requesting multiple measurement types,
On Tue, 2018-10-09 at 17:40 +0300, Lior David wrote:
> Thanks for the explanation. The send to same socket does sound more efficient.
> (In our internal implementation with vendor commands we were forced
> to send the results as broadcast...)
I suppose we can fix that, in the sense that we can
On 10/7/2018 10:58 PM, Johannes Berg wrote:
>>
>> Just curious, what's the advantage of this compared to sending the reply
>> only on
>> the socket that started the measurement?
>
> TBH, I don't really see any. Some people really wanted this for things
> like "let's do something in iw for
Hi Lior,
Thanks for taking the time :-)
> > Results availability is multicast on a new "peer-measurement"
> > multicast group, and results can be retrieved by dumping the
> > data given the measurement cookie. Note that dumping it from
> > the netlink socket that started the measurement will
Hi Johannes,
On 10/1/2018 4:35 PM, Johannes Berg wrote:
> From: Johannes Berg
>
> Add a new "peer measurement" API, that can be used to measure
> certain things related to a peer. Right now, only implement
> FTM (flight time measurement) over it, but the idea is that
> it'll be extensible to
From: Johannes Berg
Add a new "peer measurement" API, that can be used to measure
certain things related to a peer. Right now, only implement
FTM (flight time measurement) over it, but the idea is that
it'll be extensible to also support measuring the necessary
things to calculate e.g.
