Manual:Wireless FAQ: Difference between revisions

From MikroTik Wiki
Jump to navigation Jump to search
 
(15 intermediate revisions by 5 users not shown)
Line 7: Line 7:
====By changing some wireless settings the wireless link works unstable====
====By changing some wireless settings the wireless link works unstable====


Sometimes when you change some wireless setting for tuning the links you got so far that the link isn't establishing any more or works unstable and you don't remember what settings you had in the beginning. In this case you can use the ''reset-configuration'' command in the wireless menu - it will reset the all the wireless settings for the specific wireless interface and you will be able to configure the interface from the start. Note that executing this command also disables the interface, so please be careful not to execute this command if you are configuring router remotely using that wireless link that you want to reset the configuration.
Sometimes when you change some wireless setting for tuning the links you got so far that the link isn't establishing any more or works unstable and you don't remember what settings you had in the beginning. In this case, you can use the ''reset-configuration'' command in the wireless menu - it will reset the all the wireless settings for the specific wireless interface and you will be able to configure the interface from the start. Note that executing this command also disables the interface, so please be careful not to execute this command if you are configuring router remotely using that wireless link that you want to reset the configuration.


====What are wireless retransmits and where to check them?====
====What are wireless retransmits and where to check them?====


Wireless retransmission is when the card sends out a frame and you don't receive back the acknowledgment (ACK), you send out the frame once more till you get back the acknowledgment. Wireless retransmits can increase the latency and also lower the throughput of the wireless link.
Wireless retransmission occur when an interface sends out a frame and doesn't receive back an acknowledgment (ACK), causing it to try sending the frame again until an acknowledgment is received or the maximum allowed retransmission count for a packet is reached. Wireless retransmits increase the latency and lower the throughput of a wireless link.
To check if the wireless connection has wireless retransmissions you need to compare two fields in the wireless registration table: '''frames''' and '''hw-frames'''. If the ''hw-frames'' value is bigger than ''frames'' value then it means that the wireless link is making retransmissions. If the difference is not so big, it can be ignored, but if the ''hw-frames'' count it two, three or four times or even bigger than the ''frames'' count then you need to troubleshoot this wireless connection.
The number of retransmissions taking place can be determined by subtracting the value of the '''frames''' parameter from the value of the 'hw-frames''' parameter for a given entry in the registration table. Some number of retransmissions is to be expected, but if the value of '''frames''' exceeds the value of '''frames''' multiple times, there is an issue with the wireless link that requires troubleshooting.


====Can I compare frames with hw-frames also on Nstreme links?====
====Can I compare frames with hw-frames also on Nstreme links?====


