Hi,
Clearly, the MAC simulation in wmediumd is rather limited, basically the
code just munges everything together:
for (i = 0; i < frame->tx_rates_count && !is_acked; i++) {
rate_idx = frame->tx_rates[i].idx;
/* no more rates in MRR */
if (rate_idx < 0)
break;
error_prob = ctx->get_error_prob(ctx, snr, rate_idx,
frame->freq, frame->data_len,
station, deststa);
for (j = 0; j < frame->tx_rates[i].count; j++) {
send_time += difs + pkt_duration(frame->data_len,
index_to_rate(rate_idx, frame->freq));
retries++;
/* skip ack/backoff/retries for noack frames */
if (noack) {
is_acked = true;
break;
}
/* TODO TXOPs */
/* backoff */
if (j > 0) {
send_time += (cw * slot_time) / 2;
cw = (cw << 1) + 1;
if (cw > queue->cw_max)
cw = queue->cw_max;
}
send_time += ack_time_usec;
if (choice > error_prob) {
is_acked = true;
break;
}
if (!use_fixed_random_value(ctx))
choice = drand48();
}
}
if (is_acked) {
frame->tx_rates[i-1].count = j + 1;
for (; i < frame->tx_rates_count; i++) {
frame->tx_rates[i].idx = -1;
frame->tx_rates[i].count = -1;
}
frame->flags |= HWSIM_TX_STAT_ACK;
}
(I copy/pasted that from my version, may be slightly different than
current upstream due to a fix bugfixes. I also know the recent fixes
will touch this area. Anyway, that's not the point.)
Looking at this, one thing that immediately stands out is that the ACK
isn't actually transmitted in any way, so you cannot have a duplicate
transmission that's actually received and get the ACK back.
And the second thing, because of this, it's highly unsuitable for
actually integrating with some other MAC.
The way I see it, wmediumd serves a dual purpose in this code,
implementing both
1) the low-level MAC controller for hwsim, and
2) the actual medium simulation.
I wonder if this should be split, implementing a "real" MAC for hwsim,
and then sending also the ACKs "properly", perhaps implementing RTS/CTS
behaviour in the MAC, etc.?
Or perhaps then that's too much complexity and I should just teach ns3
the hwsim virtio interface?
johannes
On Mon, Mar 23, 2020 at 02:56:46PM +0100, Johannes Berg wrote:
> I wonder if this should be split, implementing a "real" MAC for hwsim,
> and then sending also the ACKs "properly", perhaps implementing RTS/CTS
> behaviour in the MAC, etc.?
The reason I did it this way was to go more for rough approximation rather
than fidelity to get whatever simplifications that allows. For example,
loop really only considers a single frame at a time (and all of its rateset)
rather than all the possible stations that could be sending at a given time
step. That is good enough for comparing rate controllers, and doing some
mesh testing with a few one-off hacks bolted on top, but nowhere near
complete.
That said, splitting them apart and having more realistic mac layer sounds
reasonable -- how do you anticipate it looking?
> Or perhaps then that's too much complexity and I should just teach ns3
> the hwsim virtio interface?
Up to you :)
--
Bob Copeland %% https://bobcopeland.com/
On Tue, 2020-03-24 at 10:53 -0400, Bob Copeland wrote:
> On Mon, Mar 23, 2020 at 02:56:46PM +0100, Johannes Berg wrote:
> > I wonder if this should be split, implementing a "real" MAC for hwsim,
> > and then sending also the ACKs "properly", perhaps implementing RTS/CTS
> > behaviour in the MAC, etc.?
>
> The reason I did it this way was to go more for rough approximation rather
> than fidelity to get whatever simplifications that allows. For example,
> loop really only considers a single frame at a time (and all of its rateset)
> rather than all the possible stations that could be sending at a given time
> step. That is good enough for comparing rate controllers, and doing some
> mesh testing with a few one-off hacks bolted on top, but nowhere near
> complete.
Right, sure. I don't really object to this - but I realized it really
doesn't fit my model when I tried to integrate our firmware into it :)
And then I was left wondering if I really should even try ...
> That said, splitting them apart and having more realistic mac layer sounds
> reasonable -- how do you anticipate it looking?
Well, it depends how deep we go, I guess? I mean, we could go all the
way down to the PHY layer, but then we're _really_ in ns3 territory and
it's probably not worth it... OTOH, to fully integrate the firmware, we
probably do need this eventually. But I'd rather not reinvent ns3 here,
obviously :)
I've been trying to come up with some kind of hybrid model, where
perhaps we simulate the bare minimum for hwsim, and provide some kind of
"mostly the transport" bits for integrating other things. Though I may
still decide that even that is overkill, and right now I don't even care
about the timing accuracy at all, I just want something to work first.
What I anticipate this looking like is kinda hard to say, and we'd need
significantly more API between hwsim and its MAC too, because even to
simulate the ACK accurately we'd need to know the basic/mandatory rate
bitmap - right now the code just does
int ack_time_usec = pkt_duration(14, index_to_rate(0, frame->freq)) +
sifs;
but this is incorrect ... so arguably we need that *anyway*?
I guess I'd start with actually subjecting the ACK to "channel
conditions", but I'd actually want to be able to hook into the TX/RX in
some way from the external MAC too ... I just don't think we need to
treat hwsim as an external MAC because that just complicates the whole
thing?
Well, honestly, I have no idea :)
> > Or perhaps then that's too much complexity and I should just teach ns3
> > the hwsim virtio interface?
>
> Up to you :)
:)
johannes
Hi,
Am 24.03.2020 um 22:26 schrieb Johannes Berg:
>
>> That said, splitting them apart and having more realistic mac layer sounds
>> reasonable -- how do you anticipate it looking?
> Well, it depends how deep we go, I guess? I mean, we could go all the
> way down to the PHY layer, but then we're _really_ in ns3 territory and
> it's probably not worth it... OTOH, to fully integrate the firmware, we
> probably do need this eventually. But I'd rather not reinvent ns3 here,
> obviously :)
I think it's not the phy but the lower MAC layer, which at least need to
be adapted to the hwsim interface. Although it has no extreme
computational effort, its not that easy to implement. Depending on your
envisioned setup this might already be done in your firmware. Thy phy
layer will bring much higher timing precision, when the right models are
applied, but will greatly impact the simulation speed.
>
> I've been trying to come up with some kind of hybrid model, where
> perhaps we simulate the bare minimum for hwsim, and provide some kind of
> "mostly the transport" bits for integrating other things. Though I may
> still decide that even that is overkill, and right now I don't even care
> about the timing accuracy at all, I just want something to work first.
>
> What I anticipate this looking like is kinda hard to say, and we'd need
> significantly more API between hwsim and its MAC too, because even to
> simulate the ACK accurately we'd need to know the basic/mandatory rate
> bitmap - right now the code just does
>
> int ack_time_usec = pkt_duration(14, index_to_rate(0, frame->freq)) +
> sifs;
>
> but this is incorrect ... so arguably we need that *anyway*?
Actually you are right. Currently, we apply this by a priori knowledge.
Maybe a silly Idea, but could we interleave the cfg80211/nl80211
protocol on the virtio channel to get the configuration information?
>
> I guess I'd start with actually subjecting the ACK to "channel
> conditions", but I'd actually want to be able to hook into the TX/RX in
> some way from the external MAC too ... I just don't think we need to
> treat hwsim as an external MAC because that just complicates the whole
> thing?
>
> Well, honestly, I have no idea :)
Mhh I don't really get what you mean by that. Why can't you hook into
RX/TX with a simulated ACK ?
>
>
>>> Or perhaps then that's too much complexity and I should just teach ns3
>>> the hwsim virtio interface?
>> Up to you :)
It should be definitely possible. But I'm asking my self how good that
interacts with your firmware simulation.
> :)
>
> johannes
>
>
kind regards
Benjamin
--
M.Sc. Benjamin Beichler
Universität Rostock, Fakultät für Informatik und Elektrotechnik
Institut für Angewandte Mikroelektronik und Datentechnik
University of Rostock, Department of CS and EE
Institute of Applied Microelectronics and CE
Richard-Wagner-Straße 31
18119 Rostock
Deutschland/Germany
phone: +49 (0) 381 498 - 7278
email: [email protected]
www: http://www.imd.uni-rostock.de/
> > Well, it depends how deep we go, I guess? I mean, we could go all the
> > way down to the PHY layer, but then we're _really_ in ns3 territory and
> > it's probably not worth it... OTOH, to fully integrate the firmware, we
> > probably do need this eventually. But I'd rather not reinvent ns3 here,
> > obviously :)
> I think it's not the phy but the lower MAC layer, which at least need to
> be adapted to the hwsim interface. Although it has no extreme
> computational effort, its not that easy to implement. Depending on your
> envisioned setup this might already be done in your firmware.
Yeah, I think so.
> Thy phy
> layer will bring much higher timing precision, when the right models are
> applied, but will greatly impact the simulation speed.
Right. No good for this, I think.
And anyway then we're looking at ns-3 I guess. Though I couldn't figure
out yesterday how we could possibly integrate all this simulation setup
into ns-3.
> > int ack_time_usec = pkt_duration(14, index_to_rate(0, frame->freq)) +
> > sifs;
> >
> > but this is incorrect ... so arguably we need that *anyway*?
>
> Actually you are right. Currently, we apply this by a priori knowledge.
> Maybe a silly Idea, but could we interleave the cfg80211/nl80211
> protocol on the virtio channel to get the configuration information?
It'd really have to be the *mac80211* protocol, which is based only on
function calls etc. so we have to build a messaging layer around it ...
which basically is mac80211-hwsim, right?
> > I guess I'd start with actually subjecting the ACK to "channel
> > conditions", but I'd actually want to be able to hook into the TX/RX in
> > some way from the external MAC too ... I just don't think we need to
> > treat hwsim as an external MAC because that just complicates the whole
> > thing?
> >
> > Well, honestly, I have no idea :)
>
> Mhh I don't really get what you mean by that. Why can't you hook into
> RX/TX with a simulated ACK ?
I guess I could, but then I have to worry about all kinds of MAC
capabilities? I mean, essentially I'd end up building a MAC for hwsim,
in some integrated fashion, which seems like it probably should've been
done in ns-3 already or such?
> > > > Or perhaps then that's too much complexity and I should just teach ns3
> > > > the hwsim virtio interface?
> > > Up to you :)
>
> It should be definitely possible. But I'm asking my self how good that
> interacts with your firmware simulation.
Well, ns-3 *is* layered, no? Arguably then I should be able to remove
the MAC layer and put in my own, hooking into the PHY layer signals? But
I quickly got lost in the documentation there, and it's not really what
I need right now anyway ...
johannes