Date: Thu, 20 Oct 2005 14:08:26 +0200 From: =?iso-8859-2?Q?Daniel_Dvo=F8=E1k?= <dandee@hellteam.net> To: "'Marcin Jessa'" <lists@yazzy.org>, "'Sam Leffler'" <sam@errno.com>, "'Jiri Mikulas'" <konfer@mikulas.com>, "'Andrey Smagin'" <samspeedu@mail.ru>, "'Daniel Dvorak'" <dandee@hellteam.net> Cc: freebsd-current@freebsd.org Subject: RE: To compare hostap-client mode and adhoc's mode on Atheros cards. Message-ID: <000001c5d56e$fbe00a90$1148280a@tocnet28.jspoj.czf> In-Reply-To: <20050930102314.46be88f5.lists@yazzy.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: owner-freebsd-current@freebsd.org > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Marcin Jessa > Sent: Friday, September 30, 2005 10:23 AM > To: dandee@volny.cz > Cc: dandee@hellteam.net; freebsd-current@freebsd.org > Subject: Re: To compare hostap-client mode and adhoc's mode > on Atheros cards. > > On Fri, 30 Sep 2005 01:21:09 +0200 > Daniel Dvorak <dandee@hellteam.net> wrote: > > > > > Hello all, > > > > who use wireless stuff of FreeBSD and others. :) > > > > Have you tested and compared the infrastructure mode and the adhoc > > mode anybody ? > > > > We have 2 servers with 681 m distance. Wireless signal is about avg. > > RSSI 20-22 on both site. > > > > We use on one site hostap and on the second site client, of course. > > Rate is a sample rate. > > > > The maximum bandwidth is about 1,2 MB/s in one direction. > Strange, you should get about 2MB/s on such a short distance. I think that for the values of RSSI 20 and 18Mbps fixed it is what I = would expect, so 1,2 MB/s. Finally we find the time to test and answer to your post. >=20 > > Problem: > > > > If we switch cards to adhoc mode on both site the speed is 10 times > > slower. Nothing else has changed. > Do you bridge them with your wired nics or route when in adhoc mode? And is it relevant ? We only switched infrastructure mode to ad-hoc mode = on cards. But the answer is: We route packets in all cases. > How do you meassure the traffic? What is the size of the > packets you're sending. We use single or multiple threads of flood pings "ping -f -s 1472 -c = 10000 IP" and wget to download test file from apache. > What is the tcp windows size? Is it relevant for only switching infrastructure to adhoc ? I answer later. > What are the values of dev.ath.0.acktimeout ? It is the same on the both side. borovice-F# sysctl dev.ath.0.acktimeout dev.ath.0.acktimeout: 27 It was computed by athctrl.sh. > Is net.inet.tcp.sack.enable set to 1 ? Yes, it is on both side. > Is there any additional latency, eg. longer ping times on > the system? Yes, in adhoc mode there are. On hostap side in hostap mode: --- 192.168.20.1 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev =3D 0.436/1.366/5.288/1.396 ms On client side in client mode: --- 192.168.20.2 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev =3D 0.419/0.704/1.726/0.378 ms borovice-F# ifconfig -v ath0 ath0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::290:4bff:feca:3319%ath0 prefixlen 64 scopeid 0x3 inet 192.168.20.2 netmask 0xfffffffc broadcast 192.168.20.3 ether 00:90:4b:ca:33:19 media: IEEE 802.11 Wireless Ethernet OFDM/18Mbps mode 11a = <hostap> status: associated ssid HA2BH channel 140 (5700) bssid 00:90:4b:ca:33:19 authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF powersavesleep 100 txpowmax 54 txpower 60 rtsthreshold 2346 fragthreshold 2346 -pureg protmode CTS -wme ssid SHOW apbridge dtimperiod 1 bintval 100 habr# ifconfig -v ath0 ath0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::290:4bff:feca:3352%ath0 prefixlen 64 scopeid 0x3 inet 192.168.20.1 netmask 0xfffffffc broadcast 192.168.20.3 ether 00:90:4b:ca:33:52 media: IEEE 802.11 Wireless Ethernet OFDM/18Mbps mode 11a status: associated ssid HA2BH channel 140 (5700) bssid 00:90:4b:ca:33:19 authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF powersavesleep 100 txpowmax 54 txpower 60 rtsthreshold 2346 fragthreshold 2346 -pureg protmode CTS -wme roaming AUTO bintval = 100 ... switching to adhoc ... On side, where hostap mode was, now adhoc borovice-F# ping -c 10 192.168.20.1 PING 192.168.20.1 (192.168.20.1): 56 data bytes 64 bytes from 192.168.20.1: icmp_seq=3D0 ttl=3D64 time=3D0.522 ms 64 bytes from 192.168.20.1: icmp_seq=3D0 ttl=3D64 time=3D0.962 ms (DUP!) 64 bytes from 192.168.20.1: icmp_seq=3D0 ttl=3D64 time=3D2.796 ms (DUP!) 64 bytes from 192.168.20.1: icmp_seq=3D1 ttl=3D64 time=3D0.917 ms 64 bytes from 192.168.20.1: icmp_seq=3D2 ttl=3D64 time=3D0.427 ms 64 bytes from 192.168.20.1: icmp_seq=3D2 ttl=3D64 time=3D2.983 ms (DUP!) 64 bytes from 192.168.20.1: icmp_seq=3D3 ttl=3D64 time=3D4039.920 ms 64 bytes from 192.168.20.1: icmp_seq=3D4 ttl=3D64 time=3D3041.282 ms 64 bytes from 192.168.20.1: icmp_seq=3D5 ttl=3D64 time=3D2040.618 ms 64 bytes from 192.168.20.1: icmp_seq=3D5 ttl=3D64 time=3D2040.652 ms = (DUP!) 64 bytes from 192.168.20.1: icmp_seq=3D6 ttl=3D64 time=3D1039.686 ms 64 bytes from 192.168.20.1: icmp_seq=3D6 ttl=3D64 time=3D1039.813 ms = (DUP!) 64 bytes from 192.168.20.1: icmp_seq=3D7 ttl=3D64 time=3D41.596 ms 64 bytes from 192.168.20.1: icmp_seq=3D7 ttl=3D64 time=3D41.826 ms = (DUP!) 64 bytes from 192.168.20.1: icmp_seq=3D8 ttl=3D64 time=3D0.528 ms 64 bytes from 192.168.20.1: icmp_seq=3D9 ttl=3D64 time=3D0.923 ms --- 192.168.20.1 ping statistics --- 10 packets transmitted, 10 packets received, +6 duplicates, 0% packet = loss round-trip min/avg/max/stddev =3D 0.427/833.466/4039.920/1248.743 ms borovice-F# BUT, on the second side, where priviously client mode was, it is still = okay --- 192.168.20.1 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev =3D 0.059/0.076/0.147/0.025 ms The speed of downloading a file from hostap side to client site ( in = same way in adhoc modes) was about 650kB/s, after switching to adhoc speed is 340kB/s > Are you using 11a or g and what channels ? > It is 5 GHz band so 11a and 140 channel, We tested many others channel, = with no influence to speed, some were even worst. In time our testing, one time, we couldn=B4t to connect cards in adhoc = mode at all. Here is athstats for borovice-F borovice-F# athstats 123 hardware error interrupts 1 tx frames discarded prior to association 7 tx frames with no ack marked 1098 rx failed 'cuz of PHY err 1098 OFDM timing 29490 beacons transmitted 132 periodic calibrations 1 rfgain value change rssi of last ack: 21 2 switched default/rx antenna Antenna profile: [1] tx 3 rx 69 [2] tx 4 rx 347 habr# athstats 54 hardware error interrupts 48 beacon miss interrupts 4 mib overflow interrupts 122 tx management frames 512 tx frames discarded prior to association 59749 tx stopped 'cuz no xmit buffer 428 tx failed 'cuz too many retries 515520 long on-chip tx retries 3 tx frames with no ack marked 99578 rx failed 'cuz frame too short 131901 rx failed 'cuz of PHY err 131901 OFDM timing 66 beacons transmitted 868 periodic calibrations 3 rfgain value change rssi of last ack: 20 1 switched default/rx antenna Antenna profile: [1] tx 557098 rx 1410153 On borovice-F side, the dmesg log was full of this: ath0: hardware error; resetting ath0: hardware error; resetting ath0: hardware error; resetting ath0: hardware error; resetting ath0: hardware error; resetting ath0: hardware error; resetting ath0: hardware error; resetting ath0: hardware error; resetting On habr side, the dmesg log was the same: ath0: hardware error; resetting ath0: hardware error; resetting ath0: hardware error; resetting ath0: device timeout ath0: device timeout ath0: device timeout After modifing rc.conf to start ath cards in adhoc mode on boot, the = cards did not connect again. I manually changed back to infrastructure mode hostap borovice and = client habr. So it started to work again. > What is the tcp windows size? I could answer now, for wget donwloading, TCP WINDOW SIZE is that what = we can expect. TCP 50878 > 80 [ACK] Seq=3D107 Ack=3D19918745 Win=3D65160 Len=3D0 = TSV=3D41567820 TSER=3D41440578 [ACK] Seq=3D107 Ack=3D19920193 Win=3D65160 Len=3D0 TSV=3D41567821 = TSER=3D41440580 [ACK] Seq=3D107 Ack=3D19921641 Win=3D65160 Len=3D0 TSV=3D41567836 = TSER=3D41440585 [ACK] Seq=3D107 Ack=3D19923089 Win=3D65160 Len=3D0 TSV=3D41567837 = TSER=3D41440594 TCP 50878 > 80 [ACK] Seq=3D107 Ack=3D19924537 Win=3D65160 Len=3D0 = TSV=3D41567839 TSER=3D41440595 TCP 50878 > 80 [ACK] Seq=3D107 Ack=3D19925985 Win=3D65160 Len=3D0 = TSV=3D41567839 TSER=3D41440595 TCP 50878 > 80 [ACK] Seq=3D107 Ack=3D19927433 Win=3D63712 Len=3D0 = TSV=3D41567842 TSER=3D41440596 TCP 50878 > 80 [ACK] Seq=3D107 Ack=3D19928881 Win=3D62264 Len=3D0 = TSV=3D41567842 TSER=3D41440599 TCP 50878 > 80 [FIN, ACK] Seq=3D107 Ack=3D19928881 Win=3D66608 Len=3D0 = TSV=3D41567842 TSER=3D41440599 So we can say, it is not small packets. There are strange issues in adhoc modes. We have another system, where FreeBSD server acts as hostap and on the second side, there is linux server with madwifi driver (snapshot from = end of August) in client mode. We wanted to swith to adhoc=B4s mode too, but it = did not connect each other at all too. I think that this issues might be connected with this what we know from = Sam L. Sam L. wrote: ath_rate_sample is the only one to use. It's still got some issues = (John did some fixes that are in the Linux version that I haven't backported = yet) but outperfoms the others hands down. Sam > > Has anybody come accross with it in the past or nowadays ? > I can remember having any problems running on NetBSD with > both atheros nics in adhoc bridged with wired nics. It > crashed with small packets but the throughput was "normal" as > long as things were working. > > Cheers, > Marcin. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" Any comments please about comparing infrastructure and adhoc=B4s mode ? Last question for Sam L.: Is it possible to commit new version of hal ( how you wrote yesterday ) = to RELENG_6 or it will be only in CURRENT 7.0 ? Dan _____ =20 avast! Antivirus <http://www.avast.com> : Odchozi zprava cista.=20 Virova databaze (VPS): 0542-4, 20.10.2005 Testovano: 20.10.2005 14:07:06 avast! - copyright (c) 1988-2005 ALWIL Software.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000001c5d56e$fbe00a90$1148280a>