Re: high latency due to distant clients
Hi, I think I fixed this in -HEAD. -adrian On 18 July 2013 08:52, Petar Bogdanovic pe...@smokva.net wrote: Hi, for several years now, I've been running an ALIX-AP with a CM9 Atheros 5212 card. The AP covers a whole house which has about 6 flats and the average amount of active clients ranges from 10 to 15. Recently I noticed high latency when pinging the AP itself which happens when distant clients (who knows where around the house---could be inside or outside) seem to cause longs (long on-chip tx retries) and/or xretries (tx failed 'cuz too many retries). The Rate, when talking to these distant clients, is usually below 11M (sometimes as low as 1M) which is consistent with their low RSSI values the AP is reporting. With high latency I mean continuous bursts of 500-1000ms instead of 0.5ms so I wonder if this is normal. The software is slightly out of date and athstats is not completely in sync with the kernel i'm using (therefore its not reporting some values): # uname -a FreeBSD parrot.NGC004 8.1-RC2 FreeBSD 8.1-RC2 #2: Thu Aug 16 21:13:54 CEST 2012 # athstats -i ath0 athstats: ath0: Invalid argument athstats: ath0: Invalid argument 3181606 data frames transmit 45659tx frames with an alternate rate 568149 long on-chip tx retries 19091tx failed 'cuz too many retries 0M current transmit rate 25 tx stopped 'cuz no xmit buffer 20922tx frames with no ack marked 3039151 tx frames with short preamble 362335 rx failed 'cuz of bad CRC 1181 rx failed 'cuz of PHY err 315 OFDM restart 866 CCK restart 2TDMA slot timing updates -0/+0TDMA slot adjust (usecs, smoothed) 26135TDMA tx failed 'cuz ACK required -74 rx noise floor 3070927 tx frames through raw api 6299685 fast frames received 1328215 fast frames flushed from staging q 20835ANI decrease noise immunity 6593 ANI increased spur immunity 121582 ANI decrease spur immunity 160 ANI decreased first step level 2cumulative OFDM phy error count 2RTS without CTS 1360093 beacons received Antenna profile: Any ideas on how to avoid that? Of course I could buy better antennas but it seems that, generally speaking, this shouldn't happen. Thanks, Petar Bogdanovic ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: high latency due to distant clients
On Thu, Jul 18, 2013 at 08:59:29AM -0700, Adrian Chadd wrote: I think I fixed this in -HEAD. Uh-oh, great! Will that change reach a stable release anytime soon? And--out of naive curiosity--what was the problem? Thanks, Petar Bogdanovic ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: high latency due to distant clients
On 18 July 2013 09:04, Petar Bogdanovic pe...@smokva.net wrote: On Thu, Jul 18, 2013 at 08:59:29AM -0700, Adrian Chadd wrote: I think I fixed this in -HEAD. Uh-oh, great! Will that change reach a stable release anytime soon? When 10.0 is stable, yup. :) And--out of naive curiosity--what was the problem? The ath driver before 11n support went in would just fill the hardware TX queue with frames. There's no per-station queue or any kind of fair queuing. So if you fill the TX queue in the driver with frames to a far away station, it'll block all frames to other stations whilst they're transmitted and retransmitted. When I introduced 11n support, I added per-station and per-traffic-class queues in the driver as part of A-MPDU support. I software queue almost everything first and then schedule frames to the hardware from these software queued frames. This has the side effect of making it fairer between multiple stations, especially if one of them is far away. It will only schedule a small number of frames to each station before going to another station, rather than possibly being backed up with 128 frames just to a single destination. Now, it's likely there's more work that can be done to improve that behaviour with slow, far away clients. The framework is there in -HEAD. I've just not sat down and made it work. So if you update to -HEAD and you still have problems, we can tweak things and experiment. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: high latency due to distant clients
I really do suggest -HEAD everything. -adrian ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: high latency due to distant clients
On Jul 18, 2013, at 11:22 AM, Adrian Chadd adr...@freebsd.org wrote: On Jul 18, 2013, at 11:19 AM, Petar Bogdanovic pe...@smokva.net wrote: On Thu, Jul 18, 2013 at 09:25:19AM -0700, Adrian Chadd wrote: On 18 July 2013 09:04, Petar Bogdanovic pe...@smokva.net wrote: On Thu, Jul 18, 2013 at 08:59:29AM -0700, Adrian Chadd wrote: I think I fixed this in -HEAD. Uh-oh, great! Will that change reach a stable release anytime soon? When 10.0 is stable, yup. :) And--out of naive curiosity--what was the problem? The ath driver before 11n support went in would just fill the hardware TX queue with frames. There's no per-station queue or any kind of fair queuing. So if you fill the TX queue in the driver with frames to a far away station, it'll block all frames to other stations whilst they're transmitted and retransmitted. When I introduced 11n support, I added per-station and per-traffic-class queues in the driver as part of A-MPDU support. I software queue almost everything first and then schedule frames to the hardware from these software queued frames. This has the side effect of making it fairer between multiple stations, especially if one of them is far away. It will only schedule a small number of frames to each station before going to another station, rather than possibly being backed up with 128 frames just to a single destination. Now, it's likely there's more work that can be done to improve that behaviour with slow, far away clients. The framework is there in -HEAD. I've just not sat down and made it work. So if you update to -HEAD and you still have problems, we can tweak things and experiment. Thanks for the nice and comprehensive explanation! I'll prepare the upgrade during the next couple of weeks and report back. It will probably be 9.1 userland and HEAD kernel (that approach worked well in the past). I really do suggest -HEAD everything. If it makes you feel any better, I've been running -HEAD (with semi-regular updates) on my ALIX AP for a while without any trouble. Of course, I do the builds on another box... I'm happy to share make settings, etc if that would be useful. JN ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: high latency due to distant clients
On Thu, Jul 18, 2013 at 10:22:50AM -0700, Adrian Chadd wrote: I really do suggest -HEAD everything. Ok, will do. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: high latency due to distant clients
On Thu, Jul 18, 2013 at 04:31:10PM -0600, John Nielsen wrote: If it makes you feel any better, I've been running -HEAD (with semi-regular updates) on my ALIX AP for a while without any trouble. Of course, I do the builds on another box... I'm happy to share make settings, etc if that would be useful. Your kernel configuration would be interesting. Mine is attached. I think it's a modified version from http://m0n0.ch/wall/. Petar Bogdanovic machine i386 cpu I586_CPU ident ALIX makeoptions MODULES_OVERRIDE= options HZ=1000 options CONSPEED=38400 options CPU_GEODE hints ALIX.hints options SCHED_4BSD # 4BSD scheduler options INET# InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options TMPFS # Efficient memory file system options MD_ROOT # MD is a potential root device options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options NO_SWAPPING options DEVICE_POLLING device apic# I/O APIC # Bus support. device eisa device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives options ATA_STATIC_ID # Static device numbering device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device uart# Generic UART driver # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device vr # VIA Rhine, Rhine II # Wireless NIC cards device wlan# 802.11 support device wlan_wep# 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device wlan_xauth # 802.11 external authenticator support device wlan_acl device ath device ath_pci # Atheros pci/cardbus glue device ath_hal # Atheros HAL (includes binary component) device ath_rate_sample # SampleRate rate control for the ath driver options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors # Pseudo devices. device loop# Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel device tap # Ethernet tunnel device pty # Pseudo-ttys (telnet etc) device md # Memory disks device gif # IPv6 and IPv4 tunneling device if_bridge # Bridge interface device vlan# VLAN support (needs miibus) device bpf # Berkeley packet filter device pf # PF OpenBSD packet-filter firewall device pflog # logging support interface for PF #device pfsync # synchronization interface for PF options ALTQ options ALTQ_CBQ# Class Bases Queueing options ALTQ_RED# Random Early Detection options ALTQ_RIO# RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler options ALTQ_CDNR # Traffic conditioner options ALTQ_PRIQ # Priority Queueing #optionsALTQ_NOPCC # Required if the TSC is unusable options NETGRAPH# netgraph(4) system options NETGRAPH_ASYNC options NETGRAPH_BPF options NETGRAPH_ETHER options NETGRAPH_IFACE options NETGRAPH_KSOCKET options NETGRAPH_L2TP options NETGRAPH_MPPC_ENCRYPTION options NETGRAPH_PPP options NETGRAPH_PPPOE options NETGRAPH_PPTPGRE options NETGRAPH_SOCKET options NETGRAPH_TCPMSS options NETGRAPH_TEE options NETGRAPH_UI