The '''frames''' counts only those which contain actual data. In case of Nstreme, only the ACK can be transmitted in a single frame, if there is no other data to send. These ACK frames will not be added to the '''frames''' count, but they will appear at '''hw-frames'''. If there is traffic on both directions at maximum speed (eg. there will be no only-ack frames), then you can't compare '''frames''' to '''hw-frames''' as in case of regular wireless links.
The '''frames''' counts only those which contain actual data. In the case of Nstreme, only the ACK can be transmitted in a single frame, if there is no other data to send. These ACK frames will not be added to the '''frames''' count, but they will appear at '''hw-frames'''. If there is traffic on both directions at maximum speed (eg. there will be no only-ack frames), then you can't compare '''frames''' to '''hw-frames''' as in case of regular wireless links.


====What TX-power values can I use?====
====What TX-power values can I use?====
Line 22: Line 22:
The tx-power default setting is the maximum tx-power that the card can use and is taken from the cards eeprom. If you want to use larger tx-power values, you are able to set them, but '''do it at your own risk''', as it will probably damage your card eventually! Usually, one should use this parameter only to reduce the tx-power.
The tx-power default setting is the maximum tx-power that the card can use and is taken from the cards eeprom. If you want to use larger tx-power values, you are able to set them, but '''do it at your own risk''', as it will probably damage your card eventually! Usually, one should use this parameter only to reduce the tx-power.


In general tx-power controlling properties should be left at the default settings. Changing the default setting may help with some cards in some situations, but without testing, the most common result is degradation of range and throughput. Some of the problems that may occur are:  
In general, tx-power controlling properties should be left at the default settings. Changing the default setting may help with some cards in some situations, but without testing, the most common result is the degradation of range and throughput. Some of the problems that may occur are:  
* overheating of the power amplifier chip and the card which will cause lower efficiency and more data errors;
* overheating of the power amplifier chip and the card which will cause lower efficiency and more data errors;
* overdriving the amplifier which will cause more data errors;
* overdriving the amplifier which will cause more data errors;
Line 29: Line 29:
====What TX-power-mode is the best?====
====What TX-power-mode is the best?====


''TX-power-mode'' tells the wireless card which tx-power values should be used. By default this setting is set to ''default''.
''TX-power-mode'' tells the wireless card which tx-power values should be used. By default, this setting is set to ''default''.
* '''default''' means that the card will use the tx-power values from the cards eeprom and will ignore the setting what is specified by the user in the ''tx-power'' field.
* '''default''' means that the card will use the tx-power values from the cards eeprom and will ignore the setting what is specified by the user in the ''tx-power'' field.
* '''card-rates''' means that for different data rates the tx-power is calculated according the cards transmit power algorithm from the cards eeprom and as an argument it takes ''tx-power'' value specified by the user.
* '''card-rates''' means that for different data rates the tx-power is calculated according to the cards transmit power algorithm from the cards eeprom and as an argument it takes ''tx-power'' value specified by the user.
* '''all-rates-fixed''' means that that the card will use one tx-power value for all data rates which is specified by the user in ''tx-power'' field.
* '''all-rates-fixed''' means that that the card will use one tx-power value for all data rates which is specified by the user in ''tx-power'' field.
Note that it is not recommended to use 'all-rates-fixed' mode as the wireless card tx-power for the higher data rates is lower and by forcing to use the fixed tx-power rates also for the higher data rates might results the same problems like in the previous question about tx-power setting. For most of the cases if you want to change the tx-power settings it is recommended to use the ''tx-power-mode=card-rates'' and it is recommended to lower and not to raise tx-power.
Note that it is not recommended to use 'all-rates-fixed' mode as the wireless card tx-power for the higher data rates is lower and by forcing to use the fixed tx-power rates also for the higher data rates might result in the same problems like in the previous question about tx-power setting.  In the case of MikroTik Radio devices, the power will not be higher than the power written in the EEPROM. For most of the cases if you want to change the tx-power settings it is recommended to use the ''tx-power-mode=card-rates'' and it is recommended to lower and not to raise tx-power. In case of AR9300 and newer Atheros wireless chipsets "tx-power-mode=all-rate-fixed" is the only option as "card-rates" option isn't working on those chipsets.


====What is CCQ and how are the values determined?====
====What is CCQ and how are the values determined?====
Line 42: Line 42:
====What is hw-retries setting?====
====What is hw-retries setting?====


Number of times sending frame is retried without considering it a transmission failure. Data rate is decreased upon failure and frame is sent again. Three sequential failures on lowest supported rate suspend transmission to this destination for the duration of ''on-fail-retry-time''. After that, frame is sent again. The frame is being retransmitted until transmission success, or until client is disconnected after ''disconnect-timeout''. Frame can be discarded during this time if ''frame-lifetime'' is exceeded.
Number of times sending frame is retried without considering it a transmission failure. The data rate is decreased upon failure and frame is sent again. Three sequential failures on lowest supported rate suspend transmission to this destination for the duration of ''on-fail-retry-time''. After that, the frame is sent again. The frame is being retransmitted until transmission success, or until the client is disconnected after ''disconnect-timeout''. The frame can be discarded during this time if ''frame-lifetime'' is exceeded.
In case of Nstreme "on-fail-retry-time", "disconnect-timeout" and "frame-lifetime" settings are not used. So after three sequential failures on the lowest supported rate, the wireless link is disconnected with "extensive data loss" message.


====What is disconnect-timeout setting?====
====What is disconnect-timeout setting?====


This interval is measured from third sending failure on the lowest data rate. At this point 3 * (''hw-retries'' + 1) frame transmits on the lowest data rate had failed. During ''disconnect-timeout'' packet transmission will be retried with ''on-fail-retry-time'' interval. If no frame can be transmitted successfully during ''disconnect-timeout'', connection is closed, and this event is logged as "extensive data loss". Successful frame transmission resets this timer.
This interval is measured from the third sending failure on the lowest data rate. At this point 3 * (''hw-retries'' + 1) frame transmits on the lowest data rate had failed. During ''disconnect-timeout'' packet transmission will be retried with ''on-fail-retry-time'' interval. If no frame can be transmitted successfully during ''disconnect-timeout'', the connection is closed, and this event is logged as "extensive data loss". Successful frame transmission resets this timer.


====What is adaptive-noise-immunity setting?====
====What is adaptive-noise-immunity setting?====
Line 54: Line 55:
====How does wireless device measure signal strength, when access-list or connect-list are used ?====
====How does wireless device measure signal strength, when access-list or connect-list are used ?====


Reported signal level is exponentially weighted moving average with smoothing factor 50%.
The reported signal level is exponentially weighted moving average with a smoothing factor of 50%.


====What error correction  methods are supported in the RouterOS wireless?====
====What error correction  methods are supported in the RouterOS wireless?====


ARQ method is supported in nstreme protocols. Regular 802.11 standard does not include ARQ - retrasmission of corrupt frames is based on acknowledgement protocol.
ARQ method is supported in nstreme protocols. Regular 802.11 standard does not include ARQ - retransmission of corrupt frames is based on acknowledgment protocol.
RouterOS supports forward error correction coding (convolutional coding) with coding rates: 1/2, 2/3, or 3/4.
RouterOS supports forward error correction coding (convolutional coding) with coding rates: 1/2, 2/3, or 3/4.
====Configuring RouterOS device for 160MHz use====
If the RouterOS device supports 4x4 transmission, additionally to setting 160MHz channel width, make sure to set "rate-set=default" on the wireless interface so all streams are available
If the client does not support Extended NSS and can only perform 2x2 transmission, set "vht-supported-mcs=mcs0-9,mcs0-9,none"


=Setups=
=Setups=
Line 65: Line 71:
====Will an amplifier improve the speed on my link?====
====Will an amplifier improve the speed on my link?====


It depends on your signal quality and noise. Remember that you can probably get a better link with low output power setting, and a good antenna. Amplifier increases the noise and will only cause problems with the link.
It depends on your signal quality and noise. Remember that you can probably get a better link with low output power setting, and a good antenna. An amplifier increases the noise and will only cause problems with the link.


The amplifier gets a boost on both the transmitted '''and''' received signal. Thus, in "silent" areas, where you are alone or with very few "noise" or "competition", you might get excellent results. On the other side, in crowded areas, with lots of wireless activity, you will also increase signal received from every other competitor or noise source, which may dramatically lower the overall quality of the link. Also, take in account the EIRP to see if your link remains in legal limits.
The amplifier gets a boost on both the transmitted '''and''' received signal. Thus, in "silent" areas, where you are alone or with very few "noise" or "competition", you might get excellent results. On the other side, in crowded areas, with lots of wireless activity, you will also increase signal received from every other competitor or noise source, which may dramatically lower the overall quality of the link. Also, take in account the EIRP to see if your link remains in legal limits.


You could also get better signal on "11b only" radios, which see most of 802.11g as "noise", thus filtering better the usable signal.
You could also get a better signal on "11b only" radios, which see most of 802.11g as "noise", thus filtering better the usable signal.


====How to fine-tune the wireless link with hw-retries?====
====How to fine-tune the wireless link with hw-retries?====


You should understand that for 802.11 devices there is really limited amount of information (or "feedback" from the environment) that devices can use to tune their behavior:
You should understand that for 802.11 devices there is a really limited amount of information (or "feedback" from the environment) that devices can use to tune their behavior:


*signal strength, which could be used to figure out best transmit rate knowing receiver sensitivity. Sill this is not reliable taking into account that sensitivity for different receivers varies (e.g. changes over time), path conditions are not symmetric (and device can only measure signal strength it receives), etc.
*signal strength, which could be used to figure out best transmit rate knowing receiver sensitivity. Sill this is not reliable taking into account that sensitivity for different receivers varies (e.g. changes over time), path conditions are not symmetric (and device can only measure signal strength it receives), etc.
*by receiving/not receiving acknowledgment for frame sent.
*by receiving/not receiving acknowledgment for frame sent.


Taking into account that using signal strength is not reliable, 802.11 device is essentially left with only one "feedback" to tune its operation - success/failure of transmission. When transmission fails (ACK not received in time), there is no way how sender can figure out why it failed - either because of noise, multipath, direct interference (and wether that disturbed actual data frame or the ACK itself) - frame just did not make it and in general it does not matter "why". All that matters is packet error rate.
Taking into account that using signal strength is not reliable, 802.11 devices are essentially left with only one "feedback" to tune its operation - success/failure of transmission. When transmission fails (ACK not received in time), there is no way how sender can figure out why it failed - either because of noise, multipath, direct interference (and whether that disturbed actual data frame or the ACK itself) - frame just did not make it and in general it does not matter "why". All that matters is the packet error rate.


Therefore RouterOS implements algorithm to try to use medium most efficiently in any environment by using only this limited information, giving users the ability to control how algorithm works and describing the algorithm. And there are only a few usage guidelines, not a set of values you should use in particular situation.
Therefore RouterOS implements an algorithm to try to use medium most efficiently in any environment by using only this limited information, giving users the ability to control how the algorithm works and describing the algorithm. And there are only a few usage guidelines, not a set of values you should use in a particular situation.


In general - the larger ''hw-retries'', the better "feedback" device gets about medium ability to deliver frame at particular rate (e.g. if sending frame with rate 54mbps fails 16 times, it is telling you more than if it fails with 2 retries) and the better it can figure out optimal transmit rate, at the expense of latency it can introduce in network - because during all those failing retries, other devices in this channel can not send. So '''bigger''' ''hw-retries'' can be suggested for ptp backbone links - where it is known that link must be always on. '''Less''' ''hw-retries'' make rate selection adapt faster at the expense of some accuracy (going below 2 is not reasonable in most cases), this can be suggested for ptmp links, where it is normal for links to connect/disconnect and keeping latency down is important.
In general - the larger ''hw-retries'', the better "feedback" device gets about medium ability to deliver frame at particular rate (e.g. if sending frame with rate 54mbps fails 16 times, it is telling you more than if it fails with 2 retries) and the better it can figure out optimal transmit rate, at the expense of latency it can introduce in network - because during all those failing retries, other devices in this channel cannot send. So '''bigger''' ''hw-retries'' can be suggested for ptp backbone links - where it is known that link must be always on. '''Less''' ''hw-retries'' make rate selection adapt faster at the expense of some accuracy (going below 2 is not reasonable in most cases), this can be suggested for ptmp links, where it is normal for links to connect/disconnect and keeping latency down is important.


''on-fail-retry-time'' and ''disconnect-timeout'' controls how hard device will try to consider remote party "connected". Larger ''disconnect-timeout'' will make device not "disconnect" other party, even if there are lots of loss at the smallest possible transmission rate. This again is most useful for "weak" links that are known that they "must" be established (e.g. backbone links). In ptmp networks large ''disconnect-timeout'' will again increase latency in network during the time e.g. AP will attempt to send data to some client that has just been disabled (AP will try to do this for whole ''disconnect-timeout'').
''on-fail-retry-time'' and ''disconnect-timeout'' controls how hard device will try to consider remote party "connected". Larger ''disconnect-timeout'' will make the device not "disconnect" other party, even if there are lots of loss at the smallest possible transmission rate. This again is most useful for "weak" links that are known that they "must" be established (e.g. backbone links). In ptmp networks large ''disconnect-timeout'' will again increase latency in the network during the time e.g. AP will attempt to send data to some client that has just been disabled (AP will try to do this for the whole ''disconnect-timeout'').


''frame-lifetime'' allows to tune for how long AP is attempting to use frame for transmitting before considering that it is not worth delivering it (for example, if sending frame fails at lowest possible rate, ''on-fail-retry-time'' timer is enabled, if during this timer ''frame-lifetime'' expires, particular frame is dropped and next transmission attempt will happen with next frame. Disabled ''frame-lifetime'' means that wireless will ensure in order delivery of "all" data frames, no matter how long it takes, "or" will drop the connection if everything fails). This allows to optimize for different types of traffic  
''frame-lifetime'' allows to tune for how long AP is attempting to use frame for transmitting before considering that it is not worth delivering it (for example, if sending frame fails at lowest possible rate, ''on-fail-retry-time'' timer is enabled, if during this timer ''frame-lifetime'' expires, particular frame is dropped and the next transmission attempt will happen with the next frame. Disabled ''frame-lifetime'' means that wireless will ensure in order delivery of "all" data frames, no matter how long it takes, "or" will drop the connection if everything fails). This allows optimizing for different types of traffic  
e.g. for real-time traffic - if primary use of wireless network is e.g. voip, then it can be reasonable to limit ''frame-lifetime'', because voip tolerates small loss better than high latency.
e.g. for real-time traffic - if the primary use of the wireless network is e.g. voip, then it can be reasonable to limit ''frame-lifetime'', because voip tolerates small loss better than high latency.


===Is it possible to use the wireless repeater only with one radio interface?===
===Is it possible to use the wireless repeater only with one radio interface?===


This setup it possible by using WDS on the wireless interface which is running in ap-bridge mode.
This setup it possible by using WDS on the wireless interface which is running in ap-bridge mode. And in newer RouterOS versions it is possible to configure wireless repeater mode.
 
===Nv2 wireless link disconnects very often===


When Nv2 wireless link experiences disconnections and in log section most of the messages are 'control frame timeout', then make sure that the router's RouterOS version is at least v5.14.  v5.14 introduced several improvements for the Nv2 wireless protocol.
The second suggestion is to lower the transmit output power of the wireless cards if the signal of the link is strong. We suggest using tx-power-mode=card-rates for lowering the tx-power of the wireless card.
If the problem continues to try to use a different wireless frequency that might have less interference.
If that also didn't help, please contact support@mikrotik.com with a support output file from the affected AP and the Station which are made after those disconnections.


[[Category:Manual|W]]
[[Category:Wireless]]
[[Category:Wireless]]
[[Category:Interface|W]]
[[Category:Case Studies]]
[[Category:Case Studies|W]]

Latest revision as of 10:37, 7 September 2020

Settings

Why I can't connect to MikroTik 802.11n AP with Apple Mac devices?

This problem is only seen on Mac devices based on Broadcom wireless chipsets. In order to connect with such wireless device to MikroTik 802.11n AP make sure that you don't use 'short' preamble-mode. Use 'long' or 'both' preamble-mode and Mac wireless devices will be able to connect.

By changing some wireless settings the wireless link works unstable

Sometimes when you change some wireless setting for tuning the links you got so far that the link isn't establishing any more or works unstable and you don't remember what settings you had in the beginning. In this case, you can use the reset-configuration command in the wireless menu - it will reset the all the wireless settings for the specific wireless interface and you will be able to configure the interface from the start. Note that executing this command also disables the interface, so please be careful not to execute this command if you are configuring router remotely using that wireless link that you want to reset the configuration.

What are wireless retransmits and where to check them?

Wireless retransmission occur when an interface sends out a frame and doesn't receive back an acknowledgment (ACK), causing it to try sending the frame again until an acknowledgment is received or the maximum allowed retransmission count for a packet is reached. Wireless retransmits increase the latency and lower the throughput of a wireless link. The number of retransmissions taking place can be determined by subtracting the value of the frames parameter from the value of the 'hw-frames parameter for a given entry in the registration table. Some number of retransmissions is to be expected, but if the value of frames exceeds the value of frames multiple times, there is an issue with the wireless link that requires troubleshooting.

Can I compare frames with hw-frames also on Nstreme links?

The frames counts only those which contain actual data. In the case of Nstreme, only the ACK can be transmitted in a single frame, if there is no other data to send. These ACK frames will not be added to the frames count, but they will appear at hw-frames. If there is traffic on both directions at maximum speed (eg. there will be no only-ack frames), then you can't compare frames to hw-frames as in case of regular wireless links.

What TX-power values can I use?

The tx-power default setting is the maximum tx-power that the card can use and is taken from the cards eeprom. If you want to use larger tx-power values, you are able to set them, but do it at your own risk, as it will probably damage your card eventually! Usually, one should use this parameter only to reduce the tx-power.

In general, tx-power controlling properties should be left at the default settings. Changing the default setting may help with some cards in some situations, but without testing, the most common result is the degradation of range and throughput. Some of the problems that may occur are:

  • overheating of the power amplifier chip and the card which will cause lower efficiency and more data errors;
  • overdriving the amplifier which will cause more data errors;
  • excessive power usage for the card and this may overload the 3.3V power supply of the board that the card is located on resulting in voltage drop and reboot or excessive temperatures for the board.

What TX-power-mode is the best?

TX-power-mode tells the wireless card which tx-power values should be used. By default, this setting is set to default.

  • default means that the card will use the tx-power values from the cards eeprom and will ignore the setting what is specified by the user in the tx-power field.
  • card-rates means that for different data rates the tx-power is calculated according to the cards transmit power algorithm from the cards eeprom and as an argument it takes tx-power value specified by the user.
  • all-rates-fixed means that that the card will use one tx-power value for all data rates which is specified by the user in tx-power field.

Note that it is not recommended to use 'all-rates-fixed' mode as the wireless card tx-power for the higher data rates is lower and by forcing to use the fixed tx-power rates also for the higher data rates might result in the same problems like in the previous question about tx-power setting. In the case of MikroTik Radio devices, the power will not be higher than the power written in the EEPROM. For most of the cases if you want to change the tx-power settings it is recommended to use the tx-power-mode=card-rates and it is recommended to lower and not to raise tx-power. In case of AR9300 and newer Atheros wireless chipsets "tx-power-mode=all-rate-fixed" is the only option as "card-rates" option isn't working on those chipsets.

What is CCQ and how are the values determined?

Client Connection Quality (CCQ) is a value in percent that shows how effective the bandwidth is used regarding the theoretically maximum available bandwidth. CCQ is weighted average of values Tmin/Treal, that get calculated for every transmitted frame, where Tmin is time it would take to transmit given frame at highest rate with no retries and Treal is time it took to transmit frame in real life (taking into account necessary retries it took to transmit frame and transmit rate).

What is hw-retries setting?

Number of times sending frame is retried without considering it a transmission failure. The data rate is decreased upon failure and frame is sent again. Three sequential failures on lowest supported rate suspend transmission to this destination for the duration of on-fail-retry-time. After that, the frame is sent again. The frame is being retransmitted until transmission success, or until the client is disconnected after disconnect-timeout. The frame can be discarded during this time if frame-lifetime is exceeded. In case of Nstreme "on-fail-retry-time", "disconnect-timeout" and "frame-lifetime" settings are not used. So after three sequential failures on the lowest supported rate, the wireless link is disconnected with "extensive data loss" message.

What is disconnect-timeout setting?

This interval is measured from the third sending failure on the lowest data rate. At this point 3 * (hw-retries + 1) frame transmits on the lowest data rate had failed. During disconnect-timeout packet transmission will be retried with on-fail-retry-time interval. If no frame can be transmitted successfully during disconnect-timeout, the connection is closed, and this event is logged as "extensive data loss". Successful frame transmission resets this timer.

What is adaptive-noise-immunity setting?

Adaptive Noise Immunity (ANI) adjusts various receiver parameters dynamically to minimize interference and noise effect on the signal quality [1] This setting is added in the wireless driver for Atheros AR5212 and newer chipset cards

How does wireless device measure signal strength, when access-list or connect-list are used ?

The reported signal level is exponentially weighted moving average with a smoothing factor of 50%.

What error correction methods are supported in the RouterOS wireless?

ARQ method is supported in nstreme protocols. Regular 802.11 standard does not include ARQ - retransmission of corrupt frames is based on acknowledgment protocol. RouterOS supports forward error correction coding (convolutional coding) with coding rates: 1/2, 2/3, or 3/4.

Configuring RouterOS device for 160MHz use

If the RouterOS device supports 4x4 transmission, additionally to setting 160MHz channel width, make sure to set "rate-set=default" on the wireless interface so all streams are available

If the client does not support Extended NSS and can only perform 2x2 transmission, set "vht-supported-mcs=mcs0-9,mcs0-9,none"

Setups

Will an amplifier improve the speed on my link?

It depends on your signal quality and noise. Remember that you can probably get a better link with low output power setting, and a good antenna. An amplifier increases the noise and will only cause problems with the link.

The amplifier gets a boost on both the transmitted and received signal. Thus, in "silent" areas, where you are alone or with very few "noise" or "competition", you might get excellent results. On the other side, in crowded areas, with lots of wireless activity, you will also increase signal received from every other competitor or noise source, which may dramatically lower the overall quality of the link. Also, take in account the EIRP to see if your link remains in legal limits.

You could also get a better signal on "11b only" radios, which see most of 802.11g as "noise", thus filtering better the usable signal.

How to fine-tune the wireless link with hw-retries?

You should understand that for 802.11 devices there is a really limited amount of information (or "feedback" from the environment) that devices can use to tune their behavior:

  • signal strength, which could be used to figure out best transmit rate knowing receiver sensitivity. Sill this is not reliable taking into account that sensitivity for different receivers varies (e.g. changes over time), path conditions are not symmetric (and device can only measure signal strength it receives), etc.
  • by receiving/not receiving acknowledgment for frame sent.

Taking into account that using signal strength is not reliable, 802.11 devices are essentially left with only one "feedback" to tune its operation - success/failure of transmission. When transmission fails (ACK not received in time), there is no way how sender can figure out why it failed - either because of noise, multipath, direct interference (and whether that disturbed actual data frame or the ACK itself) - frame just did not make it and in general it does not matter "why". All that matters is the packet error rate.

Therefore RouterOS implements an algorithm to try to use medium most efficiently in any environment by using only this limited information, giving users the ability to control how the algorithm works and describing the algorithm. And there are only a few usage guidelines, not a set of values you should use in a particular situation.

In general - the larger hw-retries, the better "feedback" device gets about medium ability to deliver frame at particular rate (e.g. if sending frame with rate 54mbps fails 16 times, it is telling you more than if it fails with 2 retries) and the better it can figure out optimal transmit rate, at the expense of latency it can introduce in network - because during all those failing retries, other devices in this channel cannot send. So bigger hw-retries can be suggested for ptp backbone links - where it is known that link must be always on. Less hw-retries make rate selection adapt faster at the expense of some accuracy (going below 2 is not reasonable in most cases), this can be suggested for ptmp links, where it is normal for links to connect/disconnect and keeping latency down is important.

on-fail-retry-time and disconnect-timeout controls how hard device will try to consider remote party "connected". Larger disconnect-timeout will make the device not "disconnect" other party, even if there are lots of loss at the smallest possible transmission rate. This again is most useful for "weak" links that are known that they "must" be established (e.g. backbone links). In ptmp networks large disconnect-timeout will again increase latency in the network during the time e.g. AP will attempt to send data to some client that has just been disabled (AP will try to do this for the whole disconnect-timeout).

frame-lifetime allows to tune for how long AP is attempting to use frame for transmitting before considering that it is not worth delivering it (for example, if sending frame fails at lowest possible rate, on-fail-retry-time timer is enabled, if during this timer frame-lifetime expires, particular frame is dropped and the next transmission attempt will happen with the next frame. Disabled frame-lifetime means that wireless will ensure in order delivery of "all" data frames, no matter how long it takes, "or" will drop the connection if everything fails). This allows optimizing for different types of traffic e.g. for real-time traffic - if the primary use of the wireless network is e.g. voip, then it can be reasonable to limit frame-lifetime, because voip tolerates small loss better than high latency.

Is it possible to use the wireless repeater only with one radio interface?

This setup it possible by using WDS on the wireless interface which is running in ap-bridge mode. And in newer RouterOS versions it is possible to configure wireless repeater mode.

Nv2 wireless link disconnects very often

When Nv2 wireless link experiences disconnections and in log section most of the messages are 'control frame timeout', then make sure that the router's RouterOS version is at least v5.14. v5.14 introduced several improvements for the Nv2 wireless protocol. The second suggestion is to lower the transmit output power of the wireless cards if the signal of the link is strong. We suggest using tx-power-mode=card-rates for lowering the tx-power of the wireless card. If the problem continues to try to use a different wireless frequency that might have less interference. If that also didn't help, please contact support@mikrotik.com with a support output file from the affected AP and the Station which are made after those disconnections.