Hello everybody,
I'm needing more information and guidance on how to aim antennas
My last attempt should have been a relatively easy task. I've got a QRT approx 7 miles from a Sector antenna. All my descriptions are from the point of beign at the QRT with admin control, and no admin control of the sector. Both are on rooftops and there is clear LOS between them. When using the sound based snr aiming tool I can get as much as high 30s for snr so I lock it down. My error rate when Babel decides to connect ends up being high 30's to above 50% and the device disconnects itself. It had a connection with 10Mb or better speed and I was able to use the connection before it disconnected.
A friend said earlier that error rate is more important now than snr. So I played around de-aiming so that the result was that my snr and nsnr would be similar. Here's the problem. I have to reboot the node to force Babel to try again to connect, and this takes FOREVER. There is in Internal Services/Advanced Options a restart Babel and hard restart Babel toggle. When I chose these they don't seem to do anything. To make things even more spooky, I'm at a site with multiple devices all POE from one switch, and the other devices report no errors dtd but my device reported 30% errors dtd. It makes no sense. To get rid of all the displayed dtd errors I had eventually to reboot the entire POE switch. Hmmm.
When I degraded by re-aiming so my snr locally dropped to mid 20s I got a connection again in the mid 30 error rate. However once Babel would allow me to navigate again to the other node the error rate and snr reported there disagree with what I see from my side. Eventually however, it stabilized and did not drop the connection. I decided to test further and ran Iperf3 tests between the nodes several times. I got a good throughput and when done, my node said my error rate was now 4%! The other node agreed more or less, and I was thrilled. Then I checked again five minutes later and the error rate had climbed back into the mid 30s ... while the nodes were idle.
Part of my problem is that you have to see the snr and error rates from the antenna on the other end of your connection, and if Babel won't allow the connection you can't see it to adjust and try things. The wifi signal tool shows local and remote ... but here's the main problem. I don't get a report of remote snr until there is a connection that Babel approves, so I can't see while aiming if I'm helping or hurting the connection from the perspective of the other node. I guess when the signal is blocked by Babel due to the other node deciding the connection isn't good enough ... how do I force it to accept the connection long enough to get return metrics and how do I encourage the other node I have no control over to retry? Is there a built in time limit? What makes a node unblock a connection that was previously blocked to do error rate?
I'd like to be able to choose to hear the snr from the other node I'm aming at before Babel decides the connection is adequate to use. In the past we could force OLSR to accept a poor connection for a temporary period so we could troubleshoot. Perhaps there could be a setting to force Babel to connect even though bad quality for fifteen minutes ... to allow for aiming and testing?
Anyway ... it's weird. I'd like to understand how I can have a connection report tx 100%, have 45Mbps (yes the picture below is different rate but it took ten minutes to take screen shot and post and the metric changes) (Iperf3 reports about 15), but it says I have 36% errors? IAnd this doesn't jive with what I see if I click the node and see the detail. And why would running Iperf3 change the reported error rate downwards?
I'm needing more information and guidance on how to aim antennas
My last attempt should have been a relatively easy task. I've got a QRT approx 7 miles from a Sector antenna. All my descriptions are from the point of beign at the QRT with admin control, and no admin control of the sector. Both are on rooftops and there is clear LOS between them. When using the sound based snr aiming tool I can get as much as high 30s for snr so I lock it down. My error rate when Babel decides to connect ends up being high 30's to above 50% and the device disconnects itself. It had a connection with 10Mb or better speed and I was able to use the connection before it disconnected.
A friend said earlier that error rate is more important now than snr. So I played around de-aiming so that the result was that my snr and nsnr would be similar. Here's the problem. I have to reboot the node to force Babel to try again to connect, and this takes FOREVER. There is in Internal Services/Advanced Options a restart Babel and hard restart Babel toggle. When I chose these they don't seem to do anything. To make things even more spooky, I'm at a site with multiple devices all POE from one switch, and the other devices report no errors dtd but my device reported 30% errors dtd. It makes no sense. To get rid of all the displayed dtd errors I had eventually to reboot the entire POE switch. Hmmm.
When I degraded by re-aiming so my snr locally dropped to mid 20s I got a connection again in the mid 30 error rate. However once Babel would allow me to navigate again to the other node the error rate and snr reported there disagree with what I see from my side. Eventually however, it stabilized and did not drop the connection. I decided to test further and ran Iperf3 tests between the nodes several times. I got a good throughput and when done, my node said my error rate was now 4%! The other node agreed more or less, and I was thrilled. Then I checked again five minutes later and the error rate had climbed back into the mid 30s ... while the nodes were idle.
Part of my problem is that you have to see the snr and error rates from the antenna on the other end of your connection, and if Babel won't allow the connection you can't see it to adjust and try things. The wifi signal tool shows local and remote ... but here's the main problem. I don't get a report of remote snr until there is a connection that Babel approves, so I can't see while aiming if I'm helping or hurting the connection from the perspective of the other node. I guess when the signal is blocked by Babel due to the other node deciding the connection isn't good enough ... how do I force it to accept the connection long enough to get return metrics and how do I encourage the other node I have no control over to retry? Is there a built in time limit? What makes a node unblock a connection that was previously blocked to do error rate?
I'd like to be able to choose to hear the snr from the other node I'm aming at before Babel decides the connection is adequate to use. In the past we could force OLSR to accept a poor connection for a temporary period so we could troubleshoot. Perhaps there could be a setting to force Babel to connect even though bad quality for fifteen minutes ... to allow for aiming and testing?
Anyway ... it's weird. I'd like to understand how I can have a connection report tx 100%, have 45Mbps (yes the picture below is different rate but it took ten minutes to take screen shot and post and the metric changes) (Iperf3 reports about 15), but it says I have 36% errors? IAnd this doesn't jive with what I see if I click the node and see the detail. And why would running Iperf3 change the reported error rate downwards?
The issue isn't where I am placing the antenna, the issue is how to interpret and use the tools. We cannot have perfection, I'm working with what I got. The problem is understanding fully what the metrics tell me and having control over Babel long enough to make good choices.
OK ... let's just ask one question then. How come the node reports mid 30's errors continuously ... I run Iperf3 and afterwards the reported error rate drops to nearly zero, then when I wait a bit the error rate reported goes back up?
I always aim for maximum signal strength.
73, Chuck
1) In this instance, and verified by another local ham who maintains other multi node sites ... going with the maxiumum snr leaves us with nodes that accumulate too high an "error" rate and Babel disconnects. When we accept a slightly lower snr on our end the error rate stays lower and we stay connected. Just reporting our actual experiences. My colleague thinks we might be getting eroneous snr readings on the aiming tool from multipath. Idk.
2) Why would running iperf3 change the reported error rate downwards, and then afterwards have it climb back up?
Ed
Ah, 'Babel disconnects' is critical. Point taken.
However, I don't know, for sure, that 'Babel' monitors error rate to decide whether to disconnect.
If true, herein lies a conflict:
I think AREDN chooses a modulation scheme based on highest throughout without regard to error rate.
I will try to pose this scenario to the developers. :-|
Thank you for posting the details.
73, Chuck
Babel itself is only responsible for 4 metrics in the Neighborhood Node info - rx success, rx cost, tx cost, route trip time - and of these "rx success" is the most important one for Babel when making choices about routing. It measures how successful Babel is at receiving Babel HELLO messages. 100% means the link isn't losing anything. When people talk about X metric being more important than SNR, "rx success" at both ends of a link are the one they mean. A lossless link is way more important, even with a lower bandwidth, compared to a lossy-link because a lossy link will kill performance of any end-to-end-protocols with data retransmissions. The other three as used to bias various alternatives all else being equal.
Local SNR and Neighbor SNR are just what they sound like - the reported signal minus noise as measured by the wifi chipsets at both ends of a link. Both values are rolling averages. No babel involvement.
Of the other metrics "tx failures" and "tx retransmissions" are what the physical hardware is reporting, whether it's wifi or ethernet. No babel involved with these. Ideally "tx failures" should be 0 and "tx retransmissions" as close to zero as possible - but no always possible on wifi. But for a physical ethernet connections (a typical DtD) these should be zero. If they're not that's a concern. These values are rolling averages.
Of the rest, the physical tx and rx bitrates are the raw bitrates as reported by the wifi hardware. Again, not a Babel thing. iPerf will never report these values as they're the raw bitrates being pushed across the link. By time various layers of protocols and retries have been layer on this, and wifi is half-duplex, you might see a 1/3 of what's reported ... maybe.
State and routes let you know how the link is being utilized. Routes let's you know how many IPv4 routes the kernel has across the link. If it's 0 then state will most likely be "idle". But if the other end of the link hasn't sent or responded to any probes in the last 2 minutes, it will indicated "disconnected".
Because many of these values come directly from the hardware, restarting babel generally wont get you much change - the tx error counts in the wifi chip aren't effected by that. Rebooting does of course clear all this. There is a service called "system manager" which you can restart which will clear the rolling averages, but doesn't effect the operation of anything.
As for how this data is retrieves, the local stuff is read out of the kernel every 30 seconds, while the remote data is updated every ~15 minutes. It an expensive operation so we don't do it much. The data is fetching using IPv6 (not IPv4) link local addresses which means it can be retrieved regardless of how Babel feels about the link. So long the link exists and is operating well enough, the data will be fetched. Babel could be disabled (don't do that!) and this would still work (the exception to this has been the WiFi Signal tool, but today we updated that to also use IPv6).
I hope this helps a bit.
Tim - KN6PLV
Particularly if you find that dropping S/N by tipping the antenna up a tad in order to improve performance is almost a dead give away of Fresnel zone issues. Although you are reducing signal, you are more substantially reducing fresnel zone interference because it is farther off the main axis of the antenna beamwidth. This can also be the case off horizontal axis if you are pointing away from the fresnel zine interference direction.
"rx" is rx sucess? Do I understand that this is more important than the parameter "errors"?
"rtt" is round trip time in ms?
What exactly on the neighbor nodes summary is "errors"? I don't see a 1 to 1 correspondence between the display in main status and anything in the detail info for the link. This is the parameter I'm reporting as changing from moderately high to much lower after running iperf3 tests. Does this mean anything? Is this parameter cleared out if you restart the system manager?
Ed