I just upgraded my system to Suse 11.1, and it installed the ath5k driver. I
started having trouble with network access, and found that the response time
to the wireless router in my house was lousy:
glenn@DepotRd:~> ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=1233 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1901 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=1550 ms
So I pulled the madwifi-0.9.4-1.src.rpm, and re-configured to use the ath_pci
driver. The results were much better:
glenn@DepotRd:~> ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.493 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.485 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.501 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.518 ms
The card I have is the Netgear WG311T, which reports with PCI ID
0x168c:0x0013, and in the log as "Atheros Communications Inc. Atheros AR5001X+
Wireless Network Adapter (rev 01)".
I'd be happy to try to help figure out why the response time is so bad with
the ath5k driver, but I'm completely new to this code set.
On Friday 16 January 2009 10:33:13 Bob Copeland wrote:
> On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt
>
> <[email protected]> wrote:
> > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> > ath5k_pci 0000:00:07.0: registered as 'phy0'
> > phy0: Selected rate control algorithm 'pid'
>
> Can you change the rate control algorithm to minstrel and retry?
I built a 2.6.28.1-9 kernel to get the minstrel code for ath5k. The
kernel for Suse 11.1 is 2.6.27.7-9. But that means that more could have
changed besides the rate control code.
It looks like minstrel and pid give about the same result, a bit worse that
the ath_pci driver right now. Performance seems to vary from day to day.
I'll experiment some more, and switch transmission channels. I'm not getting
the really poor performance with ath5k right now.
I haven't looked yet - is there a way to switch to 'pid' rate control without
rebuilding the kernel?
On Thu, Jan 22, 2009 at 03:04:35PM +0100, Johannes Berg wrote:
> On Thu, 2009-01-22 at 08:49 -0500, John W. Linville wrote:
> > On Thu, Jan 22, 2009 at 06:32:55AM +0200, Nick Kossifidis wrote:
> > > 2009/1/21 Stefanik G=E1bor <[email protected]>:
> > > >
> > > > I think EMBEDDED is for options that replace full-featured Linu=
x
> > > > components with dumbed-down, "low-profile" equivalents (like SL=
OB) -
> > > > PID vs. minstrel is more like SLAB vs. SLUB.
> > > >
> > > > G=E1bor
> > > >
> > >=20
> > > Minstrell performs very well even on embedded devices, i don't th=
ink
> > > it's that heavy compared to pid.
> >=20
> > I think his point was that people should be able to select multiple
> > algorithms without having to select EMBEDDED.
>=20
> The reason it was originally under EMBEDDED is that this allows you t=
o
> turn off _all_ algorithms, and that breaks, but might be desirable if
> you have a system where you know you're using iwlagn or ath9k only wh=
ich
> have their own algorithms.
I see. But currently it limits you to only one generic algorithm, the
one chosen as the default. I don't think that was really the intent?
John
--=20
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
2009/1/21 Stefanik G=C3=A1bor <[email protected]>:
>
> I think EMBEDDED is for options that replace full-featured Linux
> components with dumbed-down, "low-profile" equivalents (like SLOB) -
> PID vs. minstrel is more like SLAB vs. SLUB.
>
> G=C3=A1bor
>
Minstrell performs very well even on embedded devices, i don't think
it's that heavy compared to pid.
--=20
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Wed, Jan 21, 2009 at 07:22:14PM +0100, Stefanik G=E1bor wrote:
> On Wed, Jan 21, 2009 at 4:14 PM, John W. Linville
> <[email protected]> wrote:
> > On Tue, Jan 20, 2009 at 10:38:08PM -0500, Glenn Burkhardt wrote:
> >> On Friday 16 January 2009 10:33:13 Bob Copeland wrote:
> >> > On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt
> >> >
> >> > <[email protected]> wrote:
> >> > > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IR=
Q 18
> >> > > ath5k_pci 0000:00:07.0: registered as 'phy0'
> >> > > phy0: Selected rate control algorithm 'pid'
> >> >
> >> > Can you change the rate control algorithm to minstrel and retry?
> >>
> >> I built a 2.6.28.1-9 kernel to get the minstrel code for ath5k. T=
he
> >> kernel for Suse 11.1 is 2.6.27.7-9. But that means that more coul=
d have
> >> changed besides the rate control code.
> >>
> >> It looks like minstrel and pid give about the same result, a bit w=
orse that
> >> the ath_pci driver right now. Performance seems to vary from day =
to day.
> >> I'll experiment some more, and switch transmission channels. I'm =
not getting
> >> the really poor performance with ath5k right now.
> >>
> >> I haven't looked yet - is there a way to switch to 'pid' rate cont=
rol without
> >> rebuilding the kernel?
> >
> > If you configure your kernel to include multiple rate control
> > algorithms then you can use the 'ieee80211_default_rc_algo' module
> > option for mac80211. Of course, changing that only works if you
> > rmmod/insmod mac80211.
> >
> > John
>=20
> Judging from this, is it really a good idea to hide pid behind EMBEDD=
ED?
I've been wondering about that myself. I'm inclined to think no.
John
--=20
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Wed, Jan 21, 2009 at 4:14 PM, John W. Linville
<[email protected]> wrote:
> On Tue, Jan 20, 2009 at 10:38:08PM -0500, Glenn Burkhardt wrote:
>> On Friday 16 January 2009 10:33:13 Bob Copeland wrote:
>> > On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt
>> >
>> > <[email protected]> wrote:
>> > > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
>> > > ath5k_pci 0000:00:07.0: registered as 'phy0'
>> > > phy0: Selected rate control algorithm 'pid'
>> >
>> > Can you change the rate control algorithm to minstrel and retry?
>>
>> I built a 2.6.28.1-9 kernel to get the minstrel code for ath5k. The
>> kernel for Suse 11.1 is 2.6.27.7-9. But that means that more could have
>> changed besides the rate control code.
>>
>> It looks like minstrel and pid give about the same result, a bit worse that
>> the ath_pci driver right now. Performance seems to vary from day to day.
>> I'll experiment some more, and switch transmission channels. I'm not getting
>> the really poor performance with ath5k right now.
>>
>> I haven't looked yet - is there a way to switch to 'pid' rate control without
>> rebuilding the kernel?
>
> If you configure your kernel to include multiple rate control
> algorithms then you can use the 'ieee80211_default_rc_algo' module
> option for mac80211. Of course, changing that only works if you
> rmmod/insmod mac80211.
>
> John
Judging from this, is it really a good idea to hide pid behind EMBEDDED?
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
2009/1/14 Glenn Burkhardt <[email protected]>:
> I just upgraded my system to Suse 11.1, and it installed the ath5k driver. I
> started having trouble with network access, and found that the response time
> to the wireless router in my house was lousy:
>
> glenn@DepotRd:~> ping 192.168.2.1
> PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
> 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=1233 ms
> 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1901 ms
> 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=1550 ms
>
> So I pulled the madwifi-0.9.4-1.src.rpm, and re-configured to use the ath_pci
> driver. The results were much better:
>
> glenn@DepotRd:~> ping 192.168.2.1
> PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
> 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.493 ms
> 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.485 ms
> 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.501 ms
> 64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.518 ms
>
> The card I have is the Netgear WG311T, which reports with PCI ID
> 0x168c:0x0013, and in the log as "Atheros Communications Inc. Atheros AR5001X+
> Wireless Network Adapter (rev 01)".
>
> I'd be happy to try to help figure out why the response time is so bad with
> the ath5k driver, but I'm completely new to this code set.
Can you please post the dmesg output from when ath5k loads ?
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Thu, Jan 22, 2009 at 06:32:55AM +0200, Nick Kossifidis wrote:
> 2009/1/21 Stefanik G=E1bor <[email protected]>:
> >
> > I think EMBEDDED is for options that replace full-featured Linux
> > components with dumbed-down, "low-profile" equivalents (like SLOB) =
-
> > PID vs. minstrel is more like SLAB vs. SLUB.
> >
> > G=E1bor
> >
>=20
> Minstrell performs very well even on embedded devices, i don't think
> it's that heavy compared to pid.
I think his point was that people should be able to select multiple
algorithms without having to select EMBEDDED.
John
--=20
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Wed, Jan 21, 2009 at 08:33:01PM +0100, Stefanik G=E1bor wrote:
> On Wed, Jan 21, 2009 at 8:11 PM, John W. Linville
> <[email protected]> wrote:
> > On Wed, Jan 21, 2009 at 07:22:14PM +0100, Stefanik G=E1bor wrote:
> >> On Wed, Jan 21, 2009 at 4:14 PM, John W. Linville
> >> <[email protected]> wrote:
> >> > On Tue, Jan 20, 2009 at 10:38:08PM -0500, Glenn Burkhardt wrote:
> >> >> On Friday 16 January 2009 10:33:13 Bob Copeland wrote:
> >> >> > On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt
> >> >> >
> >> >> > <[email protected]> wrote:
> >> >> > > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) ->=
IRQ 18
> >> >> > > ath5k_pci 0000:00:07.0: registered as 'phy0'
> >> >> > > phy0: Selected rate control algorithm 'pid'
> >> >> >
> >> >> > Can you change the rate control algorithm to minstrel and ret=
ry?
> >> >>
> >> >> I built a 2.6.28.1-9 kernel to get the minstrel code for ath5k.=
The
> >> >> kernel for Suse 11.1 is 2.6.27.7-9. But that means that more c=
ould have
> >> >> changed besides the rate control code.
> >> >>
> >> >> It looks like minstrel and pid give about the same result, a bi=
t worse that
> >> >> the ath_pci driver right now. Performance seems to vary from d=
ay to day.
> >> >> I'll experiment some more, and switch transmission channels. I=
'm not getting
> >> >> the really poor performance with ath5k right now.
> >> >>
> >> >> I haven't looked yet - is there a way to switch to 'pid' rate c=
ontrol without
> >> >> rebuilding the kernel?
> >> >
> >> > If you configure your kernel to include multiple rate control
> >> > algorithms then you can use the 'ieee80211_default_rc_algo' modu=
le
> >> > option for mac80211. Of course, changing that only works if you
> >> > rmmod/insmod mac80211.
> >> >
> >> > John
> >>
> >> Judging from this, is it really a good idea to hide pid behind EMB=
EDDED?
> >
> > I've been wondering about that myself. I'm inclined to think no.
> >
> > John
>=20
> I think EMBEDDED is for options that replace full-featured Linux
> components with dumbed-down, "low-profile" equivalents (like SLOB) -
> PID vs. minstrel is more like SLAB vs. SLUB.
Patches welcome. Bonus points if you find a way to switch algorithms
without module unloading and/or to pick different algorithms for
different interfaces.
John
--=20
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Wednesday 14 January 2009 08:30:03 Nick Kossifidis wrote:
> 2009/1/14 Glenn Burkhardt <[email protected]>:
> > I just upgraded my system to Suse 11.1, and it installed the ath5k
> > driver. I started having trouble with network access, and found that the
> > response time to the wireless router in my house was lousy:
> >
> > glenn@DepotRd:~> ping 192.168.2.1
> > PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
> > 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=1233 ms
> > 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1901 ms
> > 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=1550 ms
> >
> > So I pulled the madwifi-0.9.4-1.src.rpm, and re-configured to use the
> > ath_pci driver. The results were much better:
> >
> > glenn@DepotRd:~> ping 192.168.2.1
> > PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
> > 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.493 ms
> > 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.485 ms
> > 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.501 ms
> > 64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.518 ms
> >
> > The card I have is the Netgear WG311T, which reports with PCI ID
> > 0x168c:0x0013, and in the log as "Atheros Communications Inc. Atheros
> > AR5001X+ Wireless Network Adapter (rev 01)".
> >
> > I'd be happy to try to help figure out why the response time is so bad
> > with the ath5k driver, but I'm completely new to this code set.
>
> Can you please post the dmesg output from when ath5k loads ?
With ath_pci driver:
glenn@DepotRd:~> ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.974 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.946 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.964 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=1.39 ms
64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=0.964 ms
64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=0.956 ms
64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=0.948 ms
64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=0.963 ms
64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=0.957 ms
64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=1.71 ms
64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=3.62 ms
64 bytes from 192.168.2.1: icmp_seq=12 ttl=64 time=0.958 ms
^C
--- 192.168.2.1 ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 11043ms
rtt min/avg/max/mdev = 0.946/1.279/3.624/0.744 ms
glenn@DepotRd:~> iwconfig
lo no wireless extensions.
wifi0 no wireless extensions.
ath0 IEEE 802.11g ESSID:"Belkin_N_Wireless_A99331"
Mode:Managed Frequency:2.437 GHz Access Point: 00:1C:DF:A9:93:31
Bit Rate:54 Mb/s Tx-Power:15 dBm Sensitivity=1/1
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality=25/70 Signal level=-70 dBm Noise level=-95 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
eth0 no wireless extensions.
Shortly thereafter, with ath5k loaded:
DepotRd:/home/gbb-suse # modprobe ath5k
DepotRd:/home/gbb-suse # /etc/init.d/network restart
Shutting down network interfaces:
eth0 device: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
(rev 10)
No configuration found for eth0
Nevertheless the interface will be shut down. done
wlan0 device: Atheros Communications Inc. Atheros AR5001X+ Wireless
Network Adapter (rev 01) done
Shutting down service network . . . . . . . . . done
Hint: you may set mandatory devices in /etc/sysconfig/network/config
Setting up network interfaces:
eth0 device: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
(rev 10)
No configuration found for eth0 unused
wlan0 device: Atheros Communications Inc. Atheros AR5001X+ Wireless
Network Adapter (rev 01)
wlan0 warning: WPA configured but may be unsupported
wlan0 warning: by this device
wlan0 starting wpa_supplicant
wlan0 Starting DHCP4 client. . . . . . . .
wlan0 DHCP4 continues in background waiting
Setting up service network . . . . . . . . . . done
DepotRd:/home/gbb-suse # ping 192.168.2.1
connect: Network is unreachable
DepotRd:/home/gbb-suse # ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:62 errors:0 dropped:0 overruns:0 frame:0
TX packets:62 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4028 (3.9 Kb) TX bytes:4028 (3.9 Kb)
wlan0 Link encap:Ethernet HWaddr 00:0F:B5:1D:93:2B
inet addr:192.168.2.3 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
wmaster0 Link encap:UNSPEC HWaddr 00-0F-
B5-1D-93-2B-00-00-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
DepotRd:/home/gbb-suse # ping 192.168.2.1
connect: Network is unreachable
DepotRd:/home/gbb-suse # ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
64 bytes from 192.168.2.1: icmp_seq=30 ttl=64 time=18.1 ms
64 bytes from 192.168.2.1: icmp_seq=31 ttl=64 time=4.25 ms
64 bytes from 192.168.2.1: icmp_seq=32 ttl=64 time=8.36 ms
ping: sendmsg: Network is unreachable
64 bytes from 192.168.2.1: icmp_seq=34 ttl=64 time=4.24 ms
64 bytes from 192.168.2.1: icmp_seq=35 ttl=64 time=10.1 ms
ping: sendmsg: Network is unreachable
64 bytes from 192.168.2.1: icmp_seq=37 ttl=64 time=6.25 ms
64 bytes from 192.168.2.1: icmp_seq=38 ttl=64 time=5.95 ms
ping: sendmsg: Network is unreachable
64 bytes from 192.168.2.1: icmp_seq=40 ttl=64 time=7.60 ms
64 bytes from 192.168.2.1: icmp_seq=41 ttl=64 time=5.36 ms
ping: sendmsg: Network is unreachable
64 bytes from 192.168.2.1: icmp_seq=43 ttl=64 time=7.49 ms
64 bytes from 192.168.2.1: icmp_seq=44 ttl=64 time=6.14 ms
64 bytes from 192.168.2.1: icmp_seq=45 ttl=64 time=1.06 ms
64 bytes from 192.168.2.1: icmp_seq=46 ttl=64 time=6.89 ms
64 bytes from 192.168.2.1: icmp_seq=47 ttl=64 time=6.74 ms
64 bytes from 192.168.2.1: icmp_seq=48 ttl=64 time=0.750 ms
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
wmaster0 Link encap:UNSPEC HWaddr 00-0F-
B5-1D-93-2B-00-00-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
DepotRd:/home/gbb-suse # ping 192.168.2.1
connect: Network is unreachable
DepotRd:/home/gbb-suse # ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
64 bytes from 192.168.2.1: icmp_seq=30 ttl=64 time=18.1 ms
64 bytes from 192.168.2.1: icmp_seq=31 ttl=64 time=4.25 ms
64 bytes from 192.168.2.1: icmp_seq=32 ttl=64 time=8.36 ms
ping: sendmsg: Network is unreachable
64 bytes from 192.168.2.1: icmp_seq=34 ttl=64 time=4.24 ms
64 bytes from 192.168.2.1: icmp_seq=35 ttl=64 time=10.1 ms
ping: sendmsg: Network is unreachable
64 bytes from 192.168.2.1: icmp_seq=37 ttl=64 time=6.25 ms
64 bytes from 192.168.2.1: icmp_seq=38 ttl=64 time=5.95 ms
ping: sendmsg: Network is unreachable
64 bytes from 192.168.2.1: icmp_seq=40 ttl=64 time=7.60 ms
64 bytes from 192.168.2.1: icmp_seq=41 ttl=64 time=5.36 ms
ping: sendmsg: Network is unreachable
64 bytes from 192.168.2.1: icmp_seq=43 ttl=64 time=7.49 ms
64 bytes from 192.168.2.1: icmp_seq=44 ttl=64 time=6.14 ms
64 bytes from 192.168.2.1: icmp_seq=45 ttl=64 time=1.06 ms
64 bytes from 192.168.2.1: icmp_seq=46 ttl=64 time=6.89 ms
64 bytes from 192.168.2.1: icmp_seq=47 ttl=64 time=6.74 ms
64 bytes from 192.168.2.1: icmp_seq=48 ttl=64 time=0.750 ms
64 bytes from 192.168.2.1: icmp_seq=49 ttl=64 time=6.25 ms
64 bytes from 192.168.2.1: icmp_seq=50 ttl=64 time=5.38 ms
64 bytes from 192.168.2.1: icmp_seq=51 ttl=64 time=0.734 ms
64 bytes from 192.168.2.1: icmp_seq=52 ttl=64 time=6.47 ms
ping: sendmsg: Network is unreachable
^C
--- 192.168.2.1 ping statistics ---
53 packets transmitted, 19 received, 64% packet loss, time 52164ms
rtt min/avg/max/mdev = 0.734/6.228/18.178/3.726 ms
DepotRd:/home/gbb-suse # emacs /var/log/messages &
[1] 2236
DepotRd:/home/gbb-suse # iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wmaster0 no wireless extensions.
wlan0 IEEE 802.11bg ESSID:"Belkin_N_Wireless_A99331"
Mode:Managed Frequency:2.437 GHz Access Point: 00:1C:DF:A9:93:31
Bit Rate=54 Mb/s Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2352 B
Encryption key:713A-E283-4CAA-0D17-911E-A88E-B3AC-8C88-E5B3-
AE6C-0923-FC80-5AF4-444F-08EB-4D2E [2] Security mode:open
Power Management:off
Link Quality=37/100 Signal level:-66 dBm Noise level=-90 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Output from dmesg:
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
agpgart-sis 0000:00:00.0: AGP 3.5 bridge
agpgart-sis 0000:00:00.0: putting AGP V3 device into 8x mode
nvidia 0000:01:00.0: putting AGP V3 device into 8x mode
NET: Registered protocol family 17
ath0: no IPv6 routers present
bootsplash: status on console 0 changed to on
ath_pci 0000:00:07.0: PCI INT A disabled
ath_pci: driver unloaded
ath_rate_sample: unloaded
wlan: driver unloaded
ath_hal: driver unloaded
ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ath5k_pci 0000:00:07.0: registered as 'phy0'
phy0: Selected rate control algorithm 'pid'
ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
ath5k phy0: RF2112A 2GHz radio found (0x46)
ADDRCONF(NETDEV_UP): wlan0: link is not ready
ADDRCONF(NETDEV_UP): wlan0: link is not ready
wlan0: authenticate with AP 00:1c:df:a9:93:31
wlan0: authenticated
wlan0: associate with AP 00:1c:df:a9:93:31
wlan0: RX AssocResp from 00:1c:df:a9:93:31 (capab=0x411 status=0 aid=1)
wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
padlock: VIA PadLock not detected.
wlan0: no IPv6 routers present
On Thu, 2009-01-22 at 08:49 -0500, John W. Linville wrote:
> On Thu, Jan 22, 2009 at 06:32:55AM +0200, Nick Kossifidis wrote:
> > 2009/1/21 Stefanik Gábor <[email protected]>:
> > >
> > > I think EMBEDDED is for options that replace full-featured Linux
> > > components with dumbed-down, "low-profile" equivalents (like SLOB) -
> > > PID vs. minstrel is more like SLAB vs. SLUB.
> > >
> > > Gábor
> > >
> >
> > Minstrell performs very well even on embedded devices, i don't think
> > it's that heavy compared to pid.
>
> I think his point was that people should be able to select multiple
> algorithms without having to select EMBEDDED.
The reason it was originally under EMBEDDED is that this allows you to
turn off _all_ algorithms, and that breaks, but might be desirable if
you have a system where you know you're using iwlagn or ath9k only which
have their own algorithms.
johannes
On Friday 16 January 2009 10:33:13 Bob Copeland wrote:
> On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt
>
> <[email protected]> wrote:
> > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> > ath5k_pci 0000:00:07.0: registered as 'phy0'
> > phy0: Selected rate control algorithm 'pid'
>
> Can you change the rate control algorithm to minstrel and retry?
I'll have to say that performance is worse with minstrel than pid rate
control. I used Channel 2 on the router, and:
ath_pci:
DepotRd:/home/gbb-suse/wireless # ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=5.82 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1.32 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.967 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.954 ms
64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=0.970 ms
64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=1.14 ms
64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=1.32 ms
64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=0.981 ms
64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=0.961 ms
64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=3.88 ms
64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=0.962 ms
64 bytes from 192.168.2.1: icmp_seq=12 ttl=64 time=0.894 ms
64 bytes from 192.168.2.1: icmp_seq=13 ttl=64 time=0.991 ms
64 bytes from 192.168.2.1: icmp_seq=14 ttl=64 time=0.968 ms
64 bytes from 192.168.2.1: icmp_seq=15 ttl=64 time=0.978 ms
64 bytes from 192.168.2.1: icmp_seq=16 ttl=64 time=1.10 ms
64 bytes from 192.168.2.1: icmp_seq=17 ttl=64 time=0.999 ms
64 bytes from 192.168.2.1: icmp_seq=18 ttl=64 time=0.998 ms
DepotRd:/home/gbb-suse/wireless # iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wifi0 no wireless extensions.
ath0 IEEE 802.11g ESSID:"Belkin_N_Wireless_A99331"
Mode:Managed Frequency:2.417 GHz Access Point: 00:1C:DF:A9:93:31
Bit Rate:36 Mb/s Tx-Power:15 dBm Sensitivity=1/1
Retry:off RTS thr:off Fragment thr:off
Encryption key:FA2D-087E-61EF-D860-2E7D-46C9-AF65-CA4C Security
mode:restricted
Power Management:off
Link Quality=37/70 Signal level=-59 dBm Noise level=-96 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
ath5k with pid:
DepotRd:/home/gbb-suse/linux-2.6.28.1 # ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=1729 ms
64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=2320 ms
64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=2050 ms
64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=1402 ms
64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=1323 ms
64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=1151 ms
64 bytes from 192.168.2.1: icmp_seq=13 ttl=64 time=608 ms
64 bytes from 192.168.2.1: icmp_seq=14 ttl=64 time=1134 ms
64 bytes from 192.168.2.1: icmp_seq=15 ttl=64 time=1100 ms
64 bytes from 192.168.2.1: icmp_seq=16 ttl=64 time=356 ms
64 bytes from 192.168.2.1: icmp_seq=17 ttl=64 time=164 ms
64 bytes from 192.168.2.1: icmp_seq=18 ttl=64 time=423 ms
ping: sendmsg: Network is unreachable
64 bytes from 192.168.2.1: icmp_seq=20 ttl=64 time=407 ms
ping: sendmsg: Network is unreachable
64 bytes from 192.168.2.1: icmp_seq=23 ttl=64 time=1086 ms
64 bytes from 192.168.2.1: icmp_seq=24 ttl=64 time=1442 ms
DepotRd:~ # iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wmaster0 no wireless extensions.
wlan0 IEEE 802.11bg ESSID:"Belkin_N_Wireless_A99331"
Mode:Managed Frequency:2.417 GHz Access Point: 00:1C:DF:A9:93:31
Bit Rate=54 Mb/s Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2352 B
Encryption key:E854-5075-1208-1225-D46B-46E6-CB2C-B627-DA3D-788E-
F50E-7351-DDE0-C111-E9A5-1FB7 [2] Security mode:open
Power Management:off
Link Quality=53/100 Signal level:-69 dBm Noise level=-103 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
ath5k with minstrel
dmesg | egrep 'ath|phy'
BIOS-provided physical RAM map:
Setting physnode_map array to node 0 for pfns:
ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ath5k_pci 0000:00:07.0: registered as 'phy0'
phy0: Selected rate control algorithm 'minstrel'
ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
ath5k phy0: RF2112B 2GHz radio found (0x46)
DepotRd:# ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=13159 ms
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=40968 ms
64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=42986 ms
ping: sendmsg: Network is unreachable
64 bytes from 192.168.2.1: icmp_seq=15 ttl=64 time=41983 ms
ping: sendmsg: Network is unreachable
64 bytes from 192.168.2.1: icmp_seq=16 ttl=64 time=42860 ms
DepotRd:~ # iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wmaster0 no wireless extensions.
wlan0 IEEE 802.11bg ESSID:"Belkin_N_Wireless_A99331"
Mode:Managed Frequency:2.417 GHz Access Point: 00:1C:DF:A9:93:31
Bit Rate=54 Mb/s Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2352 B
Encryption key:1193-9C46-9CB0-B2EE-99CA-EA37-7EB4-1B62-9475-B834-
AE70-AA4F-B4A5-B303-3D51-4244 [2] Security mode:open
Power Management:off
Link Quality=56/100 Signal level:-67 dBm Noise level=-103 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt
<[email protected]> wrote:
> ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> ath5k_pci 0000:00:07.0: registered as 'phy0'
> phy0: Selected rate control algorithm 'pid'
Can you change the rate control algorithm to minstrel and retry?
--
Bob Copeland %% http://www.bobcopeland.com
On Thu, Jan 22, 2009 at 03:45:58PM +0100, Stefanik G=E1bor wrote:
> On Thu, Jan 22, 2009 at 3:17 PM, John W. Linville
> <[email protected]> wrote:
> > On Thu, Jan 22, 2009 at 03:04:35PM +0100, Johannes Berg wrote:
> >> The reason it was originally under EMBEDDED is that this allows yo=
u to
> >> turn off _all_ algorithms, and that breaks, but might be desirable=
if
> >> you have a system where you know you're using iwlagn or ath9k only=
which
> >> have their own algorithms.
> >
> > I see. But currently it limits you to only one generic algorithm, =
the
> > one chosen as the default. I don't think that was really the inten=
t?
> >
>=20
> I think RC_NONE should depend on embedded, but not the chooser itself=
=2E
That makes sense to me.
John
--=20
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Thu, Jan 22, 2009 at 3:17 PM, John W. Linville
<[email protected]> wrote:
> On Thu, Jan 22, 2009 at 03:04:35PM +0100, Johannes Berg wrote:
>> On Thu, 2009-01-22 at 08:49 -0500, John W. Linville wrote:
>> > On Thu, Jan 22, 2009 at 06:32:55AM +0200, Nick Kossifidis wrote:
>> > > 2009/1/21 Stefanik G=E1bor <[email protected]>:
>> > > >
>> > > > I think EMBEDDED is for options that replace full-featured Lin=
ux
>> > > > components with dumbed-down, "low-profile" equivalents (like S=
LOB) -
>> > > > PID vs. minstrel is more like SLAB vs. SLUB.
>> > > >
>> > > > G=E1bor
>> > > >
>> > >
>> > > Minstrell performs very well even on embedded devices, i don't t=
hink
>> > > it's that heavy compared to pid.
>> >
>> > I think his point was that people should be able to select multipl=
e
>> > algorithms without having to select EMBEDDED.
>>
>> The reason it was originally under EMBEDDED is that this allows you =
to
>> turn off _all_ algorithms, and that breaks, but might be desirable i=
f
>> you have a system where you know you're using iwlagn or ath9k only w=
hich
>> have their own algorithms.
>
> I see. But currently it limits you to only one generic algorithm, th=
e
> one chosen as the default. I don't think that was really the intent?
>
I think RC_NONE should depend on embedded, but not the chooser itself.
--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
2009/1/22 Glenn Burkhardt <[email protected]>:
> On Friday 16 January 2009 10:33:13 Bob Copeland wrote:
>> On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt
>>
>> <[email protected]> wrote:
>> > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
>> > ath5k_pci 0000:00:07.0: registered as 'phy0'
>> > phy0: Selected rate control algorithm 'pid'
>>
>> Can you change the rate control algorithm to minstrel and retry?
>
> I'll have to say that performance is worse with minstrel than pid rate
> control. I used Channel 2 on the router, and:
>
> ath_pci:
> DepotRd:/home/gbb-suse/wireless # ping 192.168.2.1
> PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
> 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=5.82 ms
> 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1.32 ms
> 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.967 ms
> 64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.954 ms
> 64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=0.970 ms
> 64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=1.14 ms
> 64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=1.32 ms
> 64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=0.981 ms
> 64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=0.961 ms
> 64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=3.88 ms
> 64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=0.962 ms
> 64 bytes from 192.168.2.1: icmp_seq=12 ttl=64 time=0.894 ms
> 64 bytes from 192.168.2.1: icmp_seq=13 ttl=64 time=0.991 ms
> 64 bytes from 192.168.2.1: icmp_seq=14 ttl=64 time=0.968 ms
> 64 bytes from 192.168.2.1: icmp_seq=15 ttl=64 time=0.978 ms
> 64 bytes from 192.168.2.1: icmp_seq=16 ttl=64 time=1.10 ms
> 64 bytes from 192.168.2.1: icmp_seq=17 ttl=64 time=0.999 ms
> 64 bytes from 192.168.2.1: icmp_seq=18 ttl=64 time=0.998 ms
> DepotRd:/home/gbb-suse/wireless # iwconfig
> lo no wireless extensions.
>
> eth0 no wireless extensions.
>
> wifi0 no wireless extensions.
>
> ath0 IEEE 802.11g ESSID:"Belkin_N_Wireless_A99331"
> Mode:Managed Frequency:2.417 GHz Access Point: 00:1C:DF:A9:93:31
> Bit Rate:36 Mb/s Tx-Power:15 dBm Sensitivity=1/1
> Retry:off RTS thr:off Fragment thr:off
> Encryption key:FA2D-087E-61EF-D860-2E7D-46C9-AF65-CA4C Security
> mode:restricted
> Power Management:off
> Link Quality=37/70 Signal level=-59 dBm Noise level=-96 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
>
> ath5k with pid:
>
> DepotRd:/home/gbb-suse/linux-2.6.28.1 # ping 192.168.2.1
> PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
> 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=1729 ms
> 64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=2320 ms
> 64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=2050 ms
> 64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=1402 ms
> 64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=1323 ms
> 64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=1151 ms
> 64 bytes from 192.168.2.1: icmp_seq=13 ttl=64 time=608 ms
> 64 bytes from 192.168.2.1: icmp_seq=14 ttl=64 time=1134 ms
> 64 bytes from 192.168.2.1: icmp_seq=15 ttl=64 time=1100 ms
> 64 bytes from 192.168.2.1: icmp_seq=16 ttl=64 time=356 ms
> 64 bytes from 192.168.2.1: icmp_seq=17 ttl=64 time=164 ms
> 64 bytes from 192.168.2.1: icmp_seq=18 ttl=64 time=423 ms
> ping: sendmsg: Network is unreachable
> 64 bytes from 192.168.2.1: icmp_seq=20 ttl=64 time=407 ms
> ping: sendmsg: Network is unreachable
> 64 bytes from 192.168.2.1: icmp_seq=23 ttl=64 time=1086 ms
> 64 bytes from 192.168.2.1: icmp_seq=24 ttl=64 time=1442 ms
> DepotRd:~ # iwconfig
> lo no wireless extensions.
>
> eth0 no wireless extensions.
>
> wmaster0 no wireless extensions.
>
> wlan0 IEEE 802.11bg ESSID:"Belkin_N_Wireless_A99331"
> Mode:Managed Frequency:2.417 GHz Access Point: 00:1C:DF:A9:93:31
> Bit Rate=54 Mb/s Tx-Power=27 dBm
> Retry min limit:7 RTS thr:off Fragment thr=2352 B
> Encryption key:E854-5075-1208-1225-D46B-46E6-CB2C-B627-DA3D-788E-
> F50E-7351-DDE0-C111-E9A5-1FB7 [2] Security mode:open
> Power Management:off
> Link Quality=53/100 Signal level:-69 dBm Noise level=-103 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
>
>
> ath5k with minstrel
>
> dmesg | egrep 'ath|phy'
> BIOS-provided physical RAM map:
> Setting physnode_map array to node 0 for pfns:
> ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> ath5k_pci 0000:00:07.0: registered as 'phy0'
> phy0: Selected rate control algorithm 'minstrel'
> ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
> ath5k phy0: RF2112B 2GHz radio found (0x46)
>
> DepotRd:# ping 192.168.2.1
> PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
> ping: sendmsg: Network is unreachable
> ping: sendmsg: Network is unreachable
> ping: sendmsg: Network is unreachable
> 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=13159 ms
> ping: sendmsg: Network is unreachable
> ping: sendmsg: Network is unreachable
> ping: sendmsg: Network is unreachable
> ping: sendmsg: Network is unreachable
> ping: sendmsg: Network is unreachable
> 64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=40968 ms
> 64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=42986 ms
> ping: sendmsg: Network is unreachable
> 64 bytes from 192.168.2.1: icmp_seq=15 ttl=64 time=41983 ms
> ping: sendmsg: Network is unreachable
> 64 bytes from 192.168.2.1: icmp_seq=16 ttl=64 time=42860 ms
> DepotRd:~ # iwconfig
> lo no wireless extensions.
>
> eth0 no wireless extensions.
>
> wmaster0 no wireless extensions.
>
> wlan0 IEEE 802.11bg ESSID:"Belkin_N_Wireless_A99331"
> Mode:Managed Frequency:2.417 GHz Access Point: 00:1C:DF:A9:93:31
> Bit Rate=54 Mb/s Tx-Power=27 dBm
> Retry min limit:7 RTS thr:off Fragment thr=2352 B
> Encryption key:1193-9C46-9CB0-B2EE-99CA-EA37-7EB4-1B62-9475-B834-
> AE70-AA4F-B4A5-B303-3D51-4244 [2] Security mode:open
> Power Management:off
> Link Quality=56/100 Signal level:-67 dBm Noise level=-103 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
>
O.K. so both algorithms have overestimated the rate, madwifi with
minstrel sets it to 36M and both pid an minstrel on ath5k/mac80211 set
it to 54M. This results packet corruption and packet loss. Please try
locking the rate to 18M - 36M and check the performance again (also an
iperf udp test would be very usefull) to see if this is only a problem
with the algorithm or a more generic problem.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Wed, Jan 21, 2009 at 8:11 PM, John W. Linville
<[email protected]> wrote:
> On Wed, Jan 21, 2009 at 07:22:14PM +0100, Stefanik G=E1bor wrote:
>> On Wed, Jan 21, 2009 at 4:14 PM, John W. Linville
>> <[email protected]> wrote:
>> > On Tue, Jan 20, 2009 at 10:38:08PM -0500, Glenn Burkhardt wrote:
>> >> On Friday 16 January 2009 10:33:13 Bob Copeland wrote:
>> >> > On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt
>> >> >
>> >> > <[email protected]> wrote:
>> >> > > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> I=
RQ 18
>> >> > > ath5k_pci 0000:00:07.0: registered as 'phy0'
>> >> > > phy0: Selected rate control algorithm 'pid'
>> >> >
>> >> > Can you change the rate control algorithm to minstrel and retry=
?
>> >>
>> >> I built a 2.6.28.1-9 kernel to get the minstrel code for ath5k. =
The
>> >> kernel for Suse 11.1 is 2.6.27.7-9. But that means that more cou=
ld have
>> >> changed besides the rate control code.
>> >>
>> >> It looks like minstrel and pid give about the same result, a bit =
worse that
>> >> the ath_pci driver right now. Performance seems to vary from day=
to day.
>> >> I'll experiment some more, and switch transmission channels. I'm=
not getting
>> >> the really poor performance with ath5k right now.
>> >>
>> >> I haven't looked yet - is there a way to switch to 'pid' rate con=
trol without
>> >> rebuilding the kernel?
>> >
>> > If you configure your kernel to include multiple rate control
>> > algorithms then you can use the 'ieee80211_default_rc_algo' module
>> > option for mac80211. Of course, changing that only works if you
>> > rmmod/insmod mac80211.
>> >
>> > John
>>
>> Judging from this, is it really a good idea to hide pid behind EMBED=
DED?
>
> I've been wondering about that myself. I'm inclined to think no.
>
> John
I think EMBEDDED is for options that replace full-featured Linux
components with dumbed-down, "low-profile" equivalents (like SLOB) -
PID vs. minstrel is more like SLAB vs. SLUB.
G=E1bor
--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Tue, Jan 20, 2009 at 10:38:08PM -0500, Glenn Burkhardt wrote:
> On Friday 16 January 2009 10:33:13 Bob Copeland wrote:
> > On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt
> >
> > <[email protected]> wrote:
> > > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> > > ath5k_pci 0000:00:07.0: registered as 'phy0'
> > > phy0: Selected rate control algorithm 'pid'
> >
> > Can you change the rate control algorithm to minstrel and retry?
>
> I built a 2.6.28.1-9 kernel to get the minstrel code for ath5k. The
> kernel for Suse 11.1 is 2.6.27.7-9. But that means that more could have
> changed besides the rate control code.
>
> It looks like minstrel and pid give about the same result, a bit worse that
> the ath_pci driver right now. Performance seems to vary from day to day.
> I'll experiment some more, and switch transmission channels. I'm not getting
> the really poor performance with ath5k right now.
>
> I haven't looked yet - is there a way to switch to 'pid' rate control without
> rebuilding the kernel?
If you configure your kernel to include multiple rate control
algorithms then you can use the 'ieee80211_default_rc_algo' module
option for mac80211. Of course, changing that only works if you
rmmod/insmod mac80211.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
> O.K. so both algorithms have overestimated the rate, madwifi with
> minstrel sets it to 36M and both pid an minstrel on ath5k/mac80211 set
> it to 54M. This results packet corruption and packet loss. Please try
> locking the rate to 18M - 36M and check the performance again (also an
> iperf udp test would be very usefull) to see if this is only a problem
> with the algorithm or a more generic problem.
It doesn't seem to be the rate selection. I switched to channel 2 again, and
the version of ath5k that came with Suse 11.1 didn't connect to my router at
all. The ath_pci driver I built did, with roughly millisecond ping round
trips. The ath_pci driver changed the bit rate to 18 Mb/s; ath5k reported
using 5.5 Mb/s, but ping was never successful.
I also built a kernel from the wireless testing repository ( 2.6.29-rc3-wl-9-
pae), and that driver was able to connect initially, although with a slow
response rate:
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=3086 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=2925 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=3293 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=3986 ms
64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=4018 ms
64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=3030 ms
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
It reported the bit rate to be 54 Mb/s; I tried turning it down to as low as 6
Mb/s, but then it didn't work at all.
This last test was using 'minstrel' rate control; it doesn't seem that 'pid'
is a selectable option in the kernel configuration for 'wireless testing'.
I'll try to get some more data with 'iperf'. I have a couple of other
machines in the house that I can use.