For some reason I cannot understand, I have strong fluctuations in the link speed of a wifi bridge made with two LHG 52 ac. The speed varies from under 200mbps to 780mbps (occasionally it even lines up at 866), with a constant signal at around -54. ROS version is 6.46.4.
And so far it might seem normal...
But the weird thing is that the link speed is stable between 780 and 866mbps when the winbox is connected and the "wireless-> registration-table" tab is displayed, while it collapses when winbox is closed (speed is also monitored via snmp by a dedicated software). Here is the graph ...
The areas marked in red relate to when winbox was disconnected. Now is currently active on a virtual machine, and as long as it is active everything is ok, but when sometimes it disconnects for various reasons, the speed drops dramatically.
It almost seems like a quantum effect, like that of the heisenberg's cat, in which a sight changes the state: when I control it the speed is high (link full alive), when I don't control it (with winbox) the speed collapses (link almost dead).
Any suggestions?
Ok, that's weird, like a quantum paradox...
You do not have the required permissions to view the files attached to this post.
Re: Ok, that's weird, like a quantum paradox...
What you are looking at is the PHY rate, the interface rate, the MCS encoding. http://mcsindex.com/
In the wiki FAQ we learn:
.
.
If you follow this setting on a registration with very limited traffic the PHY rate drops. (It sometimes even shows just the broadcast / basic rate), because one missed transmission (there was no ack) has an enormous impact in the quality check. Once you add some traffic the PHY rate rises, as there are more good transmissions. The WinBox traffic can be what is acting here.
Another phenomenon is that the quality of the connection can drop just when traffic is applied (eg. while passing a wall the encoding must lower the MCS till 16-qam because of signal deformation or interference.)
The number of missed frames is in the registration (ration frames versus hw frames) , and used to calculate the CCQ indicator.
I have no idea what that brown/gray lower line is in the graph, but it looks strongly correlated.
Setting hw-retries to a higher (15) value than the default 7, will make one stay longer in de denser MCS encodings, even with more retransmits.
Setting hw-retries to a lower value, will make the PHY rate adjust faster to avoid retransmits.
In the wiki FAQ we learn:
Code: Select all
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..
If you follow this setting on a registration with very limited traffic the PHY rate drops. (It sometimes even shows just the broadcast / basic rate), because one missed transmission (there was no ack) has an enormous impact in the quality check. Once you add some traffic the PHY rate rises, as there are more good transmissions. The WinBox traffic can be what is acting here.
Another phenomenon is that the quality of the connection can drop just when traffic is applied (eg. while passing a wall the encoding must lower the MCS till 16-qam because of signal deformation or interference.)
The number of missed frames is in the registration (ration frames versus hw frames) , and used to calculate the CCQ indicator.
I have no idea what that brown/gray lower line is in the graph, but it looks strongly correlated.
Setting hw-retries to a higher (15) value than the default 7, will make one stay longer in de denser MCS encodings, even with more retransmits.
Setting hw-retries to a lower value, will make the PHY rate adjust faster to avoid retransmits.
Re: Ok, that's weird, like a quantum paradox...
Ok, now it seems to be more clear to me, or at least your answer have more sense in this physical world! Thank you very much.
However it is not so clear to me why winbox could generate that traffic, since my bridge have around 80-120mbps of traffic in every day moment. It is a different kind of traffic?
To answer about other lines, i have to clarify that on this link download traffic runs over the 5ghz freq and upload one over the 2,4ghz one. I've used ospf to route up and down traffic over the two separate interface, to gain more bandwidth and use them simultaneously. That's the reason you have seen other strong correlated lines:
pink --> Tx rate 5Ghz
gray --> Rx rate 5Ghz
blue --> Tx rate 2,4Ghz
black --> Rx rate 2,4Ghz
When the link stay at ~780mbps phy tx rate, rx rate on the same freq drops down to 6mbps (ideal condition, since i don't need bandwidth on that direction)
I've tested many configurations to achieve the best speed ratio and, since the link is over 4km and los is not fully clear (or, at least, i cannot check it without binoculars), it seems the best.
However it is not so clear to me why winbox could generate that traffic, since my bridge have around 80-120mbps of traffic in every day moment. It is a different kind of traffic?
To answer about other lines, i have to clarify that on this link download traffic runs over the 5ghz freq and upload one over the 2,4ghz one. I've used ospf to route up and down traffic over the two separate interface, to gain more bandwidth and use them simultaneously. That's the reason you have seen other strong correlated lines:
pink --> Tx rate 5Ghz
gray --> Rx rate 5Ghz
blue --> Tx rate 2,4Ghz
black --> Rx rate 2,4Ghz
When the link stay at ~780mbps phy tx rate, rx rate on the same freq drops down to 6mbps (ideal condition, since i don't need bandwidth on that direction)
I've tested many configurations to achieve the best speed ratio and, since the link is over 4km and los is not fully clear (or, at least, i cannot check it without binoculars), it seems the best.
Re: Ok, that's weird, like a quantum paradox...
If you use TCP as protocol then the reverse direction malfunction (with the ACK on the IP level) will influence the transmit data speed. (Should not influence PHY, but the TCP congestion control used (Reno, Vegas, new vegas, cubic ....) will reduce the transmission throughput.)
If that extra loaded reverse direction is dropping or missing ACK's at the wifi layer, then any non-received ACK for a unicast will initiate a MCS level step down, because the 802.11 does not know why the packet did not get acknowledged properly.
So TX and RX are correlated, even if they happen over different channels.
Interference corrupts at the receiver side only. The amount of interference can be quite different if both devices are not close to each other. Interference will corrupt received packets. Interference will delay sent packets.
6Mbps is special, as this is the initial basic rate for a connection. (Even if you set the basic rate higher, still some traffic happens at 6 Mbps). It is also around the MCS-0 rate.
But now, to explain what exactly happens in your case, is not easy. (Or to phrase it differently: "I don't know". I don't even know if a TCP level ACK for down traffic follows the down link path in reverse direction or the up link path.)
If that extra loaded reverse direction is dropping or missing ACK's at the wifi layer, then any non-received ACK for a unicast will initiate a MCS level step down, because the 802.11 does not know why the packet did not get acknowledged properly.
So TX and RX are correlated, even if they happen over different channels.
Interference corrupts at the receiver side only. The amount of interference can be quite different if both devices are not close to each other. Interference will corrupt received packets. Interference will delay sent packets.
6Mbps is special, as this is the initial basic rate for a connection. (Even if you set the basic rate higher, still some traffic happens at 6 Mbps). It is also around the MCS-0 rate.
But now, to explain what exactly happens in your case, is not easy. (Or to phrase it differently: "I don't know". I don't even know if a TCP level ACK for down traffic follows the down link path in reverse direction or the up link path.)
Who is online
Users browsing this forum: No registered users and 41 guests