atheros driver under high load, panics and even more freezes
Hi all,
first of all, I´m sorry maybe for my bad English.
We have 2 routers which I maintain in our mesh wireless community network.
The Router 1 has 2 atheros adapters, ath0=wistron cm9, ath1=wistron cm10, of
course some sisX, fxpX and so on.
The Router 2 has 1 atheros adapter, ath1=wistron CM10.
My R1 panics and even more it freezes very often. Maybe the reason for
panicing and freezing is the same and maybe not.
I started (only after vmcore.5, so vmcore.6 is with this option) to use
"option SW_WATCHDOG" in both my custom kernels on the R1 and R2 recently in
hope, it is some walkaround for freezing at least if not for panicing.
This router was installed on the 1st of April 2006.
Statistics:
9 panics with 8 kernel dumps, 1 missed
10 freezes
I think that all panics some how connected to athX taskq process, page fault
in kernel panic and sbflush_locked.
I guess that panic comes when router transmits and receives datas at the
maximum throughput for setted nominal media rate speed, exactly 24Mbps, more
I do not use, because there are problems with quagga
ospfd packets, it is known issue.
Today I did a small test with throughput.
Router 1 executed this command:
# ping -i 0.001 -c 10 -s 1472 ANY IP
As you see, it is not even flood ping, it is almost flood, but not flood.
Throughput was about 1,13-1,2 MB/s as bmon showed me. I notice there is not
any qos and icmp.limit is so high net.inet.icmp.icmplim: 2147483647
net.ineticmp.icmplim_output: 0.
First 5 s latency was about 1,1-1,7 ms
After it goes to 10-30, 50-70, 110-130, 270-300, up 300ms and packet loss
some seconds
panic
here it is:
# kgdb kernel.debug /var/crash/vmcore.6
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc05a47bb
stack pointer = 0x28:0xd447db18
frame pointer = 0x28:0xd447db3c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 24 (ath1 taskq)
trap number = 12
panic: page fault
Uptime: 1d7h56m6s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335
319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) backtrace
#0 doadump () at pcpu.h:165
#1 0xc056da25 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402
#2 0xc056dcbc in panic (fmt=0xc07a4185 "%s") at
/usr/src/sys/kern/kern_shutdown.c:558
#3 0xc07658c8 in trap_fatal (frame=0xd447dad8, eva=12) at
/usr/src/sys/i386/i386/trap.c:836
#4 0xc076562f in trap_pfault (frame=0xd447dad8, usermode=0, eva=12) at
/usr/src/sys/i386/i386/trap.c:744
#5 0xc076528d in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -979275436, tf_esi = 370,
tf_ebp = -733488324, tf_isp = -733488380, tf_ebx = -979275520, tf_edx = 0,
tf_ecx = -1012252656, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip =
-1067825221, tf_cs = 32, tf_eflags = 590342, tf_esp = 0, tf_ss =
-733488320})
at /usr/src/sys/i386/i386/trap.c:434
#6 0xc0754a6a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc05a47bb in m_copym (m=0x0, off0=1500, len=1480, wait=1) at
/usr/src/sys/kern/uipc_mbuf.c:400
#8 0xc06204b8 in ip_fragment (ip=0xc3aa4010, m_frag=0xd447dbec,
mtu=-979275520, if_hwassist_flags=0, sw_csum=1) at
/usr/src/sys/netinet/ip_output.c:975
#9 0xc0610c4e in ip_fastforward (m=0xc3a7ba00) at
/usr/src/sys/netinet/ip_fastfwd.c:561
#10 0xc05de953 in ether_demux (ifp=0xc33ac400, m=0xc3a7ba00) at
/usr/src/sys/net/if_ethersubr.c:766
#11 0xc05de715 in ether_input (ifp=0xc33ac400, m=0xc3a7ba00) at
/usr/src/sys/net/if_ethersubr.c:620
#12 0xc05f5604 in ieee80211_deliver_data (ic=0xc33ad230, ni=0xc5602000,
m=0xc3a7ba00) at /usr/src/sys/net80211/ieee80211_input.c:717
#13 0xc05f507d in ieee80211_input (ic=0xc33ad230, m=0xc3a7ba00,
ni=0xc5602000, rssi=30, rstamp=27616) at
/usr/src/sys/net80211/ieee80211_input.c:481
#14 0xc04afd66 in ath_rx_proc (arg=0xc33ad000, npending=1) at
/usr/src/sys/dev/ath/if_ath.c:2977
#15 0xc058de89 in taskqueue_run (queue=0xc32f4780) at
/usr/src/sys/kern/subr_taskqueue.c:217
#16 0xc
Re: atheros driver under high load, panics and even more freezes
Daniel Dvoøák wrote:
> Hi Sam and all,
>
> I am not sure if I understand your answer, but I try it.
>
> When I use start my test, athstats shows this:
>
> athstats -i ath0
>
> 19308912 data frames received
> 15723536 data frames transmit
> 6536 tx frames with an alternate rate
> 2188280 long on-chip tx retries
> 62583 tx failed 'cuz too many retries
> 348 tx linearized to cluster
> 24M current transmit rate
> 6 tx management frames
> 6 tx frames discarded prior to association
> 27129 tx stopped 'cuz no xmit buffer
> 23057 tx frames with no ack marked
> 1182 rx failed 'cuz of bad CRC
> 761604 rx failed 'cuz of PHY err
> 761604 OFDM timing
> 4829 periodic calibrations
> 28 rssi of last ack
> 27 avg recv rssi
> -96 rx noise floor
> 1 switched default/rx antenna
> Antenna profile:
> [1] tx 15660942 rx 19451935
> [2] tx2 rx0
>
> ...
>
>
> I use this ping command from R2:
> ping -i .002 -c 1 -s 1472 opposite side R1
>
> --- R1 ping statistics ---
> 1 packets transmitted, 1 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 1.316/1.442/49.391/1.757 ms
>
> You can see nice average latency about 1,4 ms and no one packet was lost.
>
> athstats almost wasn´t changed.
>
> 19309465 data frames received
> 15724079 data frames transmit
> 6536 tx frames with an alternate rate
> 2188281 long on-chip tx retries
> 62583 tx failed 'cuz too many retries
> 348 tx linearized to cluster
> 24M current transmit rate
> 6 tx management frames
> 6 tx frames discarded prior to association
> 27129 tx stopped 'cuz no xmit buffer
> 23075 tx frames with no ack marked
> 1182 rx failed 'cuz of bad CRC
> 761605 rx failed 'cuz of PHY err
> 761605 OFDM timing
> 4834 periodic calibrations
> 29 rssi of last ack
> 27 avg recv rssi
> -96 rx noise floor
> 1 switched default/rx antenna
> Antenna profile:
> [1] tx 15661485 rx 19452488
> [2] tx2 rx0
>
> For compare with flood ping at once:
>
> --- R1 ping statistics ---
> 1 packets transmitted, 1 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 1.319/1.516/5.594/0.120 ms
>
> Almost the same, yes max is even better.
>
>
> --
>
> If I use interval 1/1000 s to send the echo request, the situation is
> rapidly changed.
> ping -i .001 -c 1 -s 1472 opposite side R1
>
> --- R1 ping statistics ---
> 1 packets transmitted, 9681 packets received, 3% packet loss
> round-trip min/avg/max/stddev = 1.319/335.806/564.946/170.691 ms
>
> R2# ifconfig -v ath0
> ath0: flags=8c43 mtu 1500
> -- ??? OACTIVE FLAG ?
> inet6 fe80::20b:6bff:fe2a:c78e%ath0 prefixlen 64 scopeid 0x2
> inet 10.XX.YY.ZZ netmask 0xfffc broadcast 10.40.64.19
> ether
> media: IEEE 802.11 Wireless Ethernet OFDM/24Mbps mode 11a
> (OFDM/24Mbps)
> status: associated
>
> 19350739 data frames received
> 15765446 data frames transmit
> 6536 tx frames with an alternate rate
> 2194842 long on-chip tx retries
> 62590 tx failed 'cuz too many retries
> 348 tx linearized to cluster
> 24M current transmit rate
> 6 tx management frames
> 6 tx frames discarded prior to association
> 29242 tx stopped 'cuz no xmit buffer
> 23155 tx frames with no ack marked
> 1182 rx failed 'cuz of bad CRC
> 764641 rx failed 'cuz of PHY err
> 764641 OFDM timing
> 4856 periodic calibrations
> 28 rssi of last ack
> 27 avg recv rssi
> -96 rx noise floor
> 1 switched default/rx antenna
> Antenna profile:
> [1] tx 15702845 rx 19493774
> [2] tx2 rx0
>
> I observe flags of ath and when latency is going to high more and more,
> there is a new flag which I´ve never seen before, OACTIVE FLAG ?
>
> R2# man ifconfig | grep "OACTIVE"
>
> When ping ends oactive flag disappears.
>
> When the same ping test is done from linux box to fbsd, nice latency 1,2ms
> and no "no buffer".
>
> with -i 0.002 the throughput is about 0,5MB/s in and out of cource
>
> with -i 0.001 until no buffer is about 0,85MB/s in and out.
>
> when no buffer and octive appears, the throughput is about 0,1MB/s or
> 128KB/s if you like or 1Mbit/s.
>
> I attached the progress of pinging ip address.
You ask why you're seeing OACTIVE when you lower the inter-packet wait
time to ping. This is because you're flooding the tx queue of the ath
driver and using up all the tx buffers/descriptors. When ath is handed
a frame to send and it has no resources available it will mark the
interface "active' (OACTIVE) and drop the packet. You can also see this
in the athstats output ("tx stopped 'cuz no xmit buffer"). Linux
behaves differently because it blocks the user process when this happens
until such time as there are resources to do the send. This behaviour
likely also explains the variability in the ping times; I think the rx
processing may be deferred while the driver deals with the tx flood.
You can up the number o
Re: atheros driver under high load, panics and even more freezes
Daniel Dvoøák wrote: > Hi all, > > first of all, I´m sorry maybe for my bad English. > > We have 2 routers which I maintain in our mesh wireless community network. > > The Router 1 has 2 atheros adapters, ath0=wistron cm9, ath1=wistron cm10, of > course some sisX, fxpX and so on. > The Router 2 has 1 atheros adapter, ath1=wistron CM10. > > My R1 panics and even more it freezes very often. Maybe the reason for > panicing and freezing is the same and maybe not. > > I started (only after vmcore.5, so vmcore.6 is with this option) to use > "option SW_WATCHDOG" in both my custom kernels on the R1 and R2 recently in > hope, it is some walkaround for freezing at least if not for panicing. > > This router was installed on the 1st of April 2006. > > Statistics: > > 9 panics with 8 kernel dumps, 1 missed > > 10 freezes > > I think that all panics some how connected to athX taskq process, page fault > in kernel panic and sbflush_locked. Why? > > I guess that panic comes when router transmits and receives datas at the > maximum throughput for setted nominal media rate speed, exactly 24Mbps, more > I do not use, because there are problems with quagga > > ospfd packets, it is known issue. > > Today I did a small test with throughput. > > Router 1 executed this command: > > # ping -i 0.001 -c 10 -s 1472 ANY IP > > As you see, it is not even flood ping, it is almost flood, but not flood. > > Throughput was about 1,13-1,2 MB/s as bmon showed me. I notice there is not > any qos and icmp.limit is so high net.inet.icmp.icmplim: 2147483647 > net.ineticmp.icmplim_output: 0. > > > First 5 s latency was about 1,1-1,7 ms > After it goes to 10-30, 50-70, 110-130, 270-300, up 300ms and packet loss > > some seconds > > panic <...lots of stuff deleted...> Sounds like a resource leak to me. You've got crash dumps, look at memory usage with vmstat and/or netstat. Past that it sounds like you're running 6.1 RELEASE which is now 6+ months old. Many bugs have been fixed including, I believe, some resource-related ones. Please try 6-STABLE. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: atheros driver under high load, panics and even more freezes
Ok, I will upgrade my boxes and I will do simple ping tests again. Did you see my sysctl.conf file ? I mean these options: kern.ipc.maxsockbuf=2097152 net.inet.ip.fastforwarding=1 net.inet.tcp.sendspace=65536 Could be this connected with increasing latency up to 500ms ? I tested this issue on another box, box of my friend, you know him too. --- 10.27.128.13 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.932/1.101/9.657/0.433 ms There is nice avg 1,1ms. In his sysctl.conf, there are not these maxsockbuf, fastforwarding and sendscpace. It is ironic, because it was he, who advised me these values. You wrote me "look at memory usage with vmstat and/or netstat". Ok, bud you did not told me what I should to search for ... And I do not know how the command write with vmstat and netstat, there are many switches. :) What to find ? Thank you. Daniel > -Original Message- > From: Sam Leffler [mailto:[EMAIL PROTECTED] > Sent: Saturday, September 02, 2006 6:00 AM > To: [EMAIL PROTECTED] > Cc: freebsd-stable@freebsd.org; [EMAIL PROTECTED] > Subject: Re: atheros driver under high load, panics and even > more freezes > > Daniel Dvoøák wrote: > > Hi all, > > > > first of all, I´m sorry maybe for my bad English. > > > > We have 2 routers which I maintain in our mesh wireless > community network. > > > > The Router 1 has 2 atheros adapters, ath0=wistron cm9, ath1=wistron > > cm10, of course some sisX, fxpX and so on. > > The Router 2 has 1 atheros adapter, ath1=wistron CM10. > > > > My R1 panics and even more it freezes very often. Maybe the > reason for > > panicing and freezing is the same and maybe not. > > > > I started (only after vmcore.5, so vmcore.6 is with this > option) to > > use "option SW_WATCHDOG" in both my custom kernels on the R1 and R2 > > recently in hope, it is some walkaround for freezing at > least if not for panicing. > > > > This router was installed on the 1st of April 2006. > > > > Statistics: > > > > 9 panics with 8 kernel dumps, 1 missed > > > > 10 freezes > > > > I think that all panics some how connected to athX taskq > process, page > > fault in kernel panic and sbflush_locked. > > Why? > > > > > I guess that panic comes when router transmits and receives > datas at > > the maximum throughput for setted nominal media rate speed, exactly > > 24Mbps, more I do not use, because there are problems with quagga > > > > ospfd packets, it is known issue. > > > > Today I did a small test with throughput. > > > > Router 1 executed this command: > > > > # ping -i 0.001 -c 10 -s 1472 ANY IP > > > > As you see, it is not even flood ping, it is almost flood, > but not flood. > > > > Throughput was about 1,13-1,2 MB/s as bmon showed me. I > notice there > > is not any qos and icmp.limit is so high net.inet.icmp.icmplim: > > 2147483647 > > net.ineticmp.icmplim_output: 0. > > > > > > First 5 s latency was about 1,1-1,7 ms After it goes to > 10-30, 50-70, > > 110-130, 270-300, up 300ms and packet loss > > > > some seconds > > > > panic > > <...lots of stuff deleted...> > > Sounds like a resource leak to me. You've got crash dumps, > look at memory usage with vmstat and/or netstat. Past that > it sounds like you're running 6.1 RELEASE which is now 6+ > months old. Many bugs have been fixed including, I believe, > some resource-related ones. Please try 6-STABLE. > > Sam > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: atheros driver under high load, panics and even more freezes
Daniel Dvořák wrote: > Ok, I will upgrade my boxes and I will do simple ping tests again. > > Did you see my sysctl.conf file ? > > I mean these options: > > kern.ipc.maxsockbuf=2097152 > net.inet.ip.fastforwarding=1 > net.inet.tcp.sendspace=65536 > > Could be this connected with increasing latency up to 500ms ? Seems unlikely but I have little to go on. You can easily identify whether the delays are in the OS or due to wireless issues by sniffing traffic. Tools like athstats are also important for diagnosing problems. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Where is the maximum of hw.ath.txbuf and rxbuf ? (former: atheros driver under high load, panics and even more freezes)
Hi Sam, thank you for your answer. I think it is connected to this problem somehow, but not fully. I increased txbuf and rxbuf twice to 200 and 80, I saw some betterment in less of "no buffers space ...", but latency went up to 2000 ms. Now I ended at txbuf=800 and rxbuf=320 on both sides R1 and R2. But still, there is the same problem: It was tested after the rebooting R2 almost at once. --- R1 ping statistics --- 1 packets transmitted, 8752 packets received, 12% packet loss round-trip min/avg/max/stddev = 1.324/920.480/6323.454/766.399 ms up to 6k ms R2# athstats -i ath0 11309 data frames received 11384 data frames transmit 12508 long on-chip tx retries 769 tx failed 'cuz too many retries 24M current transmit rate 2 tx management frames 6 tx frames discarded prior to association 31 tx stopped 'cuz no xmit buffer 38 tx frames with no ack marked 3 rx failed 'cuz of bad CRC 4464 rx failed 'cuz of PHY err 4464 OFDM timing 24 periodic calibrations 27 rssi of last ack 27 avg recv rssi -96 rx noise floor 1 switched default/rx antenna Antenna profile: [1] tx10614 rx11449 Where is the maximum of txbuf and rxbuf ? I would like to test it. Thank you for your attention. Daniel > -Original Message- > From: Sam Leffler [mailto:[EMAIL PROTECTED] > Sent: Friday, September 08, 2006 6:30 AM > To: [EMAIL PROTECTED] > Cc: freebsd-stable@freebsd.org > Subject: Re: atheros driver under high load, panics and even > more freezes > > Daniel Dvoøák wrote: > > Hi Sam and all, > > > > I am not sure if I understand your answer, but I try it. > > > > When I use start my test, athstats shows this: > > > > athstats -i ath0 > > > > 19308912 data frames received > > 15723536 data frames transmit > > 6536 tx frames with an alternate rate > > 2188280 long on-chip tx retries > > 62583 tx failed 'cuz too many retries > > 348 tx linearized to cluster > > 24M current transmit rate > > 6 tx management frames > > 6 tx frames discarded prior to association > > 27129 tx stopped 'cuz no xmit buffer > > 23057 tx frames with no ack marked > > 1182 rx failed 'cuz of bad CRC > > 761604 rx failed 'cuz of PHY err > > 761604 OFDM timing > > 4829 periodic calibrations > > 28 rssi of last ack > > 27 avg recv rssi > > -96 rx noise floor > > 1 switched default/rx antenna > > Antenna profile: > > [1] tx 15660942 rx 19451935 > > [2] tx2 rx0 > > > > ... > > > > > > I use this ping command from R2: > > ping -i .002 -c 1 -s 1472 opposite side R1 > > > > --- R1 ping statistics --- > > 1 packets transmitted, 1 packets received, 0% packet loss > > round-trip min/avg/max/stddev = 1.316/1.442/49.391/1.757 ms > > > > You can see nice average latency about 1,4 ms and no one > packet was lost. > > > > athstats almost wasn´t changed. > > > > 19309465 data frames received > > 15724079 data frames transmit > > 6536 tx frames with an alternate rate > > 2188281 long on-chip tx retries > > 62583 tx failed 'cuz too many retries > > 348 tx linearized to cluster > > 24M current transmit rate > > 6 tx management frames > > 6 tx frames discarded prior to association > > 27129 tx stopped 'cuz no xmit buffer > > 23075 tx frames with no ack marked > > 1182 rx failed 'cuz of bad CRC > > 761605 rx failed 'cuz of PHY err > > 761605 OFDM timing > > 4834 periodic calibrations > > 29 rssi of last ack > > 27 avg recv rssi > > -96 rx noise floor > > 1 switched default/rx antenna > > Antenna profile: > > [1] tx 15661485 rx 19452488 > > [2] tx2 rx0 > > > > For compare with flood ping at once: > > > > --- R1 ping statistics --- > > 1 packets transmitted, 1 packets received, 0% packet loss > > round-trip min/avg/max/stddev = 1.319/1.516/5.594/0.120 ms > > > > Almost the same, yes max is even better. > > > > > -- > > -- > > -- > > > > If I use interval 1/1000 s to send the echo request, the > situation is > > rapidly changed. > > ping -i .001 -c 1 -s 1472 opposite side R1 > > > > --- R1 ping statistics --- > > 1 packets transmitted, 9681 packets received, 3% packet loss > > round-trip min/avg/max/stddev = 1.319/335.806/564.946/170.691 ms > > > > R2# ifconfig -v ath0 > > ath0: > flags=8c43 mtu > > 1500 > > --
Re: Where is the maximum of hw.ath.txbuf and rxbuf ? (former: atheros driver under high load, panics and even more freezes)
Daniel Dvořák wrote: > Hi Sam, > > thank you for your answer. I think it is connected to this problem somehow, but not fully. > > I increased txbuf and rxbuf twice to 200 and 80, I saw some > betterment in less of "no buffers space ...", but latency went up to 2000 ms. > > Now I ended at txbuf=800 and rxbuf=320 on both sides R1 and R2. > > But still, there is the same problem: > > It was tested after the rebooting R2 almost at once. > > --- R1 ping statistics --- > 1 packets transmitted, 8752 packets received, 12% packet loss > round-trip min/avg/max/stddev = 1.324/920.480/6323.454/766.399 ms > up to 6k ms > > R2# athstats -i ath0 > 11309 data frames received > 11384 data frames transmit > 12508 long on-chip tx retries > 769 tx failed 'cuz too many retries > 24M current transmit rate > 2 tx management frames > 6 tx frames discarded prior to association > 31 tx stopped 'cuz no xmit buffer > 38 tx frames with no ack marked > 3 rx failed 'cuz of bad CRC > 4464 rx failed 'cuz of PHY err > 4464 OFDM timing > 24 periodic calibrations > 27 rssi of last ack > 27 avg recv rssi > -96 rx noise floor > 1 switched default/rx antenna > Antenna profile: > [1] tx10614 rx11449 > > > Where is the maximum of txbuf and rxbuf ? The max is derived from available memory. The h/w has no upper bounds. > > I would like to test it. > > Thank you for your attention. > > Daniel > > >> -Original Message- >> From: Sam Leffler [mailto:[EMAIL PROTECTED] >> Sent: Friday, September 08, 2006 6:30 AM >> To: [EMAIL PROTECTED] >> Cc: freebsd-stable@freebsd.org >> Subject: Re: atheros driver under high load, panics and even >> more freezes >> >> Daniel Dvoøák wrote: >>> Hi Sam and all, >>> >>> I am not sure if I understand your answer, but I try it. >>> >>> When I use start my test, athstats shows this: >>> >>> athstats -i ath0 >>> >>> 19308912 data frames received >>> 15723536 data frames transmit >>> 6536 tx frames with an alternate rate >>> 2188280 long on-chip tx retries >>> 62583 tx failed 'cuz too many retries >>> 348 tx linearized to cluster >>> 24M current transmit rate >>> 6 tx management frames >>> 6 tx frames discarded prior to association >>> 27129 tx stopped 'cuz no xmit buffer >>> 23057 tx frames with no ack marked >>> 1182 rx failed 'cuz of bad CRC >>> 761604 rx failed 'cuz of PHY err >>> 761604 OFDM timing >>> 4829 periodic calibrations >>> 28 rssi of last ack >>> 27 avg recv rssi >>> -96 rx noise floor >>> 1 switched default/rx antenna >>> Antenna profile: >>> [1] tx 15660942 rx 19451935 >>> [2] tx2 rx0 >>> >>> ... >>> >>> >>> I use this ping command from R2: >>> ping -i .002 -c 1 -s 1472 opposite side R1 >>> >>> --- R1 ping statistics --- >>> 1 packets transmitted, 1 packets received, 0% packet loss >>> round-trip min/avg/max/stddev = 1.316/1.442/49.391/1.757 ms >>> >>> You can see nice average latency about 1,4 ms and no one >> packet was lost. >>> athstats almost wasn´t changed. >>> >>> 19309465 data frames received >>> 15724079 data frames transmit >>> 6536 tx frames with an alternate rate >>> 2188281 long on-chip tx retries >>> 62583 tx failed 'cuz too many retries >>> 348 tx linearized to cluster >>> 24M current transmit rate >>> 6 tx management frames >>> 6 tx frames discarded prior to association >>> 27129 tx stopped 'cuz no xmit buffer >>> 23075 tx frames with no ack marked >>> 1182 rx failed 'cuz of bad CRC >>> 761605 rx failed 'cuz of PHY err >>> 761605 OFDM timing >>> 4834 periodic calibrations >>> 29 rssi of last ack >>> 27 avg recv rssi >>> -96 rx noise floor >>> 1 switched default/rx antenna >>> Antenna profile: >>> [1] tx 15661485 rx 19452488 >>> [2] tx2 rx0 >>> >>> For compare with flood ping at once: >>> >>> --- R1 ping statistics --- >>> 1 packets transmitted, 1 packets received, 0% packet loss >>> round-trip min/avg/max/stddev = 1.319/1.516/5.594/0.120 ms >>> >>> Almost the same, yes max is even better. >>> >>> >> --
