How do you manually set the ack-timeout value with an rb532 and an xr2 card.
Thanks

I have looked in the manual and normally leave this setting on dynamic but I had UBNT take a look at one of my setups yesterday and he set it to 56. I was available when they did this and I have been unable to find where you set this.
Thanks

----
hai
how to set manuall ack-timeout try this i suggest you to check datasheet that card first before set it, and that sample code with 56 value

regards
Hasbullah.com
----

thanks for the reply. it works. however i realized that it just takes a while for it to lower the ack-timeout to a normal reading. When you first start the radio it will show somewhere around 400 and then level out around 60. But thanks again for the good info.

ack timeout is calculated on each association when ack-timeout=dynamic.
A little bit of packet loss can leave it at an unreasonable high ack-timeout, giving really poor performance.
ack-timeout=dynamic is meant to be used when you initially setup the link and should be fixed at the suggested ack-timeout.
the ack-timeout is different in each "band" and different for each channel width (5mhz, 10mhz, 20mhz, 40mhz). it is also different depending on the distance of the link.

Thanks for the extra info on that although I already knew what it was for I was unable to change it in mikrotik.

The more I learn today the less I have to do tomorrow. At least its a nice thought. haha

Hi sten.
I know that ack timeout was only dependent on distance between the two sites, but you wrote:
the ack-timeout is different in each "band" and different for each channel width (5mhz, 10mhz, 20mhz, 40mhz)

Can you explaint it better?

Thanks

try this;

we have wireless router A connected to wireless router B via a 10 km 802.11a (20mhz) link. set the ack timeout on both sides.

then change the link to "turbo" (40mhz) mode. (it still should work)

then change ack timeout to dynamic, read the ack-timeouts and set the new ack-timeout values to the suggested ones.
they will be lower by this point (roughly half)

then change wireless mode back to regular 802.11a (20mhz) link.

does it still work?

I can't try this soon, but i will remember next time i will put my hand on a 5GHz backhaul.

Thanks

P.S.
Do you know what causes this behaviour (theory)?

basically;
If ACK packets where on the link layer, it would not have mattered, but ACKs are on L2.

Yes, i know that ack are on L2, but my request was a phisical (or theoretical) explanation of this "phenomenon", if you know it.

Thanks

I just noticed a correlation between the ACK and the atheros/prism association problem.

When the problem is occurring, on the AP.. look at your ACK value under status..

from the previous post it was stated
ack timeout is calculated on each association when ack-timeout=dynamic.
A little bit of packet loss can leave it at an unreasonable high ack-timeout, giving really poor performance.
ack-timeout=dynamic is meant to be used when you initially setup the link and should be fixed at the suggested ack-timeout

on a problem node I see the Ack value at 90.. on a working node I see the ack value at 53
after a few minutes of the card being enabled it finds the ACK it seems to stick on a number

when the problem of NO cpes can connect the Ack value is way high.. mine currently is setting at 349

after disabling and -re-enalbing the card a 1000 times.. the act value goes to a normal rate of around 50..

so is the problem related to the dynamic ack ? or is the ack a byproduct of the problem.

well yes. dynamic-ack only works against Atheros, AFAIK
I sort of worked on a PRISM based PLC client antenna a couple of years ago and back then dynamic ack (on routeros) never worked for the PRISM chips. It had random results. We had to calculate the max distance by hand to be able to connect PRISM cards.
Which is the main reason i say; do not leave ack-timeout at dynamic.
Try 56 and work your way upwards. We used 80 (~6 km) as the default on 802.11b.
It's almost always better with a positive margin than a negative one.

to clarify.

ack-timeout=dynamic did not work on the AP which was routeros.
the PLC/PRISM antenna had no concept of dynamic ack timeout.
And since the AP calculated the ACK timeout by gradually decrease ACK timeout during association, it usually failed miserably.
Might be wrong, it's been 3 years!
Just as a side note. Leaving ack-timeout at a static 80 usually did the trick for clients closer than 3-4 km's. It still works today.

Sten,

I have been following this problem for quite a while and have been waiting for a solution before really launching several new AP's. Let me make sure I understand you. You are saying that if we set the Ack-Timeout to a fixed amount, say 53 or something like that, maybe up to 80 then this whole problem of clients dropping off and not reassociating is cleared up. You mention 3 years, have you been doing this sucessfully for 3 years now? If this is the answer and I hope it is, the you have saved the day. I have already changed a couple of AP's and have not had a single deauth in the log. This has been since last night when I read your post.

Thank you for sharing this.

Steve Loomis
Vroomwireless Inc

I have been following this problem for quite a while and have been waiting for a solution before really launching several new AP's. Let me make sure I understand you. You are saying that if we set the Ack-Timeout to a fixed amount, say 53 or something like that, maybe up to 80 then this whole problem of clients dropping off and not reassociating is cleared up. You mention 3 years, have you been doing this sucessfully for 3 years now? If this is the answer and I hope it is, the you have saved the day. I have already changed a couple of AP's and have not had a single deauth in the log. This has been since last night when I read your post.

