> -----Original Message----- > From: owner-freebsd-current_at_freebsd.org > [mailto:owner-freebsd-current_at_freebsd.org] On Behalf Of Marcin Jessa > Sent: Friday, September 30, 2005 10:23 AM > To: dandee_at_volny.cz > Cc: dandee_at_hellteam.net; freebsd-current_at_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_at_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. > > > 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 = 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 = 0.419/0.704/1.726/0.378 ms borovice-F# ifconfig -v ath0 ath0: flags=8843<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=8843<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=0 ttl=64 time=0.522 ms 64 bytes from 192.168.20.1: icmp_seq=0 ttl=64 time=0.962 ms (DUP!) 64 bytes from 192.168.20.1: icmp_seq=0 ttl=64 time=2.796 ms (DUP!) 64 bytes from 192.168.20.1: icmp_seq=1 ttl=64 time=0.917 ms 64 bytes from 192.168.20.1: icmp_seq=2 ttl=64 time=0.427 ms 64 bytes from 192.168.20.1: icmp_seq=2 ttl=64 time=2.983 ms (DUP!) 64 bytes from 192.168.20.1: icmp_seq=3 ttl=64 time=4039.920 ms 64 bytes from 192.168.20.1: icmp_seq=4 ttl=64 time=3041.282 ms 64 bytes from 192.168.20.1: icmp_seq=5 ttl=64 time=2040.618 ms 64 bytes from 192.168.20.1: icmp_seq=5 ttl=64 time=2040.652 ms (DUP!) 64 bytes from 192.168.20.1: icmp_seq=6 ttl=64 time=1039.686 ms 64 bytes from 192.168.20.1: icmp_seq=6 ttl=64 time=1039.813 ms (DUP!) 64 bytes from 192.168.20.1: icmp_seq=7 ttl=64 time=41.596 ms 64 bytes from 192.168.20.1: icmp_seq=7 ttl=64 time=41.826 ms (DUP!) 64 bytes from 192.168.20.1: icmp_seq=8 ttl=64 time=0.528 ms 64 bytes from 192.168.20.1: icmp_seq=9 ttl=64 time=0.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 = 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 = 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´t 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=107 Ack=19918745 Win=65160 Len=0 TSV=41567820 TSER=41440578 [ACK] Seq=107 Ack=19920193 Win=65160 Len=0 TSV=41567821 TSER=41440580 [ACK] Seq=107 Ack=19921641 Win=65160 Len=0 TSV=41567836 TSER=41440585 [ACK] Seq=107 Ack=19923089 Win=65160 Len=0 TSV=41567837 TSER=41440594 TCP 50878 > 80 [ACK] Seq=107 Ack=19924537 Win=65160 Len=0 TSV=41567839 TSER=41440595 TCP 50878 > 80 [ACK] Seq=107 Ack=19925985 Win=65160 Len=0 TSV=41567839 TSER=41440595 TCP 50878 > 80 [ACK] Seq=107 Ack=19927433 Win=63712 Len=0 TSV=41567842 TSER=41440596 TCP 50878 > 80 [ACK] Seq=107 Ack=19928881 Win=62264 Len=0 TSV=41567842 TSER=41440599 TCP 50878 > 80 [FIN, ACK] Seq=107 Ack=19928881 Win=66608 Len=0 TSV=41567842 TSER=41440599 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´s 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_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe_at_freebsd.org" Any comments please about comparing infrastructure and adhoc´s 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 _____ avast! Antivirus <http://www.avast.com> : Odchozi zprava cista. Virova databaze (VPS): 0542-4, 20.10.2005 Testovano: 20.10.2005 14:07:06 avast! - copyright (c) 1988-2005 ALWIL Software.Received on Thu Oct 20 2005 - 10:08:34 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:45 UTC