Above log is with an iperf session running in the background. :-s
Will look further into this ..
Regards,
Koen
some cents from me. the chipset has a hw delay/latency which doubles and
quadroubles depending on the channel width. this special offset needs to
be considered for ack
timing calculation. especially at very short distances you will run into
a problem that if this calculation is wrong, the ack timing register
contains a lower value than the hw delay/latency.
this will result in a effective negative ack value. maybe its worth to
check if the values used for this latency offset are correct?
i found also a patch in my own code which i made many years ago (i
cannot remember why) but maybe it helps
@@ -1128,11 +1110,10 @@
slottime = ah->slottime;
}
+
/* As defined by IEEE 802.11-2007 17.3.8.6 */
slottime += 3 * ah->coverage_class;
acktimeout = slottime + sifstime + ack_offset;
+ eifs += (6 * ah->coverage_class);
ctstimeout = acktimeout;
/*
Sebastian
