On 24.12.2009 01:35 海藻敬之 wrote:
> ( sorry again for my last post which was corrupted. I do not why... some
> coding issue.. please be patient. )
For some reason your client tries to send the mail in UTF-16 instead of UTF-8,
so mailserver cuts the mail at the zero byte in the first character of
me
( sorry again for my last post which was corrupted. I do not why... some
coding issue.. please be patient. )
Lukas
thanks.
>> 2. still not good and unstable throughput for 2.4Ghz
>> thanks to your patch[3/5], [4/5], throughput was improved pretty much
>> but still staying around 10~15Mbps(1hop), 1
<<< text/html; charset=UTF-16BE: Unrecognized >>>
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
On 23.12.2009 12:43 海藻敬之 wrote:
> 2. still not good and unstable throughput for 2.4Ghz
> thanks to your patch[3/5], [4/5], throughput was improved pretty much
> but still staying around 10~15Mbps(1hop), 1Mbps~6Mbps(2hops)
That's strange, those patches can't change anything... They modify a code tha
Thanks, Lukas
> According to my interpretation the calculation should depend
> on channel width (20MHz in normal mode, 40MHz in turbo mode, same for 802.11g
> and 802.11a), not on MAC chip clocks.
thanks, then my guess was irrelevant...
I got some improvement (even not so significant), but I mig
<<< text/html; charset=UTF-16BE: Unrecognized >>>
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
On 22.12.2009 02:24 海藻敬之 wrote:
> Does original Atheros HAL calls the function just for 5GHz
> or calls for both 2GHz and 5 GHz.?
For both, too, the condition used is IS_CHAN_OFDM(chan).
> --- reset.c_org 2009-12-17 17:01:29.0 +0900
> +++ reset.c 2009-12-22 09:51:16.0 +0900
> @@ -6
On Mon, Dec 21, 2009 at 04:28:35PM +0100, Luk Turek wrote:
> On 21.12.2009 16:08 Bob Copeland wrote:
> If performance mattered, we could store the mode index somwhere. But it
> doesn't, the conversion is only needed when setting ACK timeout and slot
> time - which is, for most users, never do
Hi, Lukas and Bob
my last post looks blank and corrupted, sorry for the junk mail..
Below shows my local patch.
Does original Atheros HAL calls the function just for 5GHz
or calls for both 2GHz and 5 GHz.?
In ath5k, ath5k_hw_write_ofdm_timings() is called when
AR_5212 and CHANNEL_OFDM are true,
<<< text/html; charset=UTF-16BE: Unrecognized >>>
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
On 21.12.2009 16:08 Bob Copeland wrote:
> I reviewed the patch, looks fine to me. The ATH hal uses a lookup
> table to keep it inline but I don't think we have a convenient
> index available to do the same.
Yes, HAL uses a lookup table for mode -> clocks coversion, but before that can
be used it
2009/12/21 Lukáš Turek <8...@praha12.net>:
> On 21.12.2009 11:41 海藻敬之 wrote:
>> In ath5k_hw_write_ofdm_timings(), comment says
>> "ALGO: coef = (5 * clock * carrier_freq) / 2) ",
>> but current code is
>> "coef_scaled = ((5 * (clock << 24)) / 2) / channel->center_freq;"
>>
>> Did th
On 21.12.2009 11:41 海藻敬之 wrote:
> In ath5k_hw_write_ofdm_timings(), comment says
> "ALGO: coef = (5 * clock * carrier_freq) / 2) ",
> but current code is
> "coef_scaled = ((5 * (clock << 24)) / 2) / channel->center_freq;"
>
> Did they match each other ?
> I am wondering the the com
On 21.12.2009 11:26 海藻敬之 wrote:
> Didn't we have to handle CHANNEL_2GHZ case in
> ath5k_hw_write_ofdm_timings() shown below ?
The ath5k gives exactly the same results as original Atheros HAL:
#define INIT_CLOCKMHZSCALED 0x6400
unsigned long clockMhzScaled = INIT_CLOCKMHZSCALED;
if (
Hi,
Let me confirm another point.
In ath5k_hw_write_ofdm_timings(), comment says
"ALGO: coef = (5 * clock * carrier_freq) / 2) ",
but current code is
"coef_scaled = ((5 * (clock << 24)) / 2) / channel->center_freq;"
Did they match each other ?
I am wondering the the comment is wron
Hi Lukas
Didn't we have to handle CHANNEL_2GHZ case in
ath5k_hw_write_ofdm_timings() shown below ?
I think we should do. then I made my own patch to hadle it and it
seemed to improve the throughput of 2.4GHz. (even still not as good as
5Ghz case )
> diff --git a/drivers/net/wireless/ath/ath
The original code was correct in 802.11a mode only, 802.11b/g uses
different clock rates. The new code uses values taken from FreeBSD HAL
and should be correct for all modes including turbo modes.
The former rate calculation was used by slope coefficient calculation
function ath5k_hw_write_ofdm_ti
17 matches
Mail list logo