On Tue, 2009-01-06 at 01:49 +0200, Nick Kossifidis wrote:
> 2009/1/5 Maxim Levitsky <maximlevit...@gmail.com>:
> > On Mon, 2009-01-05 at 10:39 -0500, Bob Copeland wrote:
> >> On Mon, Jan 5, 2009 at 4:23 AM, Maxim Levitsky <maximlevit...@gmail.com>
> >> wrote:
> >> > Yes, with your 4 patches applied.
> >> > It seems even worse now, as this happened twice already.
> >>
> >> Can you try with just patch #4 applied (continue in case of gain failure).
> >> I'd be interested to know how much/if the frequency of MAC lockup changes.
> > Will try
> >
> >>
> >> > Noise might degrade performance, but do you think it might cause all
> >> > packets to be missed?
> >>
> >> Maybe not all, but enough. If we can't tune the channel then the radio
> >> won't get the ACKs from the medium, consequently ack failures are sent
> >> to the rate control algorithm and a lower rate will be tried. Also note
> >> there's not a whole lot of difference between 802.11 B/G channels between
> >> 1 and 11. If your AP supports 802.11A, then you can do testing on a
> >> mostly quiet freq band.
> >>
> >
> > But I have looked at rate_stats.
> > There are 0 packets that are success for rates > 24
> > I can set rates above 18 via iwconfig, and it does seem to tell the
> > driver to use it, but yet nothing is ever sent via card then
> > Anyway, I'll do more careful testing here.
> >
> >
> >
>
> You can't go beyond 18Mbits due to bad PHY calibration, i'm working on
> it right now (it's related to txpower, problem is that you have a bad
> spectral mask on tx packets on high rates and they get corrupted).
> It's not a MAC issue.
Glad to hear that.
That what I meant btw, that this is related to phy (or radio as they
call it)
The chip that is on aspire one seems to be AR5007EG
which consist of AR5212 (mac) and AR2425 (phy,radio,analog part..)
Btw while reading the sources I find that it might be worth to put part
specific code in separate parts, it is hard to understand, and on top of
that there are many different versions for different chipsets, so what
do you think.
Btw, the hal although opensource contains so many 'magic numbers', it
hardly describes any registers there, and there is an intial register
dump that isn't documented at all.
So I would suggest (but this might be large work, to create a central
table for each chip and document all known registers there, like a
name/description for known regs, and 'working values'/different values
for different modes for unknown ones, maybe even create a wiki, so dumps
form different drivers might be put there.
It just that speed issues like I was worried are connected to wrong
setup of the phy, and with little documentation it is hard to to know
what to do
I with athereos released datasheets (only a wish that will never came
true I guess....)
Best regards, and thanks
Maxim Levitsky
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
