From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 25 03:20:15 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44AE2106566B for ; Sun, 25 Mar 2012 03:20:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2351C8FC17 for ; Sun, 25 Mar 2012 03:20:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2P3KFKl081883 for ; Sun, 25 Mar 2012 03:20:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2P3KEmu081882; Sun, 25 Mar 2012 03:20:14 GMT (envelope-from gnats) Date: Sun, 25 Mar 2012 03:20:14 GMT Message-Id: <201203250320.q2P3KEmu081882@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/166286: commit references a PR X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 03:20:15 -0000 The following reply was made to PR kern/166286; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/166286: commit references a PR Date: Sun, 25 Mar 2012 03:12:08 +0000 (UTC) Author: adrian Date: Sun Mar 25 03:11:57 2012 New Revision: 233452 URL: http://svn.freebsd.org/changeset/base/233452 Log: Create a new task to handle 802.11n channel width changes. Currently, a channel width change updates the 802.11n HT info data in net80211 but it doesn't trigger any device changes. So the device driver may decide that HT40 frames can be transmitted but the last device channel set only had HT20 set. Now, a task is scheduled so a hardware reset or change isn't done during any active ongoing RX. It also means that it's serialised with the other task operations (eg channel change.) This isn't the final incantation of this work, see below. For now, any unmodified drivers will simply receive a channel change log entry. A subsequent patch to ath(4) will introduce some basic channel change handling (by resetting the NIC.) Other NICs may need to update their rate control information. TODO: * There's still a small window at the present moment where the channel width has been updated but the task hasn't been fired. The final version of this should likely pass in a channel width field to the driver and let the driver atomically do whatever it needs to before changing the channel. PR: kern/166286 Modified: head/sys/net80211/ieee80211.c head/sys/net80211/ieee80211_ht.c head/sys/net80211/ieee80211_ht.h head/sys/net80211/ieee80211_node.c head/sys/net80211/ieee80211_node.h head/sys/net80211/ieee80211_proto.c head/sys/net80211/ieee80211_sta.c head/sys/net80211/ieee80211_var.h Modified: head/sys/net80211/ieee80211.c ============================================================================== --- head/sys/net80211/ieee80211.c Sun Mar 25 02:22:32 2012 (r233451) +++ head/sys/net80211/ieee80211.c Sun Mar 25 03:11:57 2012 (r233452) @@ -256,6 +256,13 @@ null_input(struct ifnet *ifp, struct mbu m_freem(m); } +static void +null_update_chw(struct ieee80211com *ic) +{ + + if_printf(ic->ic_ifp, "%s: need callback\n", __func__); +} + /* * Attach/setup the common net80211 state. Called by * the driver on attach to prior to creating any vap's. @@ -287,6 +294,7 @@ ieee80211_ifattach(struct ieee80211com * ic->ic_update_mcast = null_update_mcast; ic->ic_update_promisc = null_update_promisc; + ic->ic_update_chw = null_update_chw; ic->ic_hash_key = arc4random(); ic->ic_bintval = IEEE80211_BINTVAL_DEFAULT; Modified: head/sys/net80211/ieee80211_ht.c ============================================================================== --- head/sys/net80211/ieee80211_ht.c Sun Mar 25 02:22:32 2012 (r233451) +++ head/sys/net80211/ieee80211_ht.c Sun Mar 25 03:11:57 2012 (r233452) @@ -1428,12 +1428,13 @@ ieee80211_parse_htinfo(struct ieee80211_ * required channel change is done (e.g. in sta mode when * parsing the contents of a beacon frame). */ -static void +static int htinfo_update_chw(struct ieee80211_node *ni, int htflags) { struct ieee80211com *ic = ni->ni_ic; struct ieee80211_channel *c; int chanflags; + int ret = 0; chanflags = (ni->ni_chan->ic_flags &~ IEEE80211_CHAN_HT) | htflags; if (chanflags != ni->ni_chan->ic_flags) { @@ -1460,11 +1461,13 @@ htinfo_update_chw(struct ieee80211_node IEEE80211_IS_CHAN_HT40(c) ? 40 : 20, c->ic_freq, c->ic_flags); ni->ni_chan = c; + ret = 1; } /* NB: caller responsible for forcing any channel change */ } /* update node's tx channel width */ ni->ni_chw = IEEE80211_IS_CHAN_HT40(ni->ni_chan)? 40 : 20; + return (ret); } /* @@ -1515,13 +1518,14 @@ htcap_update_shortgi(struct ieee80211_no * Parse and update HT-related state extracted from * the HT cap and info ie's. */ -void +int ieee80211_ht_updateparams(struct ieee80211_node *ni, const uint8_t *htcapie, const uint8_t *htinfoie) { struct ieee80211vap *vap = ni->ni_vap; const struct ieee80211_ie_htinfo *htinfo; int htflags; + int ret = 0; ieee80211_parse_htcap(ni, htcapie); if (vap->iv_htcaps & IEEE80211_HTCAP_SMPS) @@ -1543,13 +1547,16 @@ ieee80211_ht_updateparams(struct ieee802 else if (ni->ni_ht2ndchan == IEEE80211_HTINFO_2NDCHAN_BELOW) htflags = IEEE80211_CHAN_HT40D; } - htinfo_update_chw(ni, htflags); + if (htinfo_update_chw(ni, htflags)) + ret = 1; if ((htinfo->hi_byte1 & IEEE80211_HTINFO_RIFSMODE_PERM) && (vap->iv_flags_ht & IEEE80211_FHT_RIFS)) ni->ni_flags |= IEEE80211_NODE_RIFS; else ni->ni_flags &= ~IEEE80211_NODE_RIFS; + + return (ret); } /* @@ -1578,7 +1585,7 @@ ieee80211_ht_updatehtcap(struct ieee8021 else if (IEEE80211_IS_CHAN_HT40D(vap->iv_bss->ni_chan)) htflags = IEEE80211_CHAN_HT40D; } - htinfo_update_chw(ni, htflags); + (void) htinfo_update_chw(ni, htflags); } /* Modified: head/sys/net80211/ieee80211_ht.h ============================================================================== --- head/sys/net80211/ieee80211_ht.h Sun Mar 25 02:22:32 2012 (r233451) +++ head/sys/net80211/ieee80211_ht.h Sun Mar 25 03:11:57 2012 (r233452) @@ -184,7 +184,7 @@ void ieee80211_htprot_update(struct ieee void ieee80211_ht_timeout(struct ieee80211com *); void ieee80211_parse_htcap(struct ieee80211_node *, const uint8_t *); void ieee80211_parse_htinfo(struct ieee80211_node *, const uint8_t *); -void ieee80211_ht_updateparams(struct ieee80211_node *, const uint8_t *, +int ieee80211_ht_updateparams(struct ieee80211_node *, const uint8_t *, const uint8_t *); void ieee80211_ht_updatehtcap(struct ieee80211_node *, const uint8_t *); int ieee80211_ampdu_request(struct ieee80211_node *, Modified: head/sys/net80211/ieee80211_node.c ============================================================================== --- head/sys/net80211/ieee80211_node.c Sun Mar 25 02:22:32 2012 (r233451) +++ head/sys/net80211/ieee80211_node.c Sun Mar 25 03:11:57 2012 (r233452) @@ -685,6 +685,14 @@ ieee80211_setcurchan(struct ieee80211com ieee80211_runtask(ic, &ic->ic_chan_task); } +void +ieee80211_update_chw(struct ieee80211com *ic) +{ + + ieee80211_setupcurchan(ic, ic->ic_curchan); + ieee80211_runtask(ic, &ic->ic_chw_task); +} + /* * Join the specified IBSS/BSS network. The node is assumed to * be passed in with a held reference. Modified: head/sys/net80211/ieee80211_node.h ============================================================================== --- head/sys/net80211/ieee80211_node.h Sun Mar 25 02:22:32 2012 (r233451) +++ head/sys/net80211/ieee80211_node.h Sun Mar 25 03:11:57 2012 (r233452) @@ -324,6 +324,7 @@ void ieee80211_sync_curchan(struct ieee8 void ieee80211_setupcurchan(struct ieee80211com *, struct ieee80211_channel *); void ieee80211_setcurchan(struct ieee80211com *, struct ieee80211_channel *); +void ieee80211_update_chw(struct ieee80211com *); int ieee80211_ibss_merge(struct ieee80211_node *); struct ieee80211_scan_entry; int ieee80211_sta_join(struct ieee80211vap *, struct ieee80211_channel *, Modified: head/sys/net80211/ieee80211_proto.c ============================================================================== --- head/sys/net80211/ieee80211_proto.c Sun Mar 25 02:22:32 2012 (r233451) +++ head/sys/net80211/ieee80211_proto.c Sun Mar 25 03:11:57 2012 (r233452) @@ -105,6 +105,7 @@ static void parent_updown(void *, int); static void update_mcast(void *, int); static void update_promisc(void *, int); static void update_channel(void *, int); +static void update_chw(void *, int); static void ieee80211_newstate_cb(void *, int); static int ieee80211_new_state_locked(struct ieee80211vap *, enum ieee80211_state, int); @@ -144,6 +145,7 @@ ieee80211_proto_attach(struct ieee80211c TASK_INIT(&ic->ic_promisc_task, 0, update_promisc, ic); TASK_INIT(&ic->ic_chan_task, 0, update_channel, ic); TASK_INIT(&ic->ic_bmiss_task, 0, beacon_miss, ic); + TASK_INIT(&ic->ic_chw_task, 0, update_chw, ic); ic->ic_wme.wme_hipri_switch_hysteresis = AGGRESSIVE_MODE_SWITCH_HYSTERESIS; @@ -1147,6 +1149,17 @@ update_channel(void *arg, int npending) ieee80211_radiotap_chan_change(ic); } +static void +update_chw(void *arg, int npending) +{ + struct ieee80211com *ic = arg; + + /* + * XXX should we defer the channel width _config_ update until now? + */ + ic->ic_update_chw(ic); +} + /* * Block until the parent is in a known state. This is * used after any operations that dispatch a task (e.g. @@ -1161,6 +1174,7 @@ ieee80211_waitfor_parent(struct ieee8021 ieee80211_draintask(ic, &ic->ic_promisc_task); ieee80211_draintask(ic, &ic->ic_chan_task); ieee80211_draintask(ic, &ic->ic_bmiss_task); + ieee80211_draintask(ic, &ic->ic_chw_task); taskqueue_unblock(ic->ic_tq); } Modified: head/sys/net80211/ieee80211_sta.c ============================================================================== --- head/sys/net80211/ieee80211_sta.c Sun Mar 25 02:22:32 2012 (r233451) +++ head/sys/net80211/ieee80211_sta.c Sun Mar 25 03:11:57 2012 (r233452) @@ -1285,6 +1285,7 @@ sta_recv_mgmt(struct ieee80211_node *ni, uint8_t *frm, *efrm; uint8_t *rates, *xrates, *wme, *htcap, *htinfo; uint8_t rate; + int ht_state_change = 0; wh = mtod(m0, struct ieee80211_frame *); frm = (uint8_t *)&wh[1]; @@ -1372,9 +1373,10 @@ sta_recv_mgmt(struct ieee80211_node *ni, #endif if (scan.htcap != NULL && scan.htinfo != NULL && (vap->iv_flags_ht & IEEE80211_FHT_HT)) { - ieee80211_ht_updateparams(ni, - scan.htcap, scan.htinfo); /* XXX state changes? */ + if (ieee80211_ht_updateparams(ni, + scan.htcap, scan.htinfo)) + ht_state_change = 1; } if (scan.quiet) ic->ic_set_quiet(ni, scan.quiet); @@ -1441,6 +1443,13 @@ sta_recv_mgmt(struct ieee80211_node *ni, #endif ieee80211_bg_scan(vap, 0); } + + /* + * If we've had a channel width change (eg HT20<->HT40) + * then schedule a delayed driver notification. + */ + if (ht_state_change) + ieee80211_update_chw(ic); return; } /* Modified: head/sys/net80211/ieee80211_var.h ============================================================================== --- head/sys/net80211/ieee80211_var.h Sun Mar 25 02:22:32 2012 (r233451) +++ head/sys/net80211/ieee80211_var.h Sun Mar 25 03:11:57 2012 (r233452) @@ -130,6 +130,7 @@ struct ieee80211com { struct task ic_mcast_task; /* deferred mcast update */ struct task ic_chan_task; /* deferred channel change */ struct task ic_bmiss_task; /* deferred beacon miss hndlr */ + struct task ic_chw_task; /* deferred HT CHW update */ uint32_t ic_flags; /* state flags */ uint32_t ic_flags_ext; /* extended state flags */ @@ -322,6 +323,10 @@ struct ieee80211com { int batimeout, int baseqctl); void (*ic_ampdu_rx_stop)(struct ieee80211_node *, struct ieee80211_rx_ampdu *); + + /* The channel width has changed (20<->2040) */ + void (*ic_update_chw)(struct ieee80211com *); + uint64_t ic_spare[7]; }; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 25 03:20:18 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 294E9106564A for ; Sun, 25 Mar 2012 03:20:18 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 09E438FC19 for ; Sun, 25 Mar 2012 03:20:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2P3KHMR081895 for ; Sun, 25 Mar 2012 03:20:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2P3KHfp081894; Sun, 25 Mar 2012 03:20:17 GMT (envelope-from gnats) Date: Sun, 25 Mar 2012 03:20:17 GMT Message-Id: <201203250320.q2P3KHfp081894@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/166286: commit references a PR X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 03:20:18 -0000 The following reply was made to PR kern/166286; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/166286: commit references a PR Date: Sun, 25 Mar 2012 03:14:39 +0000 (UTC) Author: adrian Date: Sun Mar 25 03:14:31 2012 New Revision: 233453 URL: http://svn.freebsd.org/changeset/base/233453 Log: Add the new channel width change field to the ath(4) driver. This is not entirely correct as it simply resets the channel, flushing whatever is in the TX/RX queue. This can and will break aggregation BAW tracking. But the alternative (HT40 frames being sent with the hardware in HT20 mode) is even worse. There's still a small window between the htinfo being received (and the ni_chw field being updated) which could cause problems. I'll look at fleshing this out in follow-up commits. PR: kern/166286 Modified: head/sys/dev/ath/if_ath.c Modified: head/sys/dev/ath/if_ath.c ============================================================================== --- head/sys/dev/ath/if_ath.c Sun Mar 25 03:11:57 2012 (r233452) +++ head/sys/dev/ath/if_ath.c Sun Mar 25 03:14:31 2012 (r233453) @@ -199,6 +199,7 @@ static void ath_chan_change(struct ath_s static void ath_scan_start(struct ieee80211com *); static void ath_scan_end(struct ieee80211com *); static void ath_set_channel(struct ieee80211com *); +static void ath_update_chw(struct ieee80211com *); static void ath_calibrate(void *); static int ath_newstate(struct ieee80211vap *, enum ieee80211_state, int); static void ath_setup_stationkey(struct ieee80211_node *); @@ -794,6 +795,7 @@ ath_attach(u_int16_t devid, struct ath_s ic->ic_scan_start = ath_scan_start; ic->ic_scan_end = ath_scan_end; ic->ic_set_channel = ath_set_channel; + ic->ic_update_chw = ath_update_chw; /* 802.11n specific - but just override anyway */ sc->sc_addba_request = ic->ic_addba_request; @@ -5717,6 +5719,31 @@ ath_scan_end(struct ieee80211com *ic) sc->sc_curaid); } +/* + * For now, just do a channel change. + * + * Later, we'll go through the hard slog of suspending tx/rx, changing rate + * control state and resetting the hardware without dropping frames out + * of the queue. + * + * The unfortunate trouble here is making absolutely sure that the + * channel width change has propagated enough so the hardware + * absolutely isn't handed bogus frames for it's current operating + * mode. (Eg, 40MHz frames in 20MHz mode.) Since TX and RX can and + * does occur in parallel, we need to make certain we've blocked + * any further ongoing TX (and RX, that can cause raw TX) + * before we do this. + */ +static void +ath_update_chw(struct ieee80211com *ic) +{ + struct ifnet *ifp = ic->ic_ifp; + struct ath_softc *sc = ifp->if_softc; + + DPRINTF(sc, ATH_DEBUG_STATE, "%s: called\n", __func__); + ath_set_channel(ic); +} + static void ath_set_channel(struct ieee80211com *ic) { _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 25 18:27:42 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CDFB1065674; Sun, 25 Mar 2012 18:27:42 +0000 (UTC) (envelope-from lytboris@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id B08148FC08; Sun, 25 Mar 2012 18:27:41 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so2988371wib.13 for ; Sun, 25 Mar 2012 11:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=JV67Kk2695VMY6COz7YCBRQQQU7160wJvz7ReXjDdaw=; b=mheqPsDTj2ulcnMLbsKcRiXZ9byl0fQACJ8erBlRFkNlGiLPZhVPvjWyx7PsOQpCXh A8UAdxXfWw+02K3FCZj5AI4CVFny2IchYl615z4QihYFCQXf291yJw0pMfmi3+OaDnOq d/0G1txh1cA5200lxcb7PwsPUG3BlThINUmla5gq0WoGGVrVuneDbVUitUVIWiVTfcUc VJRjVI4DAtOshYlxKPyWui8XVXrD47gmWXdwQDbkfqtm/2tkeRFx1ob+/bN7Upt4JqWc DyXXRH2oJZxDrttsVbjhTKVdCVgR0NqKZGcOHZyHqIQ0gE19rTcNYp7KKABwMWRqjXlP WH2g== MIME-Version: 1.0 Received: by 10.180.104.65 with SMTP id gc1mr12411471wib.13.1332700054639; Sun, 25 Mar 2012 11:27:34 -0700 (PDT) Received: by 10.223.72.6 with HTTP; Sun, 25 Mar 2012 11:27:34 -0700 (PDT) Date: Sun, 25 Mar 2012 22:27:34 +0400 Message-ID: From: Lytochkin Boris To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: [ath][CURRENT] Triangle-shaped network performance X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 18:27:42 -0000 Hi. I'm digging in appalling wireless network performance on my home router: fetching file from local NAS can run an 20kb/s rates while running 802.11n capable ath card. I found some curious fact: network performance is lagging periodically in triangle-shaped form. Look an this ping to router from my laptop: >ping 192.168.1.5 -t -w 1 Reply from 192.168.1.5: bytes=32 time=78ms TTL=64 Reply from 192.168.1.5: bytes=32 time=54ms TTL=64 Reply from 192.168.1.5: bytes=32 time=77ms TTL=64 Reply from 192.168.1.5: bytes=32 time=100ms TTL=64 Reply from 192.168.1.5: bytes=32 time=123ms TTL=64 Reply from 192.168.1.5: bytes=32 time=164ms TTL=64 Reply from 192.168.1.5: bytes=32 time=189ms TTL=64 Reply from 192.168.1.5: bytes=32 time=177ms TTL=64 Reply from 192.168.1.5: bytes=32 time=199ms TTL=64 Reply from 192.168.1.5: bytes=32 time=220ms TTL=64 Reply from 192.168.1.5: bytes=32 time=243ms TTL=64 Reply from 192.168.1.5: bytes=32 time=265ms TTL=64 Reply from 192.168.1.5: bytes=32 time=288ms TTL=64 Reply from 192.168.1.5: bytes=32 time=310ms TTL=64 Reply from 192.168.1.5: bytes=32 time=340ms TTL=64 Reply from 192.168.1.5: bytes=32 time=367ms TTL=64 Reply from 192.168.1.5: bytes=32 time=373ms TTL=64 Reply from 192.168.1.5: bytes=32 time=416ms TTL=64 Reply from 192.168.1.5: bytes=32 time=414ms TTL=64 Reply from 192.168.1.5: bytes=32 time=425ms TTL=64 Timeout. Reply from 192.168.1.5: bytes=32 time=39ms TTL=64 Reply from 192.168.1.5: bytes=32 time=57ms TTL=64 Reply from 192.168.1.5: bytes=32 time=81ms TTL=64 Reply from 192.168.1.5: bytes=32 time=104ms TTL=64 Reply from 192.168.1.5: bytes=32 time=130ms TTL=64 Reply from 192.168.1.5: bytes=32 time=147ms TTL=64 Reply from 192.168.1.5: bytes=32 time=174ms TTL=64 Reply from 192.168.1.5: bytes=32 time=193ms TTL=64 Reply from 192.168.1.5: bytes=32 time=214ms TTL=64 Timeout. Reply from 192.168.1.5: bytes=32 time=297ms TTL=64 Reply from 192.168.1.5: bytes=32 time=314ms TTL=64 Reply from 192.168.1.5: bytes=32 time=330ms TTL=64 Reply from 192.168.1.5: bytes=32 time=355ms TTL=64 Reply from 192.168.1.5: bytes=32 time=376ms TTL=64 Reply from 192.168.1.5: bytes=32 time=402ms TTL=64 Reply from 192.168.1.5: bytes=32 time=422ms TTL=64 Reply from 192.168.1.5: bytes=32 time=445ms TTL=64 Reply from 192.168.1.5: bytes=32 time=467ms TTL=64 Timeout. Reply from 192.168.1.5: bytes=32 time=40ms TTL=64 Reply from 192.168.1.5: bytes=32 time=62ms TTL=64 Reply from 192.168.1.5: bytes=32 time=96ms TTL=64 Reply from 192.168.1.5: bytes=32 time=116ms TTL=64 Reply from 192.168.1.5: bytes=32 time=133ms TTL=64 Reply from 192.168.1.5: bytes=32 time=159ms TTL=64 Reply from 192.168.1.5: bytes=32 time=176ms TTL=64 Reply from 192.168.1.5: bytes=32 time=188ms TTL=64 Reply from 192.168.1.5: bytes=32 time=223ms TTL=64 Reply from 192.168.1.5: bytes=32 time=233ms TTL=64 Reply from 192.168.1.5: bytes=32 time=321ms TTL=64 Reply from 192.168.1.5: bytes=32 time=285ms TTL=64 Reply from 192.168.1.5: bytes=32 time=298ms TTL=64 Reply from 192.168.1.5: bytes=32 time=320ms TTL=64 Reply from 192.168.1.5: bytes=32 time=350ms TTL=64 Reply from 192.168.1.5: bytes=32 time=374ms TTL=64 Reply from 192.168.1.5: bytes=32 time=396ms TTL=64 Reply from 192.168.1.5: bytes=32 time=420ms TTL=64 Timeout. Timeout. Reply from 192.168.1.5: bytes=32 time=24ms TTL=64 Reply from 192.168.1.5: bytes=32 time=43ms TTL=64 Reply from 192.168.1.5: bytes=32 time=65ms TTL=64 Reply from 192.168.1.5: bytes=32 time=89ms TTL=64 Reply from 192.168.1.5: bytes=32 time=109ms TTL=64 Reply from 192.168.1.5: bytes=32 time=131ms TTL=64 Reply from 192.168.1.5: bytes=32 time=154ms TTL=64 Reply from 192.168.1.5: bytes=32 time=176ms TTL=64 Reply from 192.168.1.5: bytes=32 time=200ms TTL=64 Reply from 192.168.1.5: bytes=32 time=221ms TTL=64 Reply from 192.168.1.5: bytes=32 time=244ms TTL=64 Reply from 192.168.1.5: bytes=32 time=268ms TTL=64 Reply from 192.168.1.5: bytes=32 time=290ms TTL=64 Reply from 192.168.1.5: bytes=32 time=314ms TTL=64 Reply from 192.168.1.5: bytes=32 time=357ms TTL=64 Reply from 192.168.1.5: bytes=32 time=359ms TTL=64 Reply from 192.168.1.5: bytes=32 time=392ms TTL=64 Reply from 192.168.1.5: bytes=32 time=430ms TTL=64 Reply from 192.168.1.5: bytes=32 time=429ms TTL=64 Reply from 192.168.1.5: bytes=32 time=448ms TTL=64 Timeout. Timeout. Reply from 192.168.1.5: bytes=32 time=66ms TTL=64 Reply from 192.168.1.5: bytes=32 time=89ms TTL=64 Reply from 192.168.1.5: bytes=32 time=118ms TTL=64 Reply from 192.168.1.5: bytes=32 time=138ms TTL=64 Reply from 192.168.1.5: bytes=32 time=154ms TTL=64 Reply from 192.168.1.5: bytes=32 time=163ms TTL=64 Reply from 192.168.1.5: bytes=32 time=185ms TTL=64 Reply from 192.168.1.5: bytes=32 time=227ms TTL=64 Reply from 192.168.1.5: bytes=32 time=229ms TTL=64 Reply from 192.168.1.5: bytes=32 time=261ms TTL=64 Reply from 192.168.1.5: bytes=32 time=274ms TTL=64 Reply from 192.168.1.5: bytes=32 time=297ms TTL=64 Reply from 192.168.1.5: bytes=32 time=318ms TTL=64 Reply from 192.168.1.5: bytes=32 time=340ms TTL=64 Reply from 192.168.1.5: bytes=32 time=366ms TTL=64 Reply from 192.168.1.5: bytes=32 time=388ms TTL=64 Reply from 192.168.1.5: bytes=32 time=408ms TTL=64 Reply from 192.168.1.5: bytes=32 time=431ms TTL=64 Reply from 192.168.1.5: bytes=32 time=452ms TTL=64 Timeout. Reply from 192.168.1.5: bytes=32 time=38ms TTL=64 Reply from 192.168.1.5: bytes=32 time=62ms TTL=64 Reply from 192.168.1.5: bytes=32 time=83ms TTL=64 Reply from 192.168.1.5: bytes=32 time=105ms TTL=64 Reply from 192.168.1.5: bytes=32 time=128ms TTL=64 Reply from 192.168.1.5: bytes=32 time=151ms TTL=64 Reply from 192.168.1.5: bytes=32 time=171ms TTL=64 Reply from 192.168.1.5: bytes=32 time=195ms TTL=64 Reply from 192.168.1.5: bytes=32 time=217ms TTL=64 Reply from 192.168.1.5: bytes=32 time=248ms TTL=64 Reply from 192.168.1.5: bytes=32 time=278ms TTL=64 Reply from 192.168.1.5: bytes=32 time=291ms TTL=64 Reply from 192.168.1.5: bytes=32 time=304ms TTL=64 Reply from 192.168.1.5: bytes=32 time=317ms TTL=64 Reply from 192.168.1.5: bytes=32 time=337ms TTL=64 Reply from 192.168.1.5: bytes=32 time=339ms TTL=64 Reply from 192.168.1.5: bytes=32 time=361ms TTL=64 Reply from 192.168.1.5: bytes=32 time=383ms TTL=64 Reply from 192.168.1.5: bytes=32 time=405ms TTL=64 Reply from 192.168.1.5: bytes=32 time=427ms TTL=64 Timeout. Reply from 192.168.1.5: bytes=32 time=42ms TTL=64 This hell happens some minutes after successful boot and working with ~1ms pings. Than it booms and this triangle nightmare starts. >uname -a FreeBSD gate.home 10.0-CURRENT FreeBSD 10.0-CURRENT #1: Fri Feb 17 23:48:28 MSK 2012 root@gate.home:/usr/obj/usr/src/sys/GATEv2 i386 (I tried today's kernel - bug is still there regardless of ATH_ENABLE_11N option). >ifconfig -v wlan0 wlan0: flags=8843 metric 0 mtu 1500 ether b0:48:7a:da:0e:59 inet6 fe80::b248:7aff:feda:e59%wlan0 prefixlen 64 tentative scopeid 0x10 inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng status: running ssid starlink channel 11 (2462 MHz 11g ht/40-) bssid b0:48:7a:da:0e:59 regdomain ETSI country RU indoor ecm authmode WPA -wps -tsn privacy MIXED deftxkey 3 AES-CCM 2:128-bit AES-CCM 3:128-bit powersavemode OFF powersavesleep 100 txpower 50 txpowmax 50.0 -dotd rtsthreshold 2346 fragthreshold 2346 bmiss 7 11a ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 11b ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 11g ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 turboA ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 turboG ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 sturbo ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 11na ucast NONE mgmt 12 MCS mcast 12 MCS maxretry 6 11ng ucast NONE mgmt 2 MCS mcast 2 MCS maxretry 6 half ucast NONE mgmt 3 Mb/s mcast 3 Mb/s maxretry 6 quarter ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 scanvalid 60 -bgscan bgscanintvl 300 bgscanidle 250 roam:11a rssi 7dBm rate 12 Mb/s roam:11b rssi 7dBm rate 1 Mb/s roam:11g rssi 7dBm rate 5 Mb/s roam:turboA rssi 7dBm rate 12 Mb/s roam:turboG rssi 7dBm rate 12 Mb/s roam:sturbo rssi 7dBm rate 12 Mb/s roam:11na rssi 7dBm MCS 1 roam:11ng rssi 7dBm MCS 1 roam:half rssi 7dBm rate 6 Mb/s roam:quarter rssi 7dBm rate 3 Mb/s -pureg protmode CTS ht htcompat ampdu ampdulimit 64k ampdudensity 8 amsdu shortgi htprotmode RTSCTS -puren -smps -rifs wme burst -dwds -hidessid apbridge dtimperiod 1 doth -dfs inact bintval 1000 AC_BE cwmin 4 cwmax 6 aifs 3 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm AC_BK cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm AC_VI cwmin 3 cwmax 4 aifs 1 txopLimit 94 -acm ack cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm AC_VO cwmin 2 cwmax 3 aifs 1 txopLimit 47 -acm ack cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm groups: wlan ~>athstats 17532 data frames received 12450 data frames transmit 4 tx frames with an alternate rate 2060 long on-chip tx retries 187 tx failed 'cuz too many retries MCS5 current transmit rate 417 tx frames with no ack marked 11805 tx frames with short preamble 1003 rx failed 'cuz of bad CRC 1495 beacons transmitted 26 periodic calibrations -0/+0 TDMA slot adjust (usecs, smoothed) 63 rssi of last ack 64 avg recv rssi -96 rx noise floor 229 tx frames through raw api 1726 A-MPDU sub-frames received 513 CRC errors for non-last A-MPDU subframes 272 CRC errors for last subframe in an A-MPDU 308 A-MPDU sub-frame TX attempt success 10389 cabq frames transmitted 746 cabq xmit overflowed beacon interval 1 OFDM weak signal detect 388 listen time 3 ANI disabled OFDM weak signal detect 1 ANI disabled CCK weak signal threshold 21671 cumulative OFDM phy error count 130597 cumulative CCK phy error count 30 ANI forced listen time to zero 2060 missing ACK's 1374 bad FCS 13 average rssi (beacons only) Antenna profile: [0] tx 12052 rx 12 [1] tx 0 rx 17520 >pciconf -l -v ... ath0@pci0:2:13:0: class=0x028000 card=0x2091168c chip=0x0029168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR922X Wireless Network Adapter' class = network ... Do somebody have any ideas where to dig next? ps. There is LOR on router startup: Mar 25 22:11:49 gate kernel: lock order reversal: Mar 25 22:11:49 gate kernel: 1st 0xc54b46c0 ath0_node_lock (ath0_node_lock) @ /usr/src/sys/net80211/ieee80211_ioctl.c:1341 Mar 25 22:11:49 gate kernel: 2nd 0xc54b3014 ath0_com_lock (ath0_com_lock) @ /usr/src/sys/net80211/ieee80211_node.c:2510 Mar 25 22:11:49 gate kernel: KDB: stack backtrace: Mar 25 22:11:49 gate kernel: db_trace_self_wrapper(c0cae317,6372732f,7379732f,74656e2f,31323038,...) at db_trace_self_wrapper+0x26 Mar 25 22:11:49 gate kernel: kdb_backtrace(c086e65b,c0cb1d64,c0ee7060,9ce,d6f478d8,...) at kdb_backtrace+0x2a Mar 25 22:11:49 gate kernel: _witness_debugger(c0cb1d64,c54b3014,c54b3004,c3d55590,c0cc7c06,...) at _witness_debugger+0x25 Mar 25 22:11:49 gate kernel: witness_checkorder(c54b3014,9,c0cc7c06,9ce,0,...) at witness_checkorder+0x86b Mar 25 22:11:49 gate kernel: _mtx_lock_flags(c54b3014,0,c0cc7c06,9ce,64,...) at _mtx_lock_flags+0xcc Mar 25 22:11:49 gate kernel: ieee80211_node_leave(c6ef4000,c0,2,c6ef4000,c54b46ac,...) at ieee80211_node_leave+0xb3 Mar 25 22:11:49 gate kernel: domlme(d6f47974,c6ef4000,c0cc7140,53d,d6f479a6,...) at domlme+0x83 Mar 25 22:11:49 gate kernel: setmlme_common(2,d6f479a2,2a,30000,11080002,...) at setmlme_common+0x132 Mar 25 22:11:49 gate kernel: ieee80211_ioctl_setmlme(c0ee7060,c6a1cc30,c0ee7060,c0d4ccd8,c6a1cb80,...) at ieee80211_ioctl_setmlme+0xa4 Mar 25 22:11:49 gate kernel: ieee80211_ioctl_set80211(c6a1cb80,1b9,d6f47a80,c0882524,c54b3000,...) at ieee80211_ioctl_set80211+0x554 Mar 25 22:11:49 gate kernel: ieee80211_ioctl(c646f400,801c69ea,c551ecc0,c0cbe319,d6f47ac0,...) at ieee80211_ioctl+0x300 Mar 25 22:11:49 gate kernel: in_control(c6a661a0,801c69ea,c551ecc0,c646f400,c6a1cb80,...) at in_control+0x235 Mar 25 22:11:49 gate kernel: ifioctl(c6a661a0,801c69ea,c551ecc0,c6a1cb80,c68fa9d8,...) at ifioctl+0x18c4 Mar 25 22:11:49 gate kernel: soo_ioctl(c68fa9d8,801c69ea,c551ecc0,c3da2180,c6a1cb80,...) at soo_ioctl+0x44f Mar 25 22:11:49 gate kernel: kern_ioctl(c6a1cb80,3,801c69ea,c551ecc0,f47cec,...) at kern_ioctl+0x22d Mar 25 22:11:49 gate kernel: sys_ioctl(c6a1cb80,d6f47cec,48,19ce87f7,206,...) at sys_ioctl+0x13f Mar 25 22:11:49 gate kernel: syscall(d6f47d28) at syscall+0x2e0 Mar 25 22:11:49 gate kernel: Xint0x80_syscall() at Xint0x80_syscall+0x21 Mar 25 22:11:49 gate kernel: --- syscall (54, FreeBSD ELF32, sys_ioctl), eip = 0x2821d143, esp = 0xbfbfeabc, ebp = 0xbfbfeb18 --- -- Boris Lytochkin From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 25 18:44:57 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82325106566C; Sun, 25 Mar 2012 18:44:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3360F8FC16; Sun, 25 Mar 2012 18:44:56 +0000 (UTC) Received: by iahk25 with SMTP id k25so9357021iah.13 for ; Sun, 25 Mar 2012 11:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:to:cc:reply-to:subject:in-reply-to:x-mailer :mime-version:content-type; bh=X4r+FqnKHHEpz8YQy90IYFFkeFYG6KGlqISxVrYsX90=; b=c/hHac677RCVzohYFNyO4IxBZVmjshLEbrBi3ScWUClnf8ZoNSTVBlQwoS9RQGA3tZ haAJhoff6UInvlBjoExyJtAmbRhhA3ZAwI00Cuml83vckPec2YJfTSdFULwTr+Pn7neD lb3ujNI60c1PW7ph3azJv5My0kTJ7lngR9dQpY0OupBibEk7XyO99C2lqwYqzIt7KdcF /10rt+dX4n7Ku3hge6KNMmKT6xrkS+80pBwVq5eyps6G1wfCUpCCOACGfu9X5+9SEzD2 YzhWW51i0izq8ZBX9YuPQ8p+l73YNF+IRsqOydnHyUbdBhQSfYUHX/XSFSJ0f7bG7vpq bIVw== Received: by 10.68.129.133 with SMTP id nw5mr47351071pbb.159.1332701096267; Sun, 25 Mar 2012 11:44:56 -0700 (PDT) Received: from www.palm.com ([32.153.132.214]) by mx.google.com with ESMTPS id w10sm10704915pbb.20.2012.03.25.11.44.47 (version=SSLv3 cipher=OTHER); Sun, 25 Mar 2012 11:44:55 -0700 (PDT) Message-ID: <4f6f67a7.4a0c440a.3941.ffffc865@mx.google.com> Date: Sun, 25 Mar 2012 11:44:49 -0700 From: "Adrian Chadd" To: "Lytochkin Boris" , "freebsd-wireless@freebsd.org" In-Reply-To: X-Mailer: Palm webOS v1.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: [ath][CURRENT] Triangle-shaped network performance X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Chadd List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 18:44:57 -0000 Hi, The LOR is known. I'd love to fix it but I have other things to do first. Try running athstats 1 and watch the rate of errors change over time. Disable HT40 as on ongested channels it's going to behave very oddly. Adrian Sent from my Palm Pre on AT&T On Mar 25, 2012 11:27 AM, Lytochkin Boris <lytboris@gmail.com> wrote:= Hi. I'm digging in appalling wireless network performance on my home router: fetching file from local NAS can run an 20kb/s rates while running 802.11n capable ath card. I found some curious fact: network performance is lagging periodically in triangle-shaped form. Look an this ping to router from my laptop: >ping 192.168.1.5 -t -w 1 Reply from 192.168.1.5: bytes=3D32 time=3D78ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D54ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D77ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D100ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D123ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D164ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D189ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D177ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D199ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D220ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D243ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D265ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D288ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D310ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D340ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D367ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D373ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D416ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D414ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D425ms TTL=3D64 Timeout. Reply from 192.168.1.5: bytes=3D32 time=3D39ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D57ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D81ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D104ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D130ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D147ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D174ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D193ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D214ms TTL=3D64 Timeout. Reply from 192.168.1.5: bytes=3D32 time=3D297ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D314ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D330ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D355ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D376ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D402ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D422ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D445ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D467ms TTL=3D64 Timeout. Reply from 192.168.1.5: bytes=3D32 time=3D40ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D62ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D96ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D116ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D133ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D159ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D176ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D188ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D223ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D233ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D321ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D285ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D298ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D320ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D350ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D374ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D396ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D420ms TTL=3D64 Timeout. Timeout. Reply from 192.168.1.5: bytes=3D32 time=3D24ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D43ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D65ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D89ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D109ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D131ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D154ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D176ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D200ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D221ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D244ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D268ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D290ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D314ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D357ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D359ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D392ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D430ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D429ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D448ms TTL=3D64 Timeout. Timeout. Reply from 192.168.1.5: bytes=3D32 time=3D66ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D89ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D118ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D138ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D154ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D163ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D185ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D227ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D229ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D261ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D274ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D297ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D318ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D340ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D366ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D388ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D408ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D431ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D452ms TTL=3D64 Timeout. Reply from 192.168.1.5: bytes=3D32 time=3D38ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D62ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D83ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D105ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D128ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D151ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D171ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D195ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D217ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D248ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D278ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D291ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D304ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D317ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D337ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D339ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D361ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D383ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D405ms TTL=3D64 Reply from 192.168.1.5: bytes=3D32 time=3D427ms TTL=3D64 Timeout. Reply from 192.168.1.5: bytes=3D32 time=3D42ms TTL=3D64 This hell happens some minutes after successful boot and working with ~1ms pings. Than it booms and this triangle nightmare starts. >uname -a FreeBSD gate.home 10.0-CURRENT FreeBSD 10.0-CURRENT #1: Fri Feb 17 23:48:28 MSK 2012 root@gate.home:/usr/obj/usr/src/sys/GATEv2 i386 (I tried today's kernel - bug is still there regardless of ATH_ENABLE_11N option). >ifconfig -v wlan0 wlan0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0= mtu 1500 ether b0:48:7a:da:0e:59 inet6 fe80::b248:7aff:feda:e59%wlan0 prefixlen 64 tentative scopeid= 0x10 inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng <hosta= p> status: running ssid starlink channel 11 (2462 MHz 11g ht/40-) bssid b0:48:7a:da:0e= :59 regdomain ETSI country RU indoor ecm authmode WPA -wps -tsn privacy MIXED deftxkey 3 AES-CCM 2:128-bit AES-CCM 3:128-bit powersavemode OFF powersavesleep 100 txpower 50 txpowmax 50.0 -dotd rtsthreshold 2346 fragthreshold 2346 bmiss 7 11a ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 11b ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 11g ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 turboA ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 turboG ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 sturbo ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 11na ucast NONE mgmt 12 MCS mcast 12 MCS maxretry 6 11ng ucast NONE mgmt 2 MCS mcast 2 MCS maxretry 6 half ucast NONE mgmt 3 Mb/s mcast 3 Mb/s maxretry 6 quarter ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 scanvalid 60 -bgscan bgscanintvl 300 bgscanidle 250 roam:11a rssi 7dBm rate 12 Mb/s roam:11b rssi 7dBm rate 1 Mb/s roam:11g rssi 7dBm rate 5 Mb/s roam:turboA rssi 7dBm rate 12 Mb/s roam:turboG rssi 7dBm rate 12 Mb/s roam:sturbo rssi 7dBm rate 12 Mb/s roam:11na rssi 7dBm MCS 1 roam:11ng rssi 7dBm MCS 1 roam:half rssi 7dBm rate 6 Mb/s roam:quarter rssi 7dBm rate 3 Mb/s -pureg protmode CTS ht htcompat ampdu ampdulimit 64k ampdudensity= 8 amsdu shortgi htprotmode RTSCTS -puren -smps -rifs wme burst -dwds -hidessid apbridge dtimperiod 1 doth -dfs inact bintval 1000 AC_BE cwmin 4 cwmax 6 aifs 3 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm AC_BK cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm AC_VI cwmin 3 cwmax 4 aifs 1 txopLimit 94 -acm ack cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm AC_VO cwmin 2 cwmax 3 aifs 1 txopLimit 47 -acm ack cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm groups: wlan ~>athstats 17532 data frames received 12450 data frames transmit 4 tx frames with an alternate rate 2060 long on-chip tx retries 187 tx failed 'cuz too many retries MCS5 current transmit rate 417 tx frames with no ack marked 11805 tx frames with short preamble 1003 rx failed 'cuz of bad CRC 1495 beacons transmitted 26 periodic calibrations -0/+0 TDMA slot adjust (usecs, smoothed) 63 rssi of last ack 64 avg recv rssi -96 rx noise floor 229 tx frames through raw api 1726 A-MPDU sub-frames received 513 CRC errors for non-last A-MPDU subframes 272 CRC errors for last subframe in an A-MPDU 308 A-MPDU sub-frame TX attempt success 10389 cabq frames transmitted 746 cabq xmit overflowed beacon interval 1 OFDM weak signal detect 388 listen time 3 ANI disabled OFDM weak signal detect 1 ANI disabled CCK weak signal threshold 21671 cumulative OFDM phy error count 130597 cumulative CCK phy error count 30 ANI forced listen time to zero 2060 missing ACK's 1374 bad FCS 13 average rssi (beacons only) Antenna profile: [0] tx 12052 rx 12 [1] tx 0 rx 17520 >pciconf -l -v =2E.. ath0@pci0:2:13:0: class=3D0x028000 card=3D0x2091168c chip=3D0x0029168c rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' device =3D 'AR922X Wireless Network Adapter' class =3D network =2E.. Do somebody have any ideas where to dig next? ps. There is LOR on router startup: Mar 25 22:11:49 gate kernel: lock order reversal: Mar 25 22:11:49 gate kernel: 1st 0xc54b46c0 ath0_node_lock (ath0_node_lock) @ /usr/src/sys/net80211/ieee80211_ioctl.c:1341 Mar 25 22:11:49 gate kernel: 2nd 0xc54b3014 ath0_com_lock (ath0_com_lock) @ /usr/src/sys/net80211/ieee80211_node.c:2510 Mar 25 22:11:49 gate kernel: KDB: stack backtrace: Mar 25 22:11:49 gate kernel: db_trace_self_wrapper(c0cae317,6372732f,7379732f,74656e2f,31323038,...) at db_trace_self_wrapper+0x26 Mar 25 22:11:49 gate kernel: kdb_backtrace(c086e65b,c0cb1d64,c0ee7060,9ce,d6f478d8,...) at kdb_backtrace+0x2a Mar 25 22:11:49 gate kernel: _witness_debugger(c0cb1d64,c54b3014,c54b3004,c3d55590,c0cc7c06,...) at _witness_debugger+0x25 Mar 25 22:11:49 gate kernel: witness_checkorder(c54b3014,9,c0cc7c06,9ce,0,...) at witness_checkorder+0x86b Mar 25 22:11:49 gate kernel: _mtx_lock_flags(c54b3014,0,c0cc7c06,9ce,64,...) at _mtx_lock_flags+0xcc Mar 25 22:11:49 gate kernel: ieee80211_node_leave(c6ef4000,c0,2,c6ef4000,c54b46ac,...) at ieee80211_node_leave+0xb3 Mar 25 22:11:49 gate kernel: domlme(d6f47974,c6ef4000,c0cc7140,53d,d6f479a6,...) at domlme+0x83 Mar 25 22:11:49 gate kernel: setmlme_common(2,d6f479a2,2a,30000,11080002,...) at setmlme_common+0x132 Mar 25 22:11:49 gate kernel: ieee80211_ioctl_setmlme(c0ee7060,c6a1cc30,c0ee7060,c0d4ccd8,c6a1cb80,...) at ieee80211_ioctl_setmlme+0xa4 Mar 25 22:11:49 gate kernel: ieee80211_ioctl_set80211(c6a1cb80,1b9,d6f47a80,c0882524,c54b3000,...) at ieee80211_ioctl_set80211+0x554 Mar 25 22:11:49 gate kernel: ieee80211_ioctl(c646f400,801c69ea,c551ecc0,c0cbe319,d6f47ac0,...) at ieee80211_ioctl+0x300 Mar 25 22:11:49 gate kernel: in_control(c6a661a0,801c69ea,c551ecc0,c646f400,c6a1cb80,...) at in_control+0x235 Mar 25 22:11:49 gate kernel: ifioctl(c6a661a0,801c69ea,c551ecc0,c6a1cb80,c68fa9d8,...) at ifioctl+0x18c4 Mar 25 22:11:49 gate kernel: soo_ioctl(c68fa9d8,801c69ea,c551ecc0,c3da2180,c6a1cb80,...) at soo_ioctl+0x44f Mar 25 22:11:49 gate kernel: kern_ioctl(c6a1cb80,3,801c69ea,c551ecc0,f47cec,...) at kern_ioctl+0x22d Mar 25 22:11:49 gate kernel: sys_ioctl(c6a1cb80,d6f47cec,48,19ce87f7,206,...) at sys_ioctl+0x13f Mar 25 22:11:49 gate kernel: syscall(d6f47d28) at syscall+0x2e0 Mar 25 22:11:49 gate kernel: Xint0x80_syscall() at Xint0x80_syscall+0x21 Mar 25 22:11:49 gate kernel: --- syscall (54, FreeBSD ELF32, sys_ioctl), eip =3D 0x2821d143, esp =3D 0xbfbfeabc, ebp =3D 0xbfbfeb18 --- --=20 Boris Lytochkin From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 25 19:16:13 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50F47106566C; Sun, 25 Mar 2012 19:16:13 +0000 (UTC) (envelope-from lytboris@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id B07748FC14; Sun, 25 Mar 2012 19:16:12 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so2953024wib.13 for ; Sun, 25 Mar 2012 12:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9QI/7Raj/SHiiDC1tHhgIxfCddZ9LzzJLAwZK+nQ+7g=; b=s6NwevjbDQjTw2kmhKUSmMauWEd1kkXa4mQB0bbDE7u/E21J9LK0hKuGKe5Wvl8zXD x4EM7mq4j6J1V9DI8BQvT5llHN5HqjJ0BkrkaGLmNjC/kjnBvNLdeR3O5OYLzrV1OHBD A1Z7vxXz6sLEQM1jAu6Y8VyrN0iqoLz8+lX36PIhLSeNa+EuZ7bD4+W4HnnH7zDiZHPk Qc/nRpFAIBnZQWB3y42la0NZt3bM3dfIglTymegcdmAGQ+QxW31lbBclKWLFjuhQXGli BQ7K509Llo7QHE64A0wSPYHTKkzO2f/W0usG7YeHM5GmfTOVrqpwNDGyeP09qeVbh60D FaKw== MIME-Version: 1.0 Received: by 10.216.144.138 with SMTP id n10mr10906465wej.56.1332702966220; Sun, 25 Mar 2012 12:16:06 -0700 (PDT) Received: by 10.223.72.6 with HTTP; Sun, 25 Mar 2012 12:16:06 -0700 (PDT) In-Reply-To: <4f6f67a7.4a0c440a.3941.ffffc865@mx.google.com> References: <4f6f67a7.4a0c440a.3941.ffffc865@mx.google.com> Date: Sun, 25 Mar 2012 23:16:06 +0400 Message-ID: From: Lytochkin Boris To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" Subject: Re: [ath][CURRENT] Triangle-shaped network performance X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 19:16:13 -0000 On Sun, Mar 25, 2012 at 10:44 PM, Adrian Chadd wrote: > Hi, > > The LOR is known. I'd love to fix it but I have other things to do first. > > Try running athstats 1 and watch the rate of errors change over time. Here it is. input output altrate short long xretry crcerr crypt phyerr rssi rate 44332 38318 20 0 14735 1813 1536 0 0 60 MCS11 39 41 0 0 2 0 0 0 0 69 MCS11 32 64 0 0 21 3 0 0 0 53 MCS11 38 66 0 0 4 0 0 0 0 64 MCS11 37 40 0 0 14 2 0 0 0 60 MCS6 28 32 0 0 1 0 0 0 0 56 MCS11 34 46 0 0 1 0 1 0 0 51 MCS0 44 37 0 0 18 3 0 0 0 64 MCS11 32 61 0 0 4 0 0 0 0 62 MCS11 41 60 0 0 20 3 1 0 0 66 MCS11 45 54 0 0 7 0 0 0 0 59 MCS6 43 64 0 0 20 2 0 0 0 65 MCS11 Somewere in the middle triangle-shaped ping reset (timed out and then rolled over) > > Disable HT40 as on ongested channels it's going to behave very oddly. That does not help always. 5 minutes ago I had the same triangles on ~>ifconfig wlan0 wlan0: flags=8843 metric 0 mtu 1500 ether b0:48:7a:da:0e:59 inet6 fe80::b248:7aff:feda:e59%wlan0 prefixlen 64 tentative scopeid 0x10 inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng status: running ssid starlink channel 13 (2472 MHz 11g ht/20) bssid b0:48:7a:da:0e:59 regdomain ETSI country RU indoor ecm authmode WPA privacy MIXED deftxkey 3 AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 50 scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 8 shortgi wme burst dtimperiod 1 -dfs bintval 1000 (the moment I took athstats snapshot shown in this mail). Some more observations: it can be cured temporarily fetching some data though wireless: first it will start at 10kb/s than in a minute or something triggers and both speed goes up and pings are sane. If transfer is stopped triangles come in 5-10 seconds after transfer abort. Here it is some kind of diagram of such behavior (reproducible), 1 ping per second: Reply from 192.168.1.5: bytes=32 RTT=297ms TTL=64 <-- transfer started, speed 10kb/s Reply from 192.168.1.5: bytes=32 RTT=318ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=340ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=360ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=388ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=410ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=434ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=457ms TTL=64 Timeout. Reply from 192.168.1.5: bytes=32 RTT=35ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=58ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=78ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=101ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=123ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=147ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=173ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=195ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=217ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=237ms TTL=64 Timeout. Reply from 192.168.1.5: bytes=32 RTT<1ms TTL=64 <-- speed goes to normal Reply from 192.168.1.5: bytes=32 RTT=3ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=2ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=4ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=3ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=2ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=3ms TTL=64 <-- transfer aborted Reply from 192.168.1.5: bytes=32 RTT<1ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT<1ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=1ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT<1ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT<1ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=2ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=1ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=1ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=1ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=1ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT<1ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT<1ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT<1ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT<1ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT<1ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=1ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=299ms TTL=64 <-- triangles again! Reply from 192.168.1.5: bytes=32 RTT=322ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=345ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=368ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=390ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=413ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=436ms TTL=64 Timeout. Reply from 192.168.1.5: bytes=32 RTT=34ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=57ms TTL=64 Reply from 192.168.1.5: bytes=32 RTT=80ms TTL=64 -- Boris Lytochkin From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 25 19:21:18 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6606A106566C for ; Sun, 25 Mar 2012 19:21:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 389C48FC12 for ; Sun, 25 Mar 2012 19:21:17 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so5783161pbc.13 for ; Sun, 25 Mar 2012 12:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EIFr82ngXGXkZ6J46XZjfj4pmt1y2Gd8v/mlRJ5f6Vw=; b=O7jFn3ZLmLV0L5WghZEl1Jh0mr9LpRouCzKyV15apXBDvOP92gU/hRzO73MDvfnMld Ozu6RFopcTu00d3OxV0h3K/suzLiepvoljOX4VfcqN4hcKOCyMcni9vK8YIYsSLNnE30 Va0lQ8ur9SOMT61MgQ1ON4t+Nw2mtTKU7LBssXEXU0Zm8rltjhozmn8WhhoMbq0WV/qH EH7QksBQxe+Fmclb7BDH6teOTnlF7Pc6mzM+As9BupKGQY2YDjYwIiggM5mUrOeFNnKp HrmI895vdwChk28dhKPvH0q2jzRVkwTCjMpG6kq3bwkV3iTY3niztGAn6uQ082MfHDFK xUUA== MIME-Version: 1.0 Received: by 10.68.194.199 with SMTP id hy7mr33135396pbc.37.1332703277834; Sun, 25 Mar 2012 12:21:17 -0700 (PDT) Received: by 10.143.33.5 with HTTP; Sun, 25 Mar 2012 12:21:17 -0700 (PDT) In-Reply-To: References: <4f6f67a7.4a0c440a.3941.ffffc865@mx.google.com> Date: Sun, 25 Mar 2012 12:21:17 -0700 Message-ID: From: Adrian Chadd To: Lytochkin Boris Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" Subject: Re: [ath][CURRENT] Triangle-shaped network performance X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 19:21:18 -0000 Hi, Is there power saving enabled on this particular server? Adrian From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 25 19:27:47 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34E0E106566C for ; Sun, 25 Mar 2012 19:27:47 +0000 (UTC) (envelope-from lytboris@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B11328FC14 for ; Sun, 25 Mar 2012 19:27:46 +0000 (UTC) Received: by wern13 with SMTP id n13so5000028wer.13 for ; Sun, 25 Mar 2012 12:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0XNSTGNo/afRPEabgaj5JdhQ8ciuh9MwJ4YK0kttNq8=; b=Jd2Xn86AJ5PVr9QIw/GrGGYBumpT4OyKFbmxA1QTZcbwIZM7vzffXarML034oihGf9 P30C8C04C0WIKXsGtcQBt0AJWGLIJh2Ph9swFav2XPmmHyxfwODuHlDroFqvZDC2x3/b 8Xf8VnTof8SRYCQMXwO1b/ghNdZiMdQHA0pEchh3ukt/Xhhea93nuyghCeQnwXhABrFD nyndfxsUYFcjjJxvxYiwLlEw01/UZVjbGwvIU2lXxthMnh+aZTVJrNypuSjW4wMxwxyB 4DGKOVSJ095pg3bm6A+0yfmSM7fnRHsPln5i9f1SfFc70zN5CCsD4eXh+LOMYCUcUql4 qk8g== MIME-Version: 1.0 Received: by 10.180.104.65 with SMTP id gc1mr12664006wib.13.1332703665656; Sun, 25 Mar 2012 12:27:45 -0700 (PDT) Received: by 10.223.72.6 with HTTP; Sun, 25 Mar 2012 12:27:45 -0700 (PDT) In-Reply-To: References: <4f6f67a7.4a0c440a.3941.ffffc865@mx.google.com> Date: Sun, 25 Mar 2012 23:27:45 +0400 Message-ID: From: Lytochkin Boris To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" Subject: Re: [ath][CURRENT] Triangle-shaped network performance X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 19:27:47 -0000 On Sun, Mar 25, 2012 at 11:21 PM, Adrian Chadd wrote: > Hi, > > Is there power saving enabled on this particular server? powerd is shut down, la is around zero. Are there any other power savings I forgot about? There was no problem on RELENG_8 and 802.11g with powerd enabled (though ath card was different). That server is an old laptop :) Some more facts: ping triangles for two laptops connected to server are not synchronized and roll-over independently. ps Adrian, sorry for re-posting. -- Boris Lytochkin From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 25 19:34:57 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E93E1065673 for ; Sun, 25 Mar 2012 19:34:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5E11B8FC15 for ; Sun, 25 Mar 2012 19:34:57 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so5796449pbc.13 for ; Sun, 25 Mar 2012 12:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yNswl1c734IXBleYtnF8SHeUfagV7o8IcqCnSGYO0UM=; b=n3V9YpV0IHbp/AvIXlUUp/76nEMbMr4aiuro/n5r00D9tGvI8yg8Psfz7J1O5cacWh YLHOgwfeCLScmWjyBkZuGCYoyBLLHYqij5JwA4flW7w9RtOX79Nse1xTsDg37ku1EhmO Qpxtyn94LNDI6jHraENNIKw20cFbXUAyeR4JXeeznIw6Ao11A1rIuI8fxSYHii1kF+f4 j4rDyEvpdUjxL79yI5VX463Ff2HtfPqIFKyFNCGpIw//gcsso+x4GOaNFh8uBcMDb355 8PVN2PNG/7gJzUGrQLkklTiZ1EtUxIt2JqQVlmxr3UQV3pj4IG7+3HhUyzFsVzauZSA9 wizQ== MIME-Version: 1.0 Received: by 10.68.234.195 with SMTP id ug3mr48126699pbc.4.1332704096960; Sun, 25 Mar 2012 12:34:56 -0700 (PDT) Received: by 10.143.33.5 with HTTP; Sun, 25 Mar 2012 12:34:56 -0700 (PDT) In-Reply-To: References: <4f6f67a7.4a0c440a.3941.ffffc865@mx.google.com> Date: Sun, 25 Mar 2012 12:34:56 -0700 Message-ID: From: Adrian Chadd To: Lytochkin Boris Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-wireless@freebsd.org" Subject: Re: [ath][CURRENT] Triangle-shaped network performance X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 19:34:57 -0000 On 25 March 2012 12:27, Lytochkin Boris wrote: > On Sun, Mar 25, 2012 at 11:21 PM, Adrian Chadd w= rote: >> Hi, >> >> Is there power saving enabled on this particular server? > > powerd is shut down, la is around zero. Are there any other power > =A0savings I forgot about? There was no problem on RELENG_8 and 802.11g > =A0with powerd enabled (though ath card was different). > =A0That server is an old laptop :) > > =A0Some more facts: ping triangles for two laptops connected to server > =A0are not synchronized and roll-over independently. From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 25 19:36:28 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F879106566C for ; Sun, 25 Mar 2012 19:36:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id E32AC8FC12 for ; Sun, 25 Mar 2012 19:36:27 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so5797950pbc.13 for ; Sun, 25 Mar 2012 12:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HNus1jgsIvPtaO+4ucTJ2tHwzzE9/HU9gRkURzIITwk=; b=pIGM/rB/4p/s+q6zsSMHUOvoo6j0Pg9iOn7Vt5S9fRfxf6EQuz4j36HVe44nYf/NU2 gpw068cSzgSHQ0nsnzkhDz8lVcpeei3jhHxg5ji79AeFjng4HVHEZr9rwV+BEEejqNTo Rsn1drheLLq5q+DSkAd27OMAsevlDcMXhJ5TKOakn7PmYl43rDru1FdCK0pjvNu2j/1G gNBP74WDZ7eNW+lCOzM00sgwEkg0W2Me1g3ZA+Wk+ONZEQa4baW8i9qf8OHBnJwwDsE5 R+InjfjzIdugrF5iMhezC+QAsyoC103v6wYl7fwTw0QXMnynPaeVA9syqAgrefKzjnoK 3ePA== MIME-Version: 1.0 Received: by 10.68.195.38 with SMTP id ib6mr35448128pbc.28.1332704187704; Sun, 25 Mar 2012 12:36:27 -0700 (PDT) Received: by 10.143.33.5 with HTTP; Sun, 25 Mar 2012 12:36:27 -0700 (PDT) In-Reply-To: References: <4f6f67a7.4a0c440a.3941.ffffc865@mx.google.com> Date: Sun, 25 Mar 2012 12:36:27 -0700 Message-ID: From: Adrian Chadd To: Lytochkin Boris Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-wireless@freebsd.org" Subject: Re: [ath][CURRENT] Triangle-shaped network performance X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 19:36:28 -0000 On 25 March 2012 12:27, Lytochkin Boris wrote: > powerd is shut down, la is around zero. Are there any other power > =A0savings I forgot about? There was no problem on RELENG_8 and 802.11g > =A0with powerd enabled (though ath card was different). > =A0That server is an old laptop :) Well, you changed both the OS _and_ the NIC. How are we supposed to debug this? :-) > =A0Some more facts: ping triangles for two laptops connected to server > =A0are not synchronized and roll-over independently. I still don't know what's causing this. Try running athstats a little more and try to correlate changes in latency with changes in the output of athstats. Adrian From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 25 19:51:43 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C084106564A for ; Sun, 25 Mar 2012 19:51:43 +0000 (UTC) (envelope-from lytboris@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id BA08D8FC1D for ; Sun, 25 Mar 2012 19:51:42 +0000 (UTC) Received: by wern13 with SMTP id n13so5010274wer.13 for ; Sun, 25 Mar 2012 12:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=z8Yj0Ok/bIvN+c4lw/vxq3YPezHe11BjT7st4AWJ25Y=; b=OHYS57FD9USZ5qNNQz3XAekGeUFnDjZ/yPQVl2BpJOek04neDMHzhObjQdtw86HiNX zp9MNX/xghA5jZnqLoxI/c5oljtW3y9yM1ZqALQSfo3HJoAXvfvJlkD6avd33RRANat5 ot/bE17yxcvHgDqcllMA/EFqkhxO+QHrLTfQ5oK89YrwmoDeD++8Ew3sPMjok2dY7WDA kjT7RLsPN0W7Z/gD5oIZSrzol3QVgFa7HAdjeXrp3A5Wd9X00375cHBJ1G9EUDK+GKkp /FfcOVvToMo8b4ZxyKt+JsXJv9QupWhtk4LWA+q2VVhEPzF8YuaFiaC64d2WwL1X94H+ vIhg== MIME-Version: 1.0 Received: by 10.180.94.33 with SMTP id cz1mr12846186wib.13.1332705101795; Sun, 25 Mar 2012 12:51:41 -0700 (PDT) Received: by 10.223.72.6 with HTTP; Sun, 25 Mar 2012 12:51:41 -0700 (PDT) In-Reply-To: References: <4f6f67a7.4a0c440a.3941.ffffc865@mx.google.com> Date: Sun, 25 Mar 2012 23:51:41 +0400 Message-ID: From: Lytochkin Boris To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-wireless@freebsd.org" Subject: Re: [ath][CURRENT] Triangle-shaped network performance X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 19:51:43 -0000 On Sun, Mar 25, 2012 at 11:36 PM, Adrian Chadd wro= te: > Well, you changed both the OS _and_ the NIC. How are we supposed to > debug this? :-) Let's forget about past :) I would have to change my OS back unless this madness is fixed :( > >> =A0Some more facts: ping triangles for two laptops connected to server >> =A0are not synchronized and roll-over independently. > > I still don't know what's causing this. Try running athstats a little > more and try to correlate changes in latency with changes in the > output of athstats. Here it is. Transfer initiation (you can see when it boosts): >athstats 1 input output altrate short long xretry crcerr crypt phyerr rssi = rate 608153 1085770 74 0 30727 2591 2749 0 0 62 = MCS11 4 3 0 0 0 0 0 0 0 62 = MCS11 7 4 0 0 0 0 0 0 0 62 MCS11 <--- transfer initiated 4 5 0 0 0 0 0 0 0 61 = MCS11 4 4 0 0 0 0 0 0 0 62 = MCS11 7 8 0 0 0 0 0 0 0 59 = MCS15 9 8 0 0 14 3 0 0 0 54 = 48M 6 6 0 0 4 1 0 0 0 57 = 36M 21 17 0 0 78 15 0 0 0 54 = MCS11 8 6 0 0 0 0 0 0 0 55 = 36M 10 6 0 0 0 0 0 0 0 50 = 36M 12 8 0 0 0 0 0 0 0 59 = 36M 10 13 0 0 0 0 0 0 0 58 = 36M 7 8 0 0 1 0 0 0 0 60 = 36M 6 6 0 0 0 0 0 0 0 61 = 36M 5 5 0 0 0 0 0 0 0 61 = 36M 6 8 0 0 1 0 0 0 0 61 = 36M 8 7 0 0 1 0 0 0 0 59 = 54M 12 28 0 0 0 0 0 0 0 61 = 36M 26 31 0 0 5 0 0 0 0 57 = 36M 6 10 0 0 0 0 0 0 0 59 = 36M input output altrate short long xretry crcerr crypt phyerr rssi = rate 608336 1085966 74 0 30831 2610 2749 0 0 60 = 36M 6 6 0 0 0 0 0 0 0 65 = 36M 22 53 0 0 0 0 0 0 0 61 = 36M 28 48 0 0 0 0 0 0 0 61 = 36M 28 48 0 0 1 0 0 0 0 59 = 12M 28 49 0 0 8 0 0 0 0 59 = MCS12 30 49 0 0 2 0 0 0 0 62 = MCS12 29 49 0 0 5 0 0 0 0 59 = MCS12 24 39 0 0 1 0 0 0 0 60 = MCS12 33 45 0 0 1 0 0 0 0 58 = MCS12 31 52 0 0 3 0 0 0 0 59 = MCS11 32 52 0 0 2 0 0 0 0 66 = MCS11 28 51 0 0 1 0 0 0 0 59 = MCS11 29 50 0 0 3 0 0 0 0 60 = MCS12 28 53 0 0 3 0 0 0 0 57 = MCS11 28 50 0 0 1 0 0 0 0 60 = MCS12 37 56 0 0 3 0 0 0 0 58 = MCS11 36 50 0 0 0 0 0 0 0 63 = MCS11 31 55 0 0 2 0 0 0 0 65 = MCS11 31 54 0 0 3 0 0 0 0 62 = MCS12 35 51 0 0 3 0 0 0 0 60 = MCS12 input output altrate short long xretry crcerr crypt phyerr rssi = rate 608941 1086977 74 0 30875 2610 2749 0 0 59 = MCS11 29 52 0 0 1 0 0 0 0 62 = MCS12 28 50 0 0 3 0 0 0 0 61 = MCS12 28 50 0 0 0 0 0 0 0 62 = MCS11 32 58 0 0 7 0 0 0 0 57 = MCS12 40 55 0 0 2 0 0 0 0 62 = MCS12 30 56 0 0 2 0 0 0 0 63 = MCS12 35 60 0 0 1 0 0 0 0 64 = MCS12 32 57 0 0 1 0 0 0 0 63 = MCS12 29 52 0 0 1 0 0 0 0 61 = MCS12 17 31 0 0 0 0 0 0 0 62 = 36M 33 53 0 0 3 0 0 0 0 63 = 18M 30 50 0 0 2 0 0 0 0 64 = 36M 31 50 0 0 2 0 0 0 0 63 = 36M 28 50 0 0 4 0 0 0 0 62 = 36M 29 52 0 0 3 0 0 0 0 62 = 36M 29 52 0 0 3 0 0 0 0 62 = 36M 37 55 0 0 2 0 0 0 0 56 = MCS11 30 54 0 0 3 0 0 0 0 60 = 36M 31 53 0 0 4 0 0 0 0 60 = 36M 36 55 0 0 1 0 0 0 0 63 = 36M input output altrate short long xretry crcerr crypt phyerr rssi = rate 609586 1088075 74 0 30923 2610 2749 0 0 54 = 36M 30 53 0 0 2 0 0 0 0 56 = 24M 34 56 0 0 3 0 0 0 0 51 = 36M 33 54 0 0 25 5 0 0 0 64 = 36M 32 53 0 0 2 0 0 0 0 54 = 36M 35 52 0 0 4 0 0 0 0 59 = MCS15 30 50 0 0 2 0 0 0 0 60 = MCS15 30 54 0 0 5 0 0 0 0 53 = MCS15 34 55 0 0 3 0 0 0 0 63 = MCS15 518 981 0 0 11 0 0 0 0 44 = MCS15 1398 2659 1 0 29 0 0 0 0 20 = MCS15 3051 5716 1 0 64 0 2 0 0 24 = MCS15 661 1210 1 0 43 3 0 0 0 27 = MCS15 563 1024 0 0 128 11 0 0 0 32 = MCS15 25 39 0 0 0 0 0 0 0 38 = MCS12 5 10 0 0 1 0 0 0 0 47 = 36M 7 10 0 0 0 0 0 0 0 49 = MCS12 8 6 0 0 0 0 0 0 0 56 = MCS11 63 26 0 0 1 0 0 0 0 44 = MCS11 1586 3000 0 0 37 0 0 0 0 20 = MCS12 2210 4150 0 0 61 0 0 0 0 15 = MCS12 input output altrate short long xretry crcerr crypt phyerr rssi = rate 622148 1111497 78 0 31400 2629 2751 0 0 22 = MCS12 2203 4145 0 0 63 2 0 0 0 23 = MCS12 2144 4022 0 0 64 2 0 0 0 23 = MCS12 2222 4169 0 0 45 0 0 0 0 18 = MCS12 2270 4245 0 0 45 0 0 0 0 27 = MCS12 2227 4150 0 0 62 0 0 0 0 25 = MCS12 2200 4120 0 0 56 0 0 0 0 27 = MCS12 2189 4122 0 0 59 0 0 0 0 21 = MCS12 2195 4136 0 0 57 0 0 0 0 24 = MCS12 2205 4146 0 0 55 0 0 0 0 23 = MCS12 2225 4187 0 0 63 0 2 0 0 31 = MCS12 2192 4114 0 0 48 0 0 0 0 26 = MCS12 2206 4150 0 0 47 0 1 0 0 30 = MCS12 Transfer abortion: 1551 2931 1 0 58 1 4 0 0 28 = MCS12 1657 3111 0 0 29 0 0 0 0 29 = MCS12 1361 2576 0 0 19 0 0 0 0 30 = MCS12 1564 2962 0 0 24 0 0 0 0 31 = MCS12 input output altrate short long xretry crcerr crypt phyerr rssi = rate 840750 1522646 89 0 36373 2664 2834 0 0 21 = MCS12 1623 3030 0 0 38 0 0 0 0 30 = MCS12 1497 2827 0 0 37 0 5 0 0 42 = MCS12 1450 2749 0 0 31 0 0 0 0 36 = MCS12 1381 2576 1 0 41 1 0 0 0 28 MCS12 <-- stop transfer, pings still are ok 119 201 0 0 11 1 0 0 0 47 = 1M 10 9 0 0 0 0 0 0 0 53 = 54M 5 4 0 0 0 0 0 0 0 56 = 54M 21 18 0 0 1 0 0 0 0 59 = MCS15 5 3 0 0 0 0 0 0 0 58 = 54M 6 4 0 0 0 0 0 0 0 59 = 54M 13 13 0 0 0 0 0 0 0 54 = 54M 8 8 0 0 8 2 0 0 0 56 = 54M 3 3 0 0 0 0 0 0 0 57 = 54M 5 5 0 0 0 0 0 0 0 58 = 54M 8 7 0 0 1 0 0 0 0 59 = 54M 8 6 0 0 0 0 0 0 0 60 = 54M 3 3 0 0 0 0 0 0 0 60 = 54M 6 6 0 0 1 0 0 0 0 60 = MCS15 3 3 0 0 0 0 0 0 0 61 = 54M 7 7 0 0 0 0 0 0 0 62 = 54M input output altrate short long xretry crcerr crypt phyerr rssi = rate 846937 1534134 90 0 36542 2668 2839 0 0 62 = MCS15 5 5 0 0 0 0 0 0 0 62 = MCS15 6 5 0 0 0 0 0 0 0 62 = MCS15 6 6 0 0 0 0 0 0 0 62 MCS12 <-- ping triangles start 7 6 0 0 0 0 0 0 0 62 = MCS15 6 9 0 0 1 0 0 0 0 66 = MCS12 11 8 0 0 0 0 0 0 0 62 = 48M --=20 Boris Lytochkin From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 25 20:37:06 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DB66106566C for ; Sun, 25 Mar 2012 20:37:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5BC5E8FC22 for ; Sun, 25 Mar 2012 20:37:06 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so5856732pbc.13 for ; Sun, 25 Mar 2012 13:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TwbB9xoorRYhKBl6y/QA6U2tBiSRkY6CB2p7cnHu1Kc=; b=GWrYeanZdCPXeyZtkSlT73xif+xp0XOV+KUfJC11WLsS6BPlN9AaoyoKiS0BUogTu2 M/SJtwcf58hyOhs1CAfX7FlqJSCpByuuUaJI8+vNOnQOCuOuVQatauoOJy43wORaA0Y0 HP/xZEXHvV0IJ85Gz/+nTC8eHiukU4f7gFAHhC9LJQWt6yW2rtSiXUIa/ABTNBNv0E8C WTTr9iOokCre5GRXtYYa0RQfrwPsTYKmeuvEt/82f8oF/90JSdFoLZaw8kxsP/cVGjtK UIwzddhYx78PbQ5/6JuVM23BNrnB8RqH+tNilo8VwvQ6eLjh73XWp7MY5+wG2xMjtX6b jtYQ== MIME-Version: 1.0 Received: by 10.68.212.228 with SMTP id nn4mr33475242pbc.68.1332707826211; Sun, 25 Mar 2012 13:37:06 -0700 (PDT) Received: by 10.143.33.5 with HTTP; Sun, 25 Mar 2012 13:37:06 -0700 (PDT) In-Reply-To: References: <4f6f67a7.4a0c440a.3941.ffffc865@mx.google.com> Date: Sun, 25 Mar 2012 13:37:06 -0700 Message-ID: From: Adrian Chadd To: Lytochkin Boris Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" Subject: Re: [ath][CURRENT] Triangle-shaped network performance X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 20:37:06 -0000 Hi, 'athstats 1' only displays a small subset of possible things. try say, athstats -o input,output,cck,ofdm 1 Adrian From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 25 20:41:51 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0AEB0106567B for ; Sun, 25 Mar 2012 20:41:51 +0000 (UTC) (envelope-from lytboris@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3018FC2F for ; Sun, 25 Mar 2012 20:41:50 +0000 (UTC) Received: by wern13 with SMTP id n13so5031296wer.13 for ; Sun, 25 Mar 2012 13:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hDyQSMOA4JrzVJxhnRmF6G4wKFlMAVunF9QttczcJSM=; b=ddq9BJdykC7oYoj/5mFB22vE3TtzGXOEPm5LLcqVwCZ6KpMQIKwZOn2bFMIihCmwsJ mYdoLOz1EbAkNOTYaDMaHXNx3C4l83OeF+mFhNveEmjQvDOwRAtAz1zwu4aIuk9lyWoE WOc7FaCFNfy8DtJXTwlXwATkQDojp03teZykvTBdh2ZMbFSel2eAnfnlffrbWnebgKbH g9gwuoHK13K0nNXdVBSDdj69t2toV6EbQjhONpXtkOXBnVlQWKXL3sp13H5EO5P3TCQu kTvLDgxTKCs0GoSTzR00ArwskIizLsPxNPmDJg8oZwtZ4RJPWIwyHrGXH9zNSH9lrkTH iFsw== MIME-Version: 1.0 Received: by 10.216.144.138 with SMTP id n10mr10990089wej.56.1332708109674; Sun, 25 Mar 2012 13:41:49 -0700 (PDT) Received: by 10.223.72.6 with HTTP; Sun, 25 Mar 2012 13:41:49 -0700 (PDT) In-Reply-To: References: <4f6f67a7.4a0c440a.3941.ffffc865@mx.google.com> Date: Mon, 26 Mar 2012 00:41:49 +0400 Message-ID: From: Lytochkin Boris To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" Subject: Re: [ath][CURRENT] Triangle-shaped network performance X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 20:41:51 -0000 It seems I found a solution, but not the problem :) Reverting bintval to it's default value (1000 -> 100) helped a lot: triangle-shaped ping disappeared. I wonder why that ever happen. The last thing to fix is idle pings. They are not so good: ~50ms (1ms while in transfer). -- Boris Lytochkin From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 25 20:47:54 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD7AD106566B for ; Sun, 25 Mar 2012 20:47:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8A9E78FC15 for ; Sun, 25 Mar 2012 20:47:54 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so5866937pbc.13 for ; Sun, 25 Mar 2012 13:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9GLAtK5unvjLLHJ+xF5iIaHEAuivm4GwAXao82TC1rw=; b=StbSwa7NqduCoU6QfWje0AnoXYlbc5DLTbC0d2/2tHtoyprSXng0DG5k1Fk1rgCSqd DPxT6NDjU1732Q9uZwNmgp8iAd3tcIxrIL5rYAnqoBDASlCgM+hEr0s8MacWZDAkbcDL O/uZylwYOyfrJw393c4jN3EF11geJ79On5C7HCVKeT5E3TtySr0Qc+NmTIX58wn0ANrL J+djFsxYRIGmJXR6/uew3WbwQ6GmethjBYRWjWBy4KR4nFHlsvDM2IhVSMiZFWj6VTMy tO5Vn9jvFBj4NZZMNtV9Qj7A9QZDOqa+tAVT6z4Qe8pKi556tyDEv7Rd2DS9pM/mpNcM 8/GQ== MIME-Version: 1.0 Received: by 10.68.240.135 with SMTP id wa7mr47372552pbc.7.1332708474351; Sun, 25 Mar 2012 13:47:54 -0700 (PDT) Received: by 10.143.33.5 with HTTP; Sun, 25 Mar 2012 13:47:54 -0700 (PDT) In-Reply-To: References: <4f6f67a7.4a0c440a.3941.ffffc865@mx.google.com> Date: Sun, 25 Mar 2012 13:47:54 -0700 Message-ID: From: Adrian Chadd To: Lytochkin Boris Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" Subject: Re: [ath][CURRENT] Triangle-shaped network performance X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 20:47:54 -0000 do you have a lot of broadcast traffic on your network? adrian From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 25 21:05:40 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2B6B106564A for ; Sun, 25 Mar 2012 21:05:40 +0000 (UTC) (envelope-from lytboris@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 2E0318FC1E for ; Sun, 25 Mar 2012 21:05:39 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so3054967wib.13 for ; Sun, 25 Mar 2012 14:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xpPcAzmqab5VNGI2PEpoezvsksOCZR4vcya0j3DKb9U=; b=JXr3Ei50Q3MbfXx9PTAYMkrlAzdowxCLvB6UcFtMEzOqscejYFOaoUT7kIgORtYRd8 qKyr+2OrY7XkrqAj5g/Zc4PkLAVi53XGCpVCDaGmpZAi03H3Z/w4MYbjT876n6a6fsIH XI2f58r04JOUSlGO3TvGiEXFxflTIzw8ibt/Iu54+nMaXcE72Kx8M7GO1IDCrVNYB4te Aa4EjHXUTvbbAOnnkv6rcP1Sdo9t+ZFANksX1YyxKThy6kYwmlK9XaogrSShT0/BuhN3 3+CBcd2u6KQlqFSMC/soxs8rlrR9IozeLFTmEbuBCFkb8M4B2RxhCbZyuGuTH+KXfZWd lJnQ== MIME-Version: 1.0 Received: by 10.180.94.33 with SMTP id cz1mr13153339wib.13.1332709539295; Sun, 25 Mar 2012 14:05:39 -0700 (PDT) Received: by 10.223.72.6 with HTTP; Sun, 25 Mar 2012 14:05:39 -0700 (PDT) In-Reply-To: References: <4f6f67a7.4a0c440a.3941.ffffc865@mx.google.com> Date: Mon, 26 Mar 2012 01:05:39 +0400 Message-ID: From: Lytochkin Boris To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" Subject: Re: [ath][CURRENT] Triangle-shaped network performance X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 21:05:40 -0000 On Mon, Mar 26, 2012 at 12:47 AM, Adrian Chadd wrote: > do you have a lot of broadcast traffic on your network? I whould say none: ~>time tcpdump -nli wlan0 not ether host b0:48:7a:da:0e:59 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes 01:04:00.046877 ARP, Request who-has 192.168.2.1 tell 192.168.2.101, length 28 01:04:00.046911 ARP, Request who-has 192.168.2.1 tell 192.168.2.101, length 28 ^C 2 packets captured 174 packets received by filter 0 packets dropped by kernel tcpdump -nli wlan0 not ether host b0:48:7a:da:0e:59 0.00s user 0.25s system 1% cpu 21.292 total -- Boris Lytochkin From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 25 21:50:30 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7473106566C for ; Sun, 25 Mar 2012 21:50:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A3F978FC15 for ; Sun, 25 Mar 2012 21:50:30 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so5927995pbc.13 for ; Sun, 25 Mar 2012 14:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Khd/0FmrQpk+a3UjkWVr0LJPjTxLzxjOd/mmJF+Vz0o=; b=kMLLO39C00Gr+yTIAnFckLPddTwd1dS0k+8LLmi5pZ5Ybsmyvi4KcWmKuZdhBM7IHp 4ASF6DbdVtUc+pi9ezOKCtofEq6Ig/jESo6RXiPrUXRMtVNIgJEY7TBIu9rXmZnvwPfK w0QaCrqg4lgERE1MLVOAfZ5wx3G0LD3+bOX0uiEDGCXUeYnxq5rgYl1e2yrRJfn538KN kbKemDHiEANSzcxgfpNttVEfyBLycFmiJNzZ6tOab6SKhM920USRPIojIGPURJZJKHLL uSBUUWR4vZjM4CLSa0GdkWQRY1mF/+b4banhkKwYdZlrnOCEkPckKuWksasRIehgrEU/ sS6Q== MIME-Version: 1.0 Received: by 10.68.225.104 with SMTP id rj8mr47539544pbc.135.1332712230235; Sun, 25 Mar 2012 14:50:30 -0700 (PDT) Received: by 10.143.33.5 with HTTP; Sun, 25 Mar 2012 14:50:30 -0700 (PDT) In-Reply-To: References: <4f6f67a7.4a0c440a.3941.ffffc865@mx.google.com> Date: Sun, 25 Mar 2012 14:50:30 -0700 Message-ID: From: Adrian Chadd To: Lytochkin Boris Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" Subject: Re: [ath][CURRENT] Triangle-shaped network performance X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 21:50:30 -0000 On 25 March 2012 13:41, Lytochkin Boris wrote: > It seems I found a solution, but not the problem :) Why oh why did you set.. > Reverting bintval to it's default value (1000 -> 100) helped a lot: Why'd you do this? 10 beacons a second is fine. 100 beacons a second ? > triangle-shaped ping disappeared. I wonder why that ever happen. > The last thing to fix is idle pings. They are not so good: ~50ms (1ms > while in transfer). That almost feels like some weird interrupt handling issue. Adrian From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 26 00:00:25 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7926F106566C for ; Mon, 26 Mar 2012 00:00:25 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3D62B8FC1A for ; Mon, 26 Mar 2012 00:00:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2Q00PeO063391 for ; Mon, 26 Mar 2012 00:00:25 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2Q00PRi063390; Mon, 26 Mar 2012 00:00:25 GMT (envelope-from gnats) Date: Mon, 26 Mar 2012 00:00:25 GMT Message-Id: <201203260000.q2Q00PRi063390@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/166357: commit references a PR X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 00:00:25 -0000 The following reply was made to PR kern/166357; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/166357: commit references a PR Date: Sun, 25 Mar 2012 23:50:44 +0000 (UTC) Author: adrian Date: Sun Mar 25 23:50:34 2012 New Revision: 233480 URL: http://svn.freebsd.org/changeset/base/233480 Log: Add some more debugging to try and nail down exactly what's going on when I see traffic stalls. It turns out that the bug isn't because the first and last frame in the BAW is in the software queue. It is more likely that it's because the first frame in the BAW is still in the software queue and thus there's no more room to allocate and do subsequent TX. PR: kern/166357 Modified: head/sys/dev/ath/if_ath_tx.c Modified: head/sys/dev/ath/if_ath_tx.c ============================================================================== --- head/sys/dev/ath/if_ath_tx.c Sun Mar 25 21:54:36 2012 (r233479) +++ head/sys/dev/ath/if_ath_tx.c Sun Mar 25 23:50:34 2012 (r233480) @@ -2357,6 +2357,7 @@ ath_tx_xmit_aggr(struct ath_softc *sc, s /* paused? queue */ if (tid->paused) { ATH_TXQ_INSERT_TAIL(tid, bf, bf_list); + /* XXX don't sched - we're paused! */ return; } @@ -2647,13 +2648,19 @@ ath_tx_tid_drain(struct ath_softc *sc, s if (t == 0) { device_printf(sc->sc_dev, "%s: node %p: bf=%p: addbaw=%d, dobaw=%d, " - "seqno_assign=%d, seqno_required=%d, seqno=%d\n", + "seqno_assign=%d, seqno_required=%d, seqno=%d, retry=%d\n", __func__, ni, bf, bf->bf_state.bfs_addedbaw, bf->bf_state.bfs_dobaw, bf->bf_state.bfs_need_seqno, bf->bf_state.bfs_seqno_assigned, - SEQNO(bf->bf_state.bfs_seqno)); + SEQNO(bf->bf_state.bfs_seqno), + bf->bf_state.bfs_retries); + device_printf(sc->sc_dev, + "%s: node %p: bf=%p: tid txq_depth=%d hwq_depth=%d\n", + __func__, ni, bf, + tid->axq_depth, + tid->hwq_depth); device_printf(sc->sc_dev, "%s: node %p: bf=%p: tid %d: txq_depth=%d, " "txq_aggr_depth=%d, sched=%d, paused=%d, " _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 26 06:03:54 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 15148106566C for ; Mon, 26 Mar 2012 06:03:54 +0000 (UTC) (envelope-from lytboris@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 8FE358FC0A for ; Mon, 26 Mar 2012 06:03:52 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so3234916wib.13 for ; Sun, 25 Mar 2012 23:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l/RrZ9AyB1xeHqdpzYe+c+BrlsvA0P3B3FYfaA/ftRU=; b=g5xH5PAFTC+uXJ3FENTRonsBux1CjSJ2utUHwW5FjjHXOfa3ZvyNkuT/2WC893E608 wZ1jcJGRS6dwoqAPHpgRCOwZ1XtLGPt5blZS/i4MRTV6fhS92MhvSRCdrkDDIR13ckyY 13ihb8QSAn5pO2v+yIVzu9Duyu4D74M45haZC9Hbl6ybErCgic+J8s/AS1G33MkoUbNJ O9y//ip0tRfnpYMn8p/YSocF3Bh1O9ZMVMBB/8/Gn5VC9XqmChHb8zAbvPZPAd8uQ2TQ 1lJoUOuKL75WRB/ivftTbdtK9+ppZJ7e6WAwGNqSkdBm7+28RF75aOFG3QneJmcMz28Q MqAA== MIME-Version: 1.0 Received: by 10.180.94.33 with SMTP id cz1mr15653379wib.13.1332741831810; Sun, 25 Mar 2012 23:03:51 -0700 (PDT) Received: by 10.223.72.6 with HTTP; Sun, 25 Mar 2012 23:03:51 -0700 (PDT) In-Reply-To: References: <4f6f67a7.4a0c440a.3941.ffffc865@mx.google.com> Date: Mon, 26 Mar 2012 10:03:51 +0400 Message-ID: From: Lytochkin Boris To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" Subject: Re: [ath][CURRENT] Triangle-shaped network performance X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 06:03:54 -0000 On Mon, Mar 26, 2012 at 1:50 AM, Adrian Chadd wrote: > On 25 March 2012 13:41, Lytochkin Boris wrote: >> It seems I found a solution, but not the problem :) > > Why oh why did you set.. > >> Reverting bintval to it's default value (1000 -> 100) helped a lot: > > Why'd you do this? > > 10 beacons a second is fine. 100 beacons a second ? bintval = 1000 is 1 beacon per second. Actually I was sure that Cisco AP have this setting at 3k. >> triangle-shaped ping disappeared. I wonder why that ever happen. >> The last thing to fix is idle pings. They are not so good: ~50ms (1ms >> while in transfer). > > That almost feels like some weird interrupt handling issue. Any ideas how to proove this theory? -- Boris Lytochkin From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 26 10:05:18 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 688AD1065673 for ; Mon, 26 Mar 2012 10:05:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1AB5A8FC12 for ; Mon, 26 Mar 2012 10:05:18 +0000 (UTC) Received: by ghrr20 with SMTP id r20so4413016ghr.13 for ; Mon, 26 Mar 2012 03:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SozEXD0jQ6stcjUU4aejPT9o0GnQcbPN5YaHHqYIycA=; b=nkJmVpru8hPmmQHqqL78edEHV6gRsIU1q6iNweArbQ/swK3TFv6q8vPmQEdHhwBmr2 jQyhEf3Bq8qOz/h+Gxb4KWdZNl9eCnu1V34XsFVlOYzf4igfgfiBOFfHQ1zmw4IpVP/4 Dd7mHF7lvkzltRMf2t12DTFfVTLlG/TkZoNprR2zROG8VBFgCUJUuN+NPHa1BvSbSLVS f2WVm7jOHLiAiwxjIckbEYCo4kwE5HjVMI4Dphu/r/mIynwvX0/SZ/6qzKcdBMsYUjU9 UXTkK2eH/Gz+ISEIccKBG0mXFD1m3BmykN/j/U84aAqz6PL9L6wqjTKowA1BCBWJV1+k awpg== MIME-Version: 1.0 Received: by 10.68.212.228 with SMTP id nn4mr37985535pbc.68.1332756317284; Mon, 26 Mar 2012 03:05:17 -0700 (PDT) Received: by 10.143.33.5 with HTTP; Mon, 26 Mar 2012 03:05:17 -0700 (PDT) In-Reply-To: References: <4f6f67a7.4a0c440a.3941.ffffc865@mx.google.com> Date: Mon, 26 Mar 2012 03:05:17 -0700 Message-ID: From: Adrian Chadd To: Lytochkin Boris Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" Subject: Re: [ath][CURRENT] Triangle-shaped network performance X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 10:05:18 -0000 On 25 March 2012 23:03, Lytochkin Boris wrote: >> 10 beacons a second is fine. 100 beacons a second ? > bintval = 1000 is 1 beacon per second. Actually I was sure that Cisco > AP have this setting at 3k. Hm. Weird. 1 a second seems a bit infrequent. I'm not sure what/why this is a problem. I haven't really thought about it.. :) >> That almost feels like some weird interrupt handling issue. > Any ideas how to proove this theory? Not immediately, no. I'd start by enabling interrupt debugging and see how often RX/TX completion interrupts are coming in. Adrian From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 26 11:07:18 2012 Return-Path: Delivered-To: freebsd-wireless@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D3AC106564A for ; Mon, 26 Mar 2012 11:07:18 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 072828FC29 for ; Mon, 26 Mar 2012 11:07:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2QB7HYh018455 for ; Mon, 26 Mar 2012 11:07:17 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2QB7HWh018453 for freebsd-wireless@FreeBSD.org; Mon, 26 Mar 2012 11:07:17 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Mar 2012 11:07:17 GMT Message-Id: <201203261107.q2QB7HWh018453@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-wireless@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-wireless@FreeBSD.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 11:07:18 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/166357 wireless [ath] 802.11n TX stall when the first _AND_ last frame o kern/166286 wireless [net80211] [ath] initial switch to HT40 isn't causing o kern/166190 wireless [ath] TX hangs and frames stuck in TX queue o kern/166086 wireless [Patch][ath] Reflect state of rfkill switch in a sysct o kern/165969 wireless [ath] Slower performance in adhoc mode vs Client/AP mo o kern/165966 wireless [ath] ath0: device timeout on SMP machines due to race o kern/165895 wireless [ath] overly busy cabq can tie up all tx buffers o kern/165870 wireless [bwn] bwn driver does not attach on HP Pavilion dv9420 o kern/165866 wireless [ath] TX hangs, requiring a "scan" to properly reset t o kern/165849 wireless [ath] [hang] network ath driver freeze o kern/165595 wireless [ipw] ipw(4): Can't load firmare for ipw2200bg o kern/165543 wireless [ath] ath0 endless scanning of channels without connec o kern/165517 wireless [net80211] bgscan isn't triggered when invalid beacons o kern/165475 wireless [ath] operational mode change doesn't poke the underly o kern/165382 wireless [kernel] taskqueue_unblock doesn't unblock currently q o kern/165306 wireless [ath] race conditions between scanning and beacon time o kern/165220 wireless [ath] "ath_rx_tasklet: sc_inreset_cnt > 0; skipping" m o kern/165214 wireless [ieee80211] Kernel panic in ieee80211_output.c:2505 o kern/165212 wireless [ath] No WiFi on Acer Aspire One 751h (Atheros AR5BHB6 o kern/165149 wireless [ath] [net80211] Ping with data length more than iv_fr o kern/165146 wireless [net80211] Net802.11 Fragment number is assigned 1 (sh o kern/165060 wireless [ath] vap->iv_bss race conditions causing crashes insi o kern/165021 wireless [ath] ath device timeout during scan/attach, if wlan_c o kern/164721 wireless [ath] ath device timeouts o kern/164499 wireless [wi] [patch] if_wi needs fix for big endian architectu o kern/164382 wireless [ath] crash when down/deleting a vap - inside ieee8021 o kern/164365 wireless [iwi] iwi0: UP/DOWN in o bin/164102 wireless hostapd not configured for 802.11n o kern/163759 wireless [ath] ath(4) "stops working" in hostap mode o kern/163724 wireless [mwl] [patch] NULL check before dereference o kern/163719 wireless [ath] ath interface do not receive multicast o kern/163689 wireless [ath] TX timeouts when sending probe/mgmt frames durin o kern/163574 wireless [net80211] overly-frequent HT occupancy changes o kern/163573 wireless [ath] hostap mode TX buffer hang o kern/163559 wireless [ath] kernel panic AH_DEBUG o kern/163318 wireless [ath] ath(4) stops working p kern/163312 wireless [panic] [ath driver] kernel panic: page fault with ath o kern/163237 wireless [ath] AR5416 as HostAP. Delays among clients when a cl o kern/163082 wireless [ath] ar9285 diversity fixes o kern/162648 wireless [ath] AR9227 ADC DC calibration failure o kern/162647 wireless [ath] 11n TX aggregation session / TX hang o kern/161293 wireless [iwn] hang at startup when starting network o kern/161035 wireless [ieee80211] Incorrect number describing 11ng MCS rate o kern/160391 wireless [ieee80211] [patch] Panic in mesh mode o kern/160296 wireless [zyd] [panic] 802.11 usb device reboots system on 'ifc o misc/160176 wireless [mips] [panic] Kernel panic on AR7161 platform with AR o kern/157449 wireless [ath] MAC address conflict causes system to freeze o kern/157243 wireless [ath] investigate beacon TX (AP) / RX (STA) when under o kern/156904 wireless [ath] AR9285 antenna diversity algorithm is buggy and o kern/156884 wireless [ath] ath instablity o kern/156327 wireless [bwn] bwn driver causes 20%-50% packet loss o kern/156322 wireless [wpi] no ahdemo support for if_wpi o kern/156321 wireless [ath] ahdemo doesn't work with if_ath o kern/155498 wireless [ral] ral(4) needs to be resynced with OpenBSD's to ga o kern/155100 wireless [ath] ath driver on busy channel: "stuck beacon" p kern/154598 wireless [ath] Atheros 5424/2424 can't connect to WPA network o kern/154567 wireless [ath] ath(4) lot of bad series(0) o kern/154327 wireless [ath] AR5416 in station mode hangs when transmitting f o kern/154284 wireless [ath] Modern ath wifi cards (such as AR9285) have miss o kern/154153 wireless [ath] AR5213 + MIPS + WPA group key packet corruption o kern/153448 wireless [ath] ath networking device loses association after a o kern/152750 wireless [ath] ath0 lot of bad series hwrate o kern/151198 wireless [ath] ath/5416 fails bgscan with "ath0: ath_chan_set: o kern/149786 wireless [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149516 wireless [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 wireless [realtek/atheros]: None of my network card working o kern/148322 wireless [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 wireless [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 wireless [ath] wireless networking stops functioning o kern/145826 wireless [panic] [ath] Unable to configure adhoc mode on ath0/w o kern/144987 wireless [wpi] [panic] injecting packets with wlaninject using o bin/144109 wireless hostapd(8) uses the MAC of the wireless interface, but o conf/143079 wireless hostapd(8) startup missing multi wlan functionality p kern/140567 wireless [ath] [patch] ath is not worked on my notebook PC o kern/140245 wireless [ath] [panic] Kernel panic during network activity on o kern/137592 wireless [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne p bin/137484 wireless [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/136943 wireless [wpi] [lor] wpi0_com_lock / wpi0 o kern/136836 wireless [ath] atheros card stops functioning after about 12 ho o kern/132722 wireless [ath] Wifi ath0 associates fine with AP, but DHCP or I o bin/131549 wireless ifconfig(8) can't clear 'monitor' mode on the wireless o kern/126475 wireless [ath] [panic] ath pcmcia card inevitably panics under o kern/125721 wireless [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 wireless [ath] [panic] ath(4) related panic o kern/125501 wireless [ath] atheros cardbus driver hangs o kern/125332 wireless [ath] [panic] crash under any non-tiny networking unde o kern/124767 wireless [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 wireless [ieee80211] net80211 discards power-save queue packets o docs/120456 wireless ath(4) needs to specify requirement on wlan_scan_sta o kern/119513 wireless [ath] [irq] inserting dlink dwl-g630 wireless card res o kern/116747 wireless [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile f kern/105348 wireless [ath] ath device stopps TX 92 problems total. From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 26 16:10:12 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A723106564A for ; Mon, 26 Mar 2012 16:10:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 05D378FC1B for ; Mon, 26 Mar 2012 16:10:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2QGABuX001885 for ; Mon, 26 Mar 2012 16:10:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2QGABvG001884; Mon, 26 Mar 2012 16:10:11 GMT (envelope-from gnats) Date: Mon, 26 Mar 2012 16:10:11 GMT Message-Id: <201203261610.q2QGABvG001884@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/166357: commit references a PR X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:10:12 -0000 The following reply was made to PR kern/166357; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/166357: commit references a PR Date: Mon, 26 Mar 2012 16:05:38 +0000 (UTC) Author: adrian Date: Mon Mar 26 16:05:19 2012 New Revision: 233514 URL: http://svn.freebsd.org/changeset/base/233514 Log: Use the assigned sequence number when checking if a retried packet is within the BAW. This regression was introduced in ane earlier commit by me to fix the BAW seqno allocation-but-not-insertion-into-BAW race. Since it was only ever using the to-be allocated sequence number, any frame retries with the first frame in the BAW still in the software queue would have constantly failed, as ni_txseqs[tid] would always be outside the BAW. TODO: * Extract out the mostly common code here in the agg and non-agg ADDBA case and stuff it into a single function. PR: kern/166357 Modified: head/sys/dev/ath/if_ath_tx.c head/sys/dev/ath/if_ath_tx_ht.c Modified: head/sys/dev/ath/if_ath_tx.c ============================================================================== --- head/sys/dev/ath/if_ath_tx.c Mon Mar 26 15:38:17 2012 (r233513) +++ head/sys/dev/ath/if_ath_tx.c Mon Mar 26 16:05:19 2012 (r233514) @@ -2348,7 +2348,6 @@ ath_tx_xmit_aggr(struct ath_softc *sc, s struct ath_tid *tid = &an->an_tid[bf->bf_state.bfs_tid]; struct ath_txq *txq = bf->bf_state.bfs_txq; struct ieee80211_tx_ampdu *tap; - int seqno; ATH_TXQ_LOCK_ASSERT(txq); @@ -2384,13 +2383,31 @@ ath_tx_xmit_aggr(struct ath_softc *sc, s * the TIDs that map to it. Ugh. */ if (bf->bf_state.bfs_dobaw) { - if (! BAW_WITHIN(tap->txa_start, tap->txa_wnd, - ni->ni_txseqs[bf->bf_state.bfs_tid])) { + ieee80211_seq seqno; + + /* + * If the sequence number is allocated, use it. + * Otherwise, use the sequence number we WOULD + * allocate. + */ + if (bf->bf_state.bfs_seqno_assigned) + seqno = SEQNO(bf->bf_state.bfs_seqno); + else + seqno = ni->ni_txseqs[bf->bf_state.bfs_tid]; + + /* + * Check whether either the currently allocated + * sequence number _OR_ the to-be allocated + * sequence number is inside the BAW. + */ + if (! BAW_WITHIN(tap->txa_start, tap->txa_wnd, seqno)) { ATH_TXQ_INSERT_TAIL(tid, bf, bf_list); ath_tx_tid_sched(sc, tid); return; } if (! bf->bf_state.bfs_seqno_assigned) { + int seqno; + seqno = ath_tx_tid_seqno_assign(sc, ni, bf, bf->bf_m); if (seqno < 0) { device_printf(sc->sc_dev, Modified: head/sys/dev/ath/if_ath_tx_ht.c ============================================================================== --- head/sys/dev/ath/if_ath_tx_ht.c Mon Mar 26 15:38:17 2012 (r233513) +++ head/sys/dev/ath/if_ath_tx_ht.c Mon Mar 26 16:05:19 2012 (r233514) @@ -652,7 +652,6 @@ ath_tx_form_aggr(struct ath_softc *sc, s int status = ATH_AGGR_DONE; int prev_frames = 0; /* XXX for AR5416 burst, not done here */ int prev_al = 0; /* XXX also for AR5416 burst */ - int seqno; ATH_TXQ_LOCK_ASSERT(sc->sc_ac2q[tid->ac]); @@ -747,13 +746,32 @@ ath_tx_form_aggr(struct ath_softc *sc, s * see ath_tx_xmit_aggr() for more info. */ if (bf->bf_state.bfs_dobaw) { + ieee80211_seq seqno; + + /* + * If the sequence number is allocated, use it. + * Otherwise, use the sequence number we WOULD + * allocate. + */ + if (bf->bf_state.bfs_seqno_assigned) + seqno = SEQNO(bf->bf_state.bfs_seqno); + else + seqno = ni->ni_txseqs[bf->bf_state.bfs_tid]; + + /* + * Check whether either the currently allocated + * sequence number _OR_ the to-be allocated + * sequence number is inside the BAW. + */ if (! BAW_WITHIN(tap->txa_start, tap->txa_wnd, - ni->ni_txseqs[bf->bf_state.bfs_tid])) { + seqno)) { status = ATH_AGGR_BAW_CLOSED; break; } + /* XXX check for bfs_need_seqno? */ if (! bf->bf_state.bfs_seqno_assigned) { + int seqno; seqno = ath_tx_tid_seqno_assign(sc, ni, bf, bf->bf_m); if (seqno < 0) { device_printf(sc->sc_dev, _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 26 18:00:56 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51F6D106566B for ; Mon, 26 Mar 2012 18:00:56 +0000 (UTC) (envelope-from sh4neriddle@yahoo.com) Received: from nm27.bullet.mail.bf1.yahoo.com (nm27.bullet.mail.bf1.yahoo.com [98.139.212.186]) by mx1.freebsd.org (Postfix) with SMTP id 02F7B8FC12 for ; Mon, 26 Mar 2012 18:00:55 +0000 (UTC) Received: from [98.139.212.152] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2012 18:00:55 -0000 Received: from [98.139.215.228] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2012 18:00:55 -0000 Received: from [127.0.0.1] by omp1068.mail.bf1.yahoo.com with NNFMP; 26 Mar 2012 18:00:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 277791.87509.bm@omp1068.mail.bf1.yahoo.com Received: (qmail 58009 invoked by uid 60001); 26 Mar 2012 18:00:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1332784855; bh=sNiN/O6lXi0wo/UQUonboYIIwMLj8e5rPe2HWGD1zBQ=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=NbXsSHJZTiF01LFWp8Hi5bWY3hhULCk9jpmxVk8UzmaUwO9P8U4VDM67qkOaE3oyCfYM4adWniyjCvPa74jpR9iPS3t0X0l0bSgys3IULIgfuM/raCXYvZvc1O5U8e8ue1xphQv/sJu9/Jiobm3/PCXS7U2s3W/M3mIBRRM0IsU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CB+z7R1h0niM1dIEE3yIGJonaH96Cch3DTi3F3s8CO622LKOHGHIoNYMaMAALLjqcvmh5WWR+GJRkwWHLvBp7marIUye0MSkjM2z29VyCz3wOyiT+XP3+T8GMCUD//jgWdNv2SM0EIvj+IJ4s/szI8zjC/tsNFLbZ69yGYjOJVQ=; X-YMail-OSG: O_lM7TcVM1kD_jU0IzCVsDtZUuKI5pqZI3qFIWDIn2heiYR lDv78IuAK7XphNuj8Z.6hIoXAzfA3OsZ0cuX5tdlmBoQVxfM4wBfyom6C_Ia qVSDZjENycyaJlj5I1UGPPrabofML6ROOcXGKHndfkP0O_W0.U77kvi6xrCA SHg.GnnHzDR5ZTJBsf0Jw53SEitJjmoQwkI3Oyy.Kp9hkbgc5duKr93l7Wq3 VFvmISaBgpjtGujnNc7CFWQ5rg0pc0VYS_fH4A4BYo_Hss2WUkY6DMVqOgwu ESFmkucNf6J7EFTTqF45UC1e8eIZgq7d4YcGQxUubZXHLQreiRJ4SLOfbfww odRrrwQjT_CnzrOD5D9FXqp5_ODjIMK64kj21HwGrR9EOI6Iy02QPCpPqeob BewtI7Jm8p8X.aTNf5tTPhYW.T1YxeRhS_C02xZfJ1j3gjFkY Received: from [67.60.77.222] by web162302.mail.bf1.yahoo.com via HTTP; Mon, 26 Mar 2012 11:00:54 PDT X-Mailer: YahooMailWebService/0.8.117.340979 References: <1332372462.30788.YahooMailNeo@web162302.mail.bf1.yahoo.com> Message-ID: <1332784854.37320.YahooMailNeo@web162302.mail.bf1.yahoo.com> Date: Mon, 26 Mar 2012 11:00:54 -0700 (PDT) From: Shane Riddle To: Bernhard Schmidt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-wireless@freebsd.org" Subject: Re: intel Centrino 6150 Wireless Card w freebsd8.2 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Shane Riddle List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 18:00:56 -0000 It worked!=A0=0A=0AThank you very much....=A0=0A=0A=0A=0A>_________________= _______________=0A> From: Bernhard Schmidt =0A>To: = Shane Riddle =0A>Cc: "freebsd-wireless@freebsd.org"= =0A>Sent: Thursday, March 22, 2012 2:49 AM= =0A>Subject: Re: intel Centrino 6150 Wireless Card w freebsd8.2=0A> =0A>On = Thu, Mar 22, 2012 at 00:27, Shane Riddle wrote:=0A>= > Hello Bernhard,=0A>>=0A>>=0A>> Were you ever able to get a hold of this c= ard?=0A>=0A>No, the cards with wimax support are hard to get.=0A>=0A>> iwi = and iwn don't seem to support it on my laptop.... or maybe I'm not doing so= mething right. Before investigating further I figured I'd check here first.= =0A>=0A>I can't say for certain that the card is supported due to mentioned= =0A>lack of hardware, but chances are pretty good that with just applying= =0A>attached patch you get the card to work on a recent 9 version. Want to= =0A>give it a shot?=0A>=0A>-- =0A>Bernhard=0A>=0A>=0A> From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 26 21:59:14 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B841106564A for ; Mon, 26 Mar 2012 21:59:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 22A188FC16 for ; Mon, 26 Mar 2012 21:59:13 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so7515355pbc.13 for ; Mon, 26 Mar 2012 14:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=MXLRCZYp9tcwqAPBuYs42wHMMXazVO5iuAbRx1EbAhs=; b=A91BG5u/v9i3ZhBvBBxsd10zMajGeJ+0LiOfMUeAePEg7tyJCreSJ7q2LM/3bH+wp6 P1+DKje8P0r2Uo1cZdPsqXMWTCANljJNNLMlpnQg+OLivUTaev1mNhNAJ9bDE/AX7Wn9 LjrZwiLMWS9q/XvKw8Za/ZAZHvkNAzgyQt5mYs2yQhj6PU8rr0kYf6OQD9OpJ9O2XTQl THob0SwUKNGXwvMtkhrWQl1bYaQptGjn+qX950d2dll4DMFDXE+Km+9FLfgtxJMXB6ey k+XbfNwQO5RiY9fnw4EY0m5H0dukmYrRTUMmbnOAYrcrohj1ZrMce09VF5ex/bqbFQ2v znYg== MIME-Version: 1.0 Received: by 10.68.202.195 with SMTP id kk3mr44352112pbc.96.1332799153717; Mon, 26 Mar 2012 14:59:13 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Mon, 26 Mar 2012 14:59:13 -0700 (PDT) Date: Mon, 26 Mar 2012 14:59:13 -0700 X-Google-Sender-Auth: pYuVx4sdk7RXPC-dAoQzIJKfYms Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: TX BAW hangs (again) fixed, please test -HEAD X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 21:59:14 -0000 Hi, I've fixed the latest TX BAW (TX block-ack window) hang which I introduced when I fixed another BAW hang. I'm going to do a drive by tidy-up of this stuff but I'd just first like to be sure that no further TX aggregation hangs. Remember, if you're testing atheros 802.11n out you need to create your vap with -bgscan or things will get very special. Fixing 802.11n (and non-n too) background scanning is another complete project and I don't want to tackle it yet. So I'd appreciate it if those of you testing out ath(4) 802.11n (in both station and access point modes) could please update your net80211 and ath driver to -HEAD. Please report back any issues that creep up. Thanks, Adrian From owner-freebsd-wireless@FreeBSD.ORG Tue Mar 27 07:05:18 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D80C3106566B for ; Tue, 27 Mar 2012 07:05:18 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 551538FC14 for ; Tue, 27 Mar 2012 07:05:17 +0000 (UTC) Received: by lboi15 with SMTP id i15so6081287lbo.13 for ; Tue, 27 Mar 2012 00:05:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=qgxNccvYUaLmjgdKrARk1YXVPQzaOfQqB3Dpef9qvZo=; b=i1fdT3JUBHj9T9lsfWh0mYBYdqsjRIwvi/qU4AEGv9YTRtwFCyMS04/C0Yvu+OOQkH xQK0tXvANALoBrzDrQ48e2cFgfGSelthG6Tdu3CnPWxXN6uRbCeuNyrOfShXUXghPsvt ydnEXbupYVBfePUytEZy3qhIMqkMkJ07sdMBl1P/F/7x+5aQkaaVU4LrE1xNMSEf4eDT /wFrZOjwcMDE4qT8v4AN4JJZWyVNL64xTMVvwC1cYbizcCi0+lrL5DL42JuqGBba4xJx MML/BtdAdoSuBVgO9GBebRJ+BOkrPiDz++h92FxQSjbBYN11sjVaS5i4pQrJ1JNSU1Bc rEPw== MIME-Version: 1.0 Received: by 10.152.103.12 with SMTP id fs12mr17802269lab.47.1332831534290; Mon, 26 Mar 2012 23:58:54 -0700 (PDT) Received: by 10.152.112.234 with HTTP; Mon, 26 Mar 2012 23:58:54 -0700 (PDT) X-Originating-IP: [79.140.39.245] In-Reply-To: <1332784854.37320.YahooMailNeo@web162302.mail.bf1.yahoo.com> References: <1332372462.30788.YahooMailNeo@web162302.mail.bf1.yahoo.com> <1332784854.37320.YahooMailNeo@web162302.mail.bf1.yahoo.com> Date: Tue, 27 Mar 2012 08:58:54 +0200 Message-ID: From: Bernhard Schmidt To: Shane Riddle Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlp9fxSMsrRVC0+R0rJrk/VU7hsqzJFbHal4IS02EOyVWoogEhk+B2YfY42y+svvVDVQMUZ Cc: "freebsd-wireless@freebsd.org" Subject: Re: intel Centrino 6150 Wireless Card w freebsd8.2 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 07:05:18 -0000 On Mon, Mar 26, 2012 at 20:00, Shane Riddle wrote: > It worked! > > Thank you very much.... Nice! I'll get it into the tree. Thanks! -- Bernhard From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 29 21:00:19 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE97B106564A for ; Thu, 29 Mar 2012 21:00:18 +0000 (UTC) (envelope-from Marc.Mosko@parc.com) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mx1.freebsd.org (Postfix) with ESMTP id 749108FC08 for ; Thu, 29 Mar 2012 21:00:18 +0000 (UTC) Received: from exchangehub.parc.xerox.com ([13.2.13.102]) by alpha.xerox.com with SMTP id <322037(2)>; Thu, 29 Mar 2012 13:59:07 PDT Received: from E2010DAG2.corp.ad.parc.com ([fe80::5c4e:d341:1a9c:59c0]) by vertigo.corp.ad.parc.com ([fe80::606e:47ce:f5e2:fe3a%16]) with mapi; Thu, 29 Mar 2012 13:59:07 -0700 From: To: Thread-Topic: Tdma module Thread-Index: Ac0N7sfWFZeQ99JUQz2c8jNhv85ZQw== Date: Thu, 29 Mar 2012 13:59:09 PDT Message-ID: <1111A274-7A9E-442B-9918-DD80298BE766@parc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Tdma module X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 21:00:19 -0000 Hello, Is there any documentation available for the tdma module? I'm primarily in= terested in how time sync works and how slots are assigned. I had implemented some tdma macs on an old madwifi on linux 3 years ago and= I'd like to bring them into a current driver without having to hack it to = death like before. Thanks, Marc Mosko From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 29 21:30:28 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41C68106564A for ; Thu, 29 Mar 2012 21:30:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id B15058FC12 for ; Thu, 29 Mar 2012 21:30:27 +0000 (UTC) Received: by lagv3 with SMTP id v3so4365198lag.13 for ; Thu, 29 Mar 2012 14:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NbQ1iLV1W3PYcFI+mrBqUzXITADpNPDJAsRFTFk8TAw=; b=uJgRE1fpT5XeG8HzQtkKHpN6w33AKV+qmCw3CfME5gJJdR8SRBm8hD5cx/M2bXcHbv Tk2lM/EHwpbLgmeeLdWVWiDK0voD/7Pv/iUscJz6vqyLw4ms/yNPfQ8JHuKJVJq97g04 4npkbxJ27pQvYl901fJ8njSBql+F9NTDE/q/jBv9e0scQnALNCmst1w61aQCzeBb3WNX 882Ct8h4kgoGkybZLN932BD1zJNBYQGE6CW0ZVu9ThV2OoqhXUiLfMtRPNFvyC3kmWUR lNWHkUno7ZLSdqMHDxwzNdGrUxolNKAn8w/GM5NzBYJQHOuwjsLARysm/T7HU1UVAA9t ANyg== MIME-Version: 1.0 Received: by 10.152.111.161 with SMTP id ij1mr29037415lab.19.1333056626206; Thu, 29 Mar 2012 14:30:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.112.91.141 with HTTP; Thu, 29 Mar 2012 14:30:26 -0700 (PDT) In-Reply-To: <1111A274-7A9E-442B-9918-DD80298BE766@parc.com> References: <1111A274-7A9E-442B-9918-DD80298BE766@parc.com> Date: Thu, 29 Mar 2012 14:30:26 -0700 X-Google-Sender-Auth: MoDjnLiL8dUvkbRST8meBMidRkk Message-ID: From: Adrian Chadd To: Marc.Mosko@parc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org Subject: Re: Tdma module X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 21:30:28 -0000 On 29 March 2012 13:59, wrote: > Hello, > > Is there any documentation available for the tdma module? =A0I'm primaril= y interested in how time sync works and how slots are assigned. > > I had implemented some tdma macs on an old madwifi on linux 3 years ago a= nd I'd like to bring them into a current driver without having to hack it t= o death like before. Hi, Google for Sam Leffler's TDMA paper. Unfortunately I haven't had much time to test it out, so it's quite possible that it's broken in 9 and further broken in 10. The specifics are: * the beacon related timers changed between AR5212 and AR5416 (11n), so all the TDMA assumptions that certain timers were in TU's were no longer true; * I've massively hacked on the TX data path to support 802.11n aggregation. Although I know what is needed for TDMA, I've ignored it for now and will continue to do so until I finish 802.11n aggregation. I do plan on trying to bring up TDMA on -HEAD once I've finished the 11n TX aggregation work. I have a good idea of what his work is supposed to be doing, so I'll just fix up the STA/AP TDMA configuration first and ensure that the timers are setup correctly. I'll then worry about frame TX. I won't say no if you're interested in helping out :) Adrian From owner-freebsd-wireless@FreeBSD.ORG Sat Mar 31 18:28:58 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3057B106566B for ; Sat, 31 Mar 2012 18:28:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0090F8FC0A for ; Sat, 31 Mar 2012 18:28:57 +0000 (UTC) Received: by dadz14 with SMTP id z14so3863280dad.17 for ; Sat, 31 Mar 2012 11:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=aeaAPS54N4pzUYMBswciKCoHfr9kZs2lHiDx2NZ3mF8=; b=KMTmk3JRd2jGtfOEUXmWsrgzRbp+DQg+RA95Z58fjRIJPRpz8DfIR99UYWqImx9Rgk 0WW7vazkySQgnNOSaxp5UmTGDPhit22a0SrppAhamckVlohB7MtzHKlYFENpN9JqE6Rv EEge1ujIknGEUa54IJvZ2Uo5AmJ23jWN5LZOSOcnPBJ5iNuNGkwb9RJ78/QOaI2iuP8a 8dcIVZUjffKt63Q9EzW0NmiMaFhrFVddhH02G939Gg6QnzjvEPyL0Rp6cFRwSwldT+WF 4Owyqp69ibP9rvRQUA77JMog3c9k78FD3B6fJGdzIYLQaGnAD3rFgiahQIor1YZNU93s UWhw== MIME-Version: 1.0 Received: by 10.68.234.134 with SMTP id ue6mr7784575pbc.14.1333218537556; Sat, 31 Mar 2012 11:28:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.19.19 with HTTP; Sat, 31 Mar 2012 11:28:57 -0700 (PDT) Date: Sat, 31 Mar 2012 11:28:57 -0700 X-Google-Sender-Auth: hFmf4GPTfUmc8ACeZRZOx9htYPw Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: multipart/mixed; boundary=047d7b33cf7c56c94404bc8e2115 Subject: Request for testing: BAR TX handling for ath(4) X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 18:28:58 -0000 --047d7b33cf7c56c94404bc8e2115 Content-Type: text/plain; charset=ISO-8859-1 Hi all, This patch is my first (dirty) attempt at implementing BAR TX for FreeBSD. What it does: * adds two state flags for ath_tid - one that indicates that a BAR is pending, another that indicates that a BAR TX has been attempted. * whenever a frame is dropped, transition into the BAR pending state and pause the queue - but it's paused once, on the state transition, since multiple frames inside the BAW may be dropped; * .. then, don't transmit anything from that TID until all the frames in the hardware queue for that TID are completed. * Check whether we need to send the BAR upon completion of any frame it an aggregation session (aggregate or unaggregate) - as there may have been more than one frame pending on the hardware queue, and only one out of a larger set may have failed. I'm not entirely comfortable with this solution - especially with the silly locking - but it does work. The main downside is that the call to ieee80211_send_bar() can fail if the ic_raw_xmit function or the mbuf allocation functions return errors. Now, what I'm seeing with live tests is that sometimes, the sender side will fail one of these and the BAR attempt will fail. For now this code just ignores it and continues along it's merry way. It _should_ drop out of aggregation. If ieee80211_send_bar() does fail to successfully transmit the BAR, it will eventually transition the session out of aggregation. However, if the initial call to ieee80211_send_bar() fails, then the driver has to handle it itself. I'll fix the behaviour or use of ieee80211_send_bar() in a future commit. I'd just like to get the BAR suspend/resume stuff tidied up and in the tree so I'm one step closer to enabling ath 11n by default. TL;DR - if you're testing out FreeBSD ath(4) 802.11n support, please enable this patch and let me know what happens. Thanks! Adrian --047d7b33cf7c56c94404bc8e2115 Content-Type: application/octet-stream; name="ath-bar-tx-2.diff" Content-Disposition: attachment; filename="ath-bar-tx-2.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h0gzf6180 SW5kZXg6IHN5cy9kZXYvYXRoL2lmX2F0aHZhci5oCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvYXRo L2lmX2F0aHZhci5oCShyZXZpc2lvbiAyMzM2NzMpCisrKyBzeXMvZGV2L2F0aC9pZl9hdGh2YXIu aAkod29ya2luZyBjb3B5KQpAQCAtMTA2LDYgKzEwNiw4IEBACiAJVEFJTFFfRU5UUlkoYXRoX3Rp ZCkJYXhxX3FlbGVtOwogCWludAkJCXNjaGVkOwogCWludAkJCXBhdXNlZDsJLyogPjAgaWYgdGhl IFRJRCBoYXMgYmVlbiBwYXVzZWQgKi8KKwlpbnQJCQliYXJfd2FpdDsJLyogd2FpdGluZyBmb3Ig QkFSICovCisJaW50CQkJYmFyX3R4OwkJLyogQkFSIFRYZWQgKi8KIAogCS8qCiAJICogSXMgdGhl IFRJRCBiZWluZyBjbGVhbmVkIHVwIGFmdGVyIGEgdHJhbnNpdGlvbgpJbmRleDogc3lzL2Rldi9h dGgvaWZfYXRoX3R4LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9hdGgvaWZfYXRoX3R4LmMJKHJl dmlzaW9uIDIzMzY3MykKKysrIHN5cy9kZXYvYXRoL2lmX2F0aF90eC5jCSh3b3JraW5nIGNvcHkp CkBAIC0yNTk3LDExICsyNTk3LDExIEBACiBzdGF0aWMgdm9pZAogYXRoX3R4X3RpZF9wYXVzZShz dHJ1Y3QgYXRoX3NvZnRjICpzYywgc3RydWN0IGF0aF90aWQgKnRpZCkKIHsKLQlBVEhfVFhRX0xP Q0soc2MtPnNjX2FjMnFbdGlkLT5hY10pOworCisJQVRIX1RYUV9MT0NLX0FTU0VSVChzYy0+c2Nf YWMycVt0aWQtPmFjXSk7CiAJdGlkLT5wYXVzZWQrKzsKIAlEUFJJTlRGKHNjLCBBVEhfREVCVUdf U1dfVFhfQ1RSTCwgIiVzOiBwYXVzZWQgPSAlZFxuIiwKIAkgICAgX19mdW5jX18sIHRpZC0+cGF1 c2VkKTsKLQlBVEhfVFhRX1VOTE9DSyhzYy0+c2NfYWMycVt0aWQtPmFjXSk7CiB9CiAKIC8qCkBA IC0yNjI4LDYgKzI2MjgsMTQ2IEBACiB9CiAKIC8qCisgKiBTdXNwZW5kIHRoZSBxdWV1ZSBiZWNh dXNlIHdlIG5lZWQgdG8gVFggYSBCQVIuCisgKi8KK3N0YXRpYyB2b2lkCithdGhfdHhfdGlkX2Jh cl9zdXNwZW5kKHN0cnVjdCBhdGhfc29mdGMgKnNjLCBzdHJ1Y3QgYXRoX3RpZCAqdGlkKQorewor CUFUSF9UWFFfTE9DS19BU1NFUlQoc2MtPnNjX2FjMnFbdGlkLT5hY10pOworCisJZGV2aWNlX3By aW50ZihzYy0+c2NfZGV2LCAiJXM6IHRpZD0lcCwgY2FsbGVkXG4iLCBfX2Z1bmNfXywgdGlkKTsK KworCS8qIFdlIHNob3VsZG4ndCBiZSBjYWxsZWQgd2hlbiBiYXJfdHggaXMgMSAqLworCWlmICh0 aWQtPmJhcl90eCkgeworCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsICIlczogYmFyX3R4IGlz IDE/IVxuIiwKKwkJICAgIF9fZnVuY19fKTsKKwl9CisKKwkvKiBJZiB3ZSd2ZSBhbHJlYWR5IGJl ZW4gY2FsbGVkLCBqdXN0IGJlIHBhdGllbnQuICovCisJaWYgKHRpZC0+YmFyX3dhaXQpCisJCXJl dHVybjsKKworCS8qIFdhaXQhICovCisJdGlkLT5iYXJfd2FpdCA9IDE7CisKKwkvKiBPbmx5IG9u ZSBwYXVzZSwgbm8gbWF0dGVyIGhvdyBtYW55IGZyYW1lcyBmYWlsICovCisJYXRoX3R4X3RpZF9w YXVzZShzYywgdGlkKTsKK30KKworLyoKKyAqIFdlJ3ZlIGZpbmlzaGVkIHdpdGggQkFSIGhhbmRs aW5nIC0gZWl0aGVyIHdlIHN1Y2NlZWRlZCBvcgorICogZmFpbGVkLiBFaXRoZXIgd2F5LCB1bnN1 c3BlbmQgVFguCisgKi8KK3N0YXRpYyB2b2lkCithdGhfdHhfdGlkX2Jhcl91bnN1c3BlbmQoc3Ry dWN0IGF0aF9zb2Z0YyAqc2MsIHN0cnVjdCBhdGhfdGlkICp0aWQpCit7CisJQVRIX1RYUV9MT0NL X0FTU0VSVChzYy0+c2NfYWMycVt0aWQtPmFjXSk7CisKKwlkZXZpY2VfcHJpbnRmKHNjLT5zY19k ZXYsICIlczogdGlkPSVwLCBjYWxsZWRcbiIsIF9fZnVuY19fLCB0aWQpOworCisJaWYgKHRpZC0+ YmFyX3R4ID09IDAgfHwgdGlkLT5iYXJfd2FpdCA9PSAwKSB7CisJCWRldmljZV9wcmludGYoc2Mt PnNjX2RldiwgIiVzOiBiYXJfdHg9JWQsIGJhcl93YWl0PSVkOiA/XG4iLAorCQkgICAgX19mdW5j X18sIHRpZC0+YmFyX3R4LCB0aWQtPmJhcl93YWl0KTsKKwl9CisKKwl0aWQtPmJhcl90eCA9IHRp ZC0+YmFyX3dhaXQgPSAwOworCWF0aF90eF90aWRfcmVzdW1lKHNjLCB0aWQpOworfQorCisvKgor ICogUmV0dXJuIHdoZXRoZXIgd2UncmUgcmVhZHkgdG8gVFggYSBCQVIgZnJhbWUuCisgKgorICog UmVxdWlyZXMgdGhlIFRJRCBsb2NrIGJlIGhlbGQuCisgKi8KK3N0YXRpYyBpbnQKK2F0aF90eF90 aWRfYmFyX3R4X3JlYWR5KHN0cnVjdCBhdGhfc29mdGMgKnNjLCBzdHJ1Y3QgYXRoX3RpZCAqdGlk KQoreworCisJQVRIX1RYUV9MT0NLX0FTU0VSVChzYy0+c2NfYWMycVt0aWQtPmFjXSk7CisKKwlp ZiAodGlkLT5iYXJfd2FpdCA9PSAwIHx8IHRpZC0+aHdxX2RlcHRoID4gMCkKKwkJcmV0dXJuICgw KTsKKworCXJldHVybiAoMSk7Cit9CisKKy8qCisgKiBDaGVjayB3aGV0aGVyIHRoZSBjdXJyZW50 IFRJRCBpcyByZWFkeSB0byBoYXZlIGEgQkFSCisgKiBUWGVkIGFuZCBpZiBzbywgZG8gdGhlIFRY LgorICoKKyAqIFNpbmNlIHRoZSBUSUQvVFhRIGxvY2sgY2FuJ3QgYmUgaGVsZCBkdXJpbmcgYSBj YWxsIHRvCisgKiBpZWVlODAyMTFfc2VuZF9iYXIoKSwgd2UgaGF2ZSB0byBkbyB0aGUgZGlydHkg dGhpbmcgb2YgdW5sb2NraW5nIGl0LAorICogc2VuZGluZyB0aGUgQkFSIGFuZCBsb2NraW5nIGl0 IGFnYWluLgorICoKKyAqIEV2ZW50dWFsbHksIHRoZSBjb2RlIHRvIHNlbmQgdGhlIEJBUiBzaG91 bGQgYmUgYnJva2VuIG91dAorICogZnJvbSB0aGlzIHJvdXRpbmUgc28gdGhlIGxvY2sgZG9lc24n dCBoYXZlIHRvIGJlIHJlYWNxdWlyZWQKKyAqIGp1c3QgdG8gYmUgaW1tZWRpYXRlbHkgZHJvcHBl ZCBieSB0aGUgY2FsbGVyLgorICovCitzdGF0aWMgdm9pZAorYXRoX3R4X3RpZF9iYXJfdHgoc3Ry dWN0IGF0aF9zb2Z0YyAqc2MsIHN0cnVjdCBhdGhfdGlkICp0aWQpCit7CisJc3RydWN0IGllZWU4 MDIxMV90eF9hbXBkdSAqdGFwOworCisJQVRIX1RYUV9MT0NLX0FTU0VSVChzYy0+c2NfYWMycVt0 aWQtPmFjXSk7CisKKwlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsICIlczogdGlkPSVwLCBjYWxs ZWRcbiIsIF9fZnVuY19fLCB0aWQpOworCisJdGFwID0gYXRoX3R4X2dldF90eF90aWQodGlkLT5h biwgdGlkLT50aWQpOworCisJLyoKKwkgKiBUaGlzIGlzIGFuIGVycm9yIGNvbmRpdGlvbiEKKwkg Ki8KKwlpZiAodGlkLT5iYXJfd2FpdCA9PSAwIHx8IHRpZC0+YmFyX3R4ID09IDEpIHsKKwkJZGV2 aWNlX3ByaW50ZihzYy0+c2NfZGV2LAorCQkgICAgIiVzOiB0aWQ9JXAsIGJhcl90eD0lZCwgYmFy X3dhaXQ9JWQ6ID9cbiIsCisJCSAgICBfX2Z1bmNfXywKKwkJICAgIHRpZCwKKwkJICAgIHRpZC0+ YmFyX3R4LAorCQkgICAgdGlkLT5iYXJfd2FpdCk7CisJCXJldHVybjsKKwl9CisKKwkvKiBEb24n dCBkbyBhbnl0aGluZyBpZiB3ZSBzdGlsbCBoYXZlIHBlbmRpbmcgZnJhbWVzICovCisJaWYgKHRp ZC0+aHdxX2RlcHRoID4gMCkgeworCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsCisJCSAgICAi JXM6IHRpZD0lcCwgaHdxX2RlcHRoPSVkLCB3YWl0aW5nXG4iLAorCQkgICAgX19mdW5jX18sCisJ CSAgICB0aWQsCisJCSAgICB0aWQtPmh3cV9kZXB0aCk7CisJCXJldHVybjsKKwl9CisKKwkvKiBX ZSdyZSBub3cgYWJvdXQgdG8gVFggKi8KKwl0aWQtPmJhcl90eCA9IDE7CisKKwkvKgorCSAqIENh bGN1bGF0ZSBuZXcgQkFXIGxlZnQgZWRnZSwgbm93IHRoYXQgYWxsIGZyYW1lcyBoYXZlIGVpdGhl cgorCSAqIHN1Y2NlZWRlZCBvciBmYWlsZWQuCisJICoKKwkgKiBYWFggdmVyaWZ5IHRoaXMgaXMg X2FjdHVhbGx5XyB0aGUgdmFsaWQgdmFsdWUgdG8gYmVnaW4gYXQhCisJICovCisJZGV2aWNlX3By aW50ZihzYy0+c2NfZGV2LCAiJXM6IHRpZD0lcCwgbmV3IEJBVyBsZWZ0IGVkZ2U9JWRcbiIsCisJ ICAgIF9fZnVuY19fLCB0aWQsIHRhcC0+dHhhX3N0YXJ0KTsKKworCS8qIFRyeSBzZW5kaW5nIHRo ZSBCQVIgZnJhbWUgKi8KKwkvKiBXZSBjYW4ndCBob2xkIHRoZSBsb2NrIGhlcmUhICovCisKKwlB VEhfVFhRX1VOTE9DSyhzYy0+c2NfYWMycVt0aWQtPmFjXSk7CisJaWYgKGllZWU4MDIxMV9zZW5k X2JhcigmdGlkLT5hbi0+YW5fbm9kZSwgdGFwLCB0YXAtPnR4YV9zdGFydCkgPT0gMCkgeworCQkv KiBTdWNjZXNzPyBOb3cgd2Ugd2FpdCBmb3Igbm90aWZpY2F0aW9uIHRoYXQgaXQncyBkb25lICov CisJCUFUSF9UWFFfTE9DSyhzYy0+c2NfYWMycVt0aWQtPmFjXSk7CisJCXJldHVybjsKKwl9CisK KwkvKiBGYWlsdXJlPyBGb3Igbm93LCB3YXJuIGxvdWRseSBhbmQgY29udGludWUgKi8KKwlBVEhf VFhRX0xPQ0soc2MtPnNjX2FjMnFbdGlkLT5hY10pOworCWRldmljZV9wcmludGYoc2MtPnNjX2Rl diwgIiVzOiB0aWQ9JXAsIGZhaWxlZCB0byBUWCBCQVIsIGNvbnRpbnVlIVxuIiwKKwkgICAgX19m dW5jX18sIHRpZCk7CisJYXRoX3R4X3RpZF9iYXJfdW5zdXNwZW5kKHNjLCB0aWQpOworfQorCisK Ky8qCiAgKiBGcmVlIGFueSBwYWNrZXRzIGN1cnJlbnRseSBwZW5kaW5nIGluIHRoZSBzb2Z0d2Fy ZSBUWCBxdWV1ZS4KICAqCiAgKiBUaGlzIHdpbGwgYmUgY2FsbGVkIHdoZW4gYSBub2RlIGlzIGJl aW5nIGRlbGV0ZWQuCkBAIC0zMDc2LDcgKzMyMTYsNiBAQAogCWludCB0aWQgPSBiZi0+YmZfc3Rh dGUuYmZzX3RpZDsKIAlzdHJ1Y3QgYXRoX3RpZCAqYXRpZCA9ICZhbi0+YW5fdGlkW3RpZF07CiAJ c3RydWN0IGllZWU4MDIxMV90eF9hbXBkdSAqdGFwOwotCWludCB0eHNlcTsKIAogCUFUSF9UWFFf TE9DSyhzYy0+c2NfYWMycVthdGlkLT5hY10pOwogCkBAIC0zMTE3LDE4ICszMjU2LDE0IEBACiAJ CX0KIAkJYmYtPmJmX3N0YXRlLmJmc19kb2JhdyA9IDA7CiAKLQkJLyogU2VuZCBCQVIgZnJhbWUg Ki8KLQkJLyoKLQkJICogVGhpcydsbCBlbmQgdXAgZ29pbmcgaW50byBuZXQ4MDIxMSBhbmQgYmFj ayBvdXQKLQkJICogYWdhaW4sIHZpYSBpYy0+aWNfcmF3X3htaXQoKS4KLQkJICovCi0JCXR4c2Vx ID0gdGFwLT50eGFfc3RhcnQ7Ci0JCUFUSF9UWFFfVU5MT0NLKHNjLT5zY19hYzJxW2F0aWQtPmFj XSk7CisJCS8qIFN1c3BlbmQgdGhlIFRYIHF1ZXVlIGFuZCBnZXQgcmVhZHkgdG8gc2VuZCB0aGUg QkFSICovCisJCWF0aF90eF90aWRfYmFyX3N1c3BlbmQoc2MsIGF0aWQpOwogCi0JCWRldmljZV9w cmludGYoc2MtPnNjX2RldiwKLQkJICAgICIlczogVElEICVkOiBzZW5kIEJBUjsgc2VxICVkXG4i LCBfX2Z1bmNfXywgdGlkLCB0eHNlcSk7CisJCS8qIFNlbmQgdGhlIEJBUiBpZiB0aGVyZSBhcmUg bm8gb3RoZXIgZnJhbWVzIHdhaXRpbmcgKi8KKwkJaWYgKGF0aF90eF90aWRfYmFyX3R4X3JlYWR5 KHNjLCBhdGlkKSkKKwkJCWF0aF90eF90aWRfYmFyX3R4KHNjLCBhdGlkKTsKIAotCQkvKiBYWFgg VE9ETzogc2VuZCBCQVIgKi8KKwkJQVRIX1RYUV9VTkxPQ0soc2MtPnNjX2FjMnFbYXRpZC0+YWNd KTsKIAogCQkvKiBGcmVlIGJ1ZmZlciwgYmYgaXMgZnJlZSBhZnRlciB0aGlzIGNhbGwgKi8KIAkJ YXRoX3R4X2RlZmF1bHRfY29tcChzYywgYmYsIDApOwpAQCAtMzE0OCw2ICszMjgzLDkgQEAKIAkg Ki8KIAlBVEhfVFhRX0lOU0VSVF9IRUFEKGF0aWQsIGJmLCBiZl9saXN0KTsKIAlhdGhfdHhfdGlk X3NjaGVkKHNjLCBhdGlkKTsKKwkvKiBTZW5kIHRoZSBCQVIgaWYgdGhlcmUgYXJlIG5vIG90aGVy IGZyYW1lcyB3YWl0aW5nICovCisJaWYgKGF0aF90eF90aWRfYmFyX3R4X3JlYWR5KHNjLCBhdGlk KSkKKwkJYXRoX3R4X3RpZF9iYXJfdHgoc2MsIGF0aWQpOwogCiAJQVRIX1RYUV9VTkxPQ0soc2Mt PnNjX2FjMnFbYXRpZC0+YWNdKTsKIH0KQEAgLTMyNzcsMTcgKzM0MTUsMjAgQEAKIAkgKiBpbiB0 aGUgaWZuZXQgVFggY29udGV4dCBvciByYXcgVFggY29udGV4dC4pCiAJICovCiAJaWYgKGRyb3Bz KSB7Ci0JCWludCB0eHNlcSA9IHRhcC0+dHhhX3N0YXJ0OwotCQlBVEhfVFhRX1VOTE9DSyhzYy0+ c2NfYWMycVt0aWQtPmFjXSk7Ci0JCWRldmljZV9wcmludGYoc2MtPnNjX2RldiwKLQkJICAgICIl czogVElEICVkOiBzZW5kIEJBUjsgc2VxICVkXG4iLAotCQkgICAgX19mdW5jX18sIHRpZC0+dGlk LCB0eHNlcSk7Ci0KLQkJLyogWFhYIFRPRE86IHNlbmQgQkFSICovCi0JfSBlbHNlIHsKLQkJQVRI X1RYUV9VTkxPQ0soc2MtPnNjX2FjMnFbdGlkLT5hY10pOworCQkvKiBTdXNwZW5kIHRoZSBUWCBx dWV1ZSBhbmQgZ2V0IHJlYWR5IHRvIHNlbmQgdGhlIEJBUiAqLworCQlhdGhfdHhfdGlkX2Jhcl9z dXNwZW5kKHNjLCB0aWQpOwogCX0KIAorCUFUSF9UWFFfVU5MT0NLKHNjLT5zY19hYzJxW3RpZC0+ YWNdKTsKKworCS8qCisJICogU2VuZCBCQVIgaWYgcmVxdWlyZWQKKwkgKi8KKwlBVEhfVFhRX0xP Q0soc2MtPnNjX2FjMnFbdGlkLT5hY10pOworCWlmIChhdGhfdHhfdGlkX2Jhcl90eF9yZWFkeShz YywgdGlkKSkKKwkJYXRoX3R4X3RpZF9iYXJfdHgoc2MsIHRpZCk7CisJQVRIX1RYUV9VTkxPQ0so c2MtPnNjX2FjMnFbdGlkLT5hY10pOworCiAJLyogQ29tcGxldGUgZnJhbWVzIHdoaWNoIGVycm9y ZWQgb3V0ICovCiAJd2hpbGUgKChiZiA9IFRBSUxRX0ZJUlNUKCZiZl9jcSkpICE9IE5VTEwpIHsK IAkJVEFJTFFfUkVNT1ZFKCZiZl9jcSwgYmYsIGJmX2xpc3QpOwpAQCAtMzMyNyw2ICszNDY4LDEw IEBACiAJCWF0aWQtPmNsZWFudXBfaW5wcm9ncmVzcyA9IDA7CiAJCWF0aF90eF90aWRfcmVzdW1l KHNjLCBhdGlkKTsKIAl9CisKKwkvKiBTZW5kIEJBUiBpZiByZXF1aXJlZCAqLworCWlmIChhdGhf dHhfdGlkX2Jhcl90eF9yZWFkeShzYywgYXRpZCkpCisJCWF0aF90eF90aWRfYmFyX3R4KHNjLCBh dGlkKTsKIAlBVEhfVFhRX1VOTE9DSyhzYy0+c2NfYWMycVthdGlkLT5hY10pOwogCiAJLyogSGFu ZGxlIGZyYW1lIGNvbXBsZXRpb24gKi8KQEAgLTM1NDEsOSArMzY4NiwxMCBAQAogCSAqIHNlbmQg YmFyIGlmIHdlIGRyb3BwZWQgYW55IGZyYW1lcwogCSAqLwogCWlmIChkcm9wcykgewotCQlkZXZp Y2VfcHJpbnRmKHNjLT5zY19kZXYsCi0JCSAgICAiJXM6IFRJRCAlZDogc2VuZCBCQVI7IHNlcSAl ZFxuIiwgX19mdW5jX18sIHRpZCwgdHhzZXEpOwotCQkvKiBYWFggVE9ETzogc2VuZCBCQVIgKi8K KwkJLyogU3VzcGVuZCB0aGUgVFggcXVldWUgYW5kIGdldCByZWFkeSB0byBzZW5kIHRoZSBCQVIg Ki8KKwkJQVRIX1RYUV9MT0NLKHNjLT5zY19hYzJxW2F0aWQtPmFjXSk7CisJCWF0aF90eF90aWRf YmFyX3N1c3BlbmQoc2MsIGF0aWQpOworCQlBVEhfVFhRX1VOTE9DSyhzYy0+c2NfYWMycVthdGlk LT5hY10pOwogCX0KIAogCS8qIFByZXBlbmQgYWxsIGZyYW1lcyB0byB0aGUgYmVnaW5uaW5nIG9m IHRoZSBxdWV1ZSAqLwpAQCAtMzU1OCw2ICszNzA0LDE0IEBACiAJRFBSSU5URihzYywgQVRIX0RF QlVHX1NXX1RYX0FHR1IsCiAJICAgICIlczogdHhhX3N0YXJ0IG5vdyAlZFxuIiwgX19mdW5jX18s IHRhcC0+dHhhX3N0YXJ0KTsKIAorCS8qCisJICogU2VuZCBCQVIgaWYgcmVxdWlyZWQKKwkgKi8K KwlBVEhfVFhRX0xPQ0soc2MtPnNjX2FjMnFbYXRpZC0+YWNdKTsKKwlpZiAoYXRoX3R4X3RpZF9i YXJfdHhfcmVhZHkoc2MsIGF0aWQpKQorCQlhdGhfdHhfdGlkX2Jhcl90eChzYywgYXRpZCk7CisJ QVRIX1RYUV9VTkxPQ0soc2MtPnNjX2FjMnFbYXRpZC0+YWNdKTsKKwogCS8qIERvIGRlZmVycmVk IGNvbXBsZXRpb24gKi8KIAl3aGlsZSAoKGJmID0gVEFJTFFfRklSU1QoJmJmX2NxKSkgIT0gTlVM TCkgewogCQlUQUlMUV9SRU1PVkUoJmJmX2NxLCBiZiwgYmZfbGlzdCk7CkBAIC0zNjUxLDYgKzM4 MDUsMTIgQEAKIAkJCSAgICBfX2Z1bmNfXywgU0VRTk8oYmYtPmJmX3N0YXRlLmJmc19zZXFubykp OwogCX0KIAorCS8qCisJICogU2VuZCBCQVIgaWYgcmVxdWlyZWQKKwkgKi8KKwlpZiAoYXRoX3R4 X3RpZF9iYXJfdHhfcmVhZHkoc2MsIGF0aWQpKQorCQlhdGhfdHhfdGlkX2Jhcl90eChzYywgYXRp ZCk7CisKIAlBVEhfVFhRX1VOTE9DSyhzYy0+c2NfYWMycVthdGlkLT5hY10pOwogCiAJYXRoX3R4 X2RlZmF1bHRfY29tcChzYywgYmYsIGZhaWwpOwpAQCAtNDA3OSw3ICs0MjM5LDkgQEAKIAkgKiBp dCdsbCBiZSAiYWZ0ZXIiIHRoZSBsZWZ0IGVkZ2Ugb2YgdGhlIEJBVyBhbmQgdGh1cyBpdCdsbAog CSAqIGZhbGwgd2l0aGluIGl0LgogCSAqLworCUFUSF9UWFFfTE9DSyhzYy0+c2NfYWMycVthdGlk LT50aWRdKTsKIAlhdGhfdHhfdGlkX3BhdXNlKHNjLCBhdGlkKTsKKwlBVEhfVFhRX1VOTE9DSyhz Yy0+c2NfYWMycVthdGlkLT50aWRdKTsKIAogCURQUklOVEYoc2MsIEFUSF9ERUJVR19TV19UWF9D VFJMLAogCSAgICAiJXM6IGNhbGxlZDsgZGlhbG9ndG9rZW49JWQsIGJhcGFyYW1zZXQ9JWQsIGJh dGltZW91dD0lZFxuIiwKQEAgLTQxNjUsNyArNDMyNyw5IEBACiAJRFBSSU5URihzYywgQVRIX0RF QlVHX1NXX1RYX0NUUkwsICIlczogY2FsbGVkXG4iLCBfX2Z1bmNfXyk7CiAKIAkvKiBQYXVzZSBU SUQgdHJhZmZpYyBlYXJseSwgc28gdGhlcmUgYXJlbid0IGFueSByYWNlcyAqLworCUFUSF9UWFFf TE9DSyhzYy0+c2NfYWMycVthdGlkLT50aWRdKTsKIAlhdGhfdHhfdGlkX3BhdXNlKHNjLCBhdGlk KTsKKwlBVEhfVFhRX1VOTE9DSyhzYy0+c2NfYWMycVthdGlkLT50aWRdKTsKIAogCS8qIFRoZXJl J3Mgbm8gbmVlZCB0byBob2xkIHRoZSBUWFEgbG9jayBoZXJlICovCiAJc2MtPnNjX2FkZGJhX3N0 b3AobmksIHRhcCk7CkBAIC00MjEyLDcgKzQzNzYsNyBAQAogCSAqLwogCWlmIChzdGF0dXMgPT0g MCB8fCBhdHRlbXB0cyA9PSA1MCkgewogCQlBVEhfVFhRX0xPQ0soc2MtPnNjX2FjMnFbYXRpZC0+ YWNdKTsKLQkJYXRoX3R4X3RpZF9yZXN1bWUoc2MsIGF0aWQpOworCQlhdGhfdHhfdGlkX2Jhcl91 bnN1c3BlbmQoc2MsIGF0aWQpOwogCQlBVEhfVFhRX1VOTE9DSyhzYy0+c2NfYWMycVthdGlkLT5h Y10pOwogCX0KIH0K --047d7b33cf7c56c94404bc8e2115--