Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

2009-12-26 Thread Lukáš Turek
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

Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

2009-12-23 Thread 海藻敬之
( 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

Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

2009-12-23 Thread 海藻敬之
<<< text/html; charset=UTF-16BE: Unrecognized >>> ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel

Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

2009-12-23 Thread Lukáš Turek
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

Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

2009-12-23 Thread 海藻敬之
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

Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

2009-12-23 Thread 海藻敬之
<<< text/html; charset=UTF-16BE: Unrecognized >>> ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel

Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

2009-12-22 Thread Lukáš Turek
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

Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

2009-12-21 Thread Bob Copeland
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

Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

2009-12-21 Thread 海藻敬之
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,

Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

2009-12-21 Thread 海藻敬之
<<< text/html; charset=UTF-16BE: Unrecognized >>> ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel

Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

2009-12-21 Thread Lukáš Turek
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

Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

2009-12-21 Thread Bob Copeland
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

Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

2009-12-21 Thread Lukáš Turek
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

Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

2009-12-21 Thread Lukáš Turek
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 (

Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

2009-12-21 Thread 海藻敬之
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

Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

2009-12-21 Thread 海藻敬之
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