Yes, the PRISM antenna i'm currently looking at has been connected for 13 days (AP reboot), it was installed atleast 2 years and 8 months ago (as that was when the last PRISM based client antenna was installed). It has been in active operation since then.

EDIT: AP is version 2.9.26 and ack-timeout is 80

when I look at my senao prism card in one of my APs running 2.9.29, and I see no ack-timeout anywhere, the field does not show up on the advance tab, and the status is blank.

here is my atheros, it shows the ack
name="wlan4" mtu=1500 mac-address=00:0B:6B:34:33:E2 arp=enabled
disable-running-check=no interface-type=Atheros AR5213 radio-name="000B6B3433E2"
mode=station ssid="MVRE" area="" frequency-mode=manual-txpower
country=no_country_set antenna-gain=0 frequency=5745 band=5ghz scan-list=default
rate-set=default supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps
supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps
basic-rates-b=1Mbps basic-rates-a/g=6Mbps max-station-count=2007
ack-timeout=dynamic tx-power-mode=default noise-floor-threshold=default
periodic-calibration=default periodic-calibration-interval=60 burst-time=disabled
dfs-mode=none antenna-mode=ant-a wds-mode=disabled wds-default-bridge=none
wds-default-cost=100 wds-cost-range=50-150 wds-ignore-ssid=no
update-stats-interval=disabled default-authentication=yes default-forwarding=no
default-ap-tx-limit=0 default-client-tx-limit=0 proprietary-extensions=pre-2.9.25
hide-ssid=no security-profile=default disconnect-timeout=3s
on-fail-retry-time=100ms preamble-mode=both compression=no allow-sharedkey=no

here is my prism
notice no ack
name="wlan2" mtu=1500 mac-address=00:02:6F:35:30:3E arp=enabled
disable-running-check=no interface-type=Prism prism-cardtype=200mW
radio-name="00026F35303E" mode=ap-bridge ssid="SurfnetAP6" area=""
frequency-mode=manual-txpower country=no_country_set antenna-gain=0 frequency=2457
band=2.4ghz-b scan-list=default rate-set=default
supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps basic-rates-b=1Mbps
max-station-count=2007 IT SHOULD BE HEREtx-power-mode=default periodic-calibration=default
periodic-calibration-interval=60 dfs-mode=none antenna-mode=ant-a
wds-mode=disabled wds-default-bridge=none wds-default-cost=100
wds-cost-range=50-150 wds-ignore-ssid=no update-stats-interval=disabled
default-authentication=yes default-forwarding=no default-ap-tx-limit=0
default-client-tx-limit=0 proprietary-extensions=pre-2.9.25 hide-ssid=no
security-profile=default disconnect-timeout=3s on-fail-retry-time=100ms
compression=no allow-sharedkey=no

I just went to a problem node with an atheros AP. I looked and the ack was 346.
I then with to the reg table double clicked on each client and looked at their ack.
Most of the clients had an ack value in the 30-50 range. I found the one that had an ack of 346 and clicked 'copy to access list'.. which basically resets his connection and it resets their ACK as well. It went to 50.. but the AP interface went to 254, I then looked for the client that was at 254 and reset him. I did this over and over again till I found all the high ack clients.
Now my AP interface ACK read 53.


question: did I improve performance? I feel like I must have.. but only time will tell.
and should I llok at all the APs for this issue? Perhaps MK should have a periodic ack check on clients, if this is indeed an issue.

ack-timeout=dynamic is only meant to be used during installation of a link.
i'm sure you could script something, but;
what would you regard your maximum to be?
why didn't you set it to that value in the first place?
how will you enforce the client side ack-timeout?

without ack-timeout setting on clients and AP, you will experience very poor performance for links that are longer than ~4 km's, depending on the firmware. if a link is longer than the (prism hardcoded?) ack-timeout then every packet that this station (or AP) will transmit, will essentially be retransmitted X number of times, even though the first was accepted.
but perhaps none of your links are longer than that?

I don't think that you can set ack-timeout on a tranzeo tr-cpe-200. If so I don't know how. Every setting is done with web gui and there isn't any distance or ack setting in there. Now what?

<< read the ack-timeouts and set the new ack-timeout values to the suggested ones. >>

And what if the CPE is not showing the current ack-timeout???
I just looked and 50% of our Mikrotik CPE have the current ack blank (set to default in setting, but displaying blank in monitoring)...

???

SMA

To my knowledge this is not something you can change on prism cards.

Ours are all Atheros (SR2/SR5), and 50% of them are not displaying the current ack.

SMA

My SR9 in B mode doesn't show ACK timing either. I thought ACK timing wasn't included in B mode. Is Sten correct above?

ACK timing applies to *all* non-proprietary 802.11 (a/b/g/n) except under certain WMM modes.

When you *set* the ack-timeout then ack-timeout wont be displayed under "status".
It will only be displayed when ack-timeout=dynamic

I've never used PRISM in an AP.

Both our AP and CPE are set to dynamic, and status is not displaying the current ack value.


SMA

PRISM does not support setting ACK timeouts AFAIK.
But if ack-timeout does not show up on Atheros based ack-timeout=default then there might be an explanation for it.

Please do a;

/ interface wireless info print
/ interface wireless registration print stats

just remove last-ip and radio-name if you feel that is necessary

[admin@xxxxxxxxxxxxxxx] > / interface wireless info print
0 interface-type=Atheros AR5213
chip-info="mac:0x5/0x9, phy:0x43, a5:0x46, a2:0x0, eeprom:0x4008"
pci-info="00:01.0" capabilities=tx-power-control,ack-timeout-control,
virtual-ap,alignment-mode,noise-floor-
control,scanning,burst-support,nstreme,
sniffing,compression,power-channel
default-periodic-calibration=enabled
supported-bands=2ghz-b,2ghz-g,2ghz-g-turbo,2ghz-10mhz,2ghz-5mhz
2ghz-b-channels=2412:0,2417:0,2422:0,2427:0,2432:0,2437:0,2442:0,2447:0,
2452:0,2457:0,2462:0
2ghz-g-channels=2412:0,2417:0,2422:0,2427:0,2432:0,2437:0,2442:0,2447:0,
2452:0,2457:0,2462:0
2ghz-g-turbo-channels=2437:0
2ghz-10mhz-power-channels=2412:0,2417:0,2422:0,2427:0,2432:0,2437:0,2442:0,
2447:0,2452:0,2457:0,2462:0
2ghz-5mhz-power-channels=2412:0,2417:0,2422:0,2427:0,2432:0,2437:0,2442:0,
2447:0,2452:0,2457:0,2462:0



[admin@xxxxxxxxxxxxxxxxxxxxxxx] > / interface wireless registration print stats
0 interface=wlan1 radio-name="00156D5398BB" mac-address=00:15:6D:53:98:BB
ap=yes wds=no rx-rate=12Mbps tx-rate=12Mbps packets=3891258,5260099
bytes=551220745,3327631321 frames=3891258,5266312
frame-bytes=527911393,3296163392 hw-frames=3891258,5266326
hw-frame-bytes=636866617,3464685740 uptime=5d14h36m27s last-activity=10ms
signal-strength=-64dBm@6Mbps signal-to-noise=38dB
strength-at-rates=-64dBm@6Mbps 70ms,-63dBm@9Mbps 5s420ms,-64dBm@12Mbps
70ms
tx-signal-strength=-66dBm tx-ccq=47% rx-ccq=36% p-throughput=9920
nstreme=no framing-mode=none routeros-version="2.9.38" last-ip=xxxxxxxxxx
802.1x-port-enabled=yes authentication-type=none encryption=none
compression=no


I have about 10 more of these atleast that don't show current ack either, all with various versions of RouterOS from 2.9.3x to 2.9.4x...

SMA

if this AP interface has ack-timeout=dynamic then there is probably a bug in that version.

That output was from a CPE that I posted.

Do you need the output from the AP serving that CPE?

SMA

no, as long as ack-timeout=dynamic was set.

Sten,

can you please tell us what ack-timeout value we should use for 2-b/g/10/5 bands for different distances, is there any specific formulae we should follow?

can you guide and elaborate on this a little more.

regards

a table is here; http://www.mikrotik.com/testdocs/ros/2. ... reless.php

and for theory: http://c3lab.poliba.it/images/7/71/Optimization.pdf

Sten:
Do you set the ack timeout on the ap as well? Or is it left at dynamic? If you set it is it set to the maximum distance you are willing to serve clients from that particular AP?

We have some sr9 clients that we use dynamic as well as use dynamic between our backhaul ends. sounds like setting it may improve our performance.

do you see what the client connects to the ap initially and then set the client accordingly or do you go by the table on the mikrotik manual?

KEnny

.
.
.
I have about 10 more of these atleast that don't show current ack either, all with various versions of RouterOS from 2.9.3x to 2.9.4x...

SMA

If you set the ack-timeout value to something besides dynamic, the reg stats won't show ack or distance on any of the clients or the AP. Not sure if this is intentional or not, but have noticed this recently.

ALL of ours are set to dynamic, and random ones do not show the current ack in the reg stats of the CPE or the AP. No rhyme or reason to it that I can find, some versions have working ones and non-working ones, all the same cards, same settings, same frequencies, same hardware/routerboard, etc---completely random as far as I can tell.

SMA

I would like to know the best setup about multipoint system with 40 clients. The clients are at around 5-10km.
All the clients are configured at ack-timeout=dynamics and I use polling and nstream.

My Ap show me that it is using 25, but I dubt it is the best value. I owuld like to go with a fix value. what is your advice?

Regards

under nstreme it is not necessary to set ack timeout. just leave it as dynamic.

thank you.

Ros

i have a 67 link in 5805 and xr5 cards, whitch ack-timeout can you suggest me??
thanks

i suggest you google and rtfm the subject.

he he he very good men !!!!!!!!

We have not found a solution to this, and no common reasoning.
Looks to be yet another bug in the Mikrotik system.

SMA

Does the suggested static ack timout setting change based on the number of subs on an AP?

for example i have given my ack-timeout value 230, which according the manual would be 25kms +15ms for wireless G.

my tower is pushing 70 subs and forced to 11m b only, would i need to make adjustments that deviate from the manual suggested settings?