OKay, so at the moment the LQ and NLQ aren't quite 100% but it is still close. Let me start from the beginning, We have a Mountain top node that is a rocketM2 and 120 degree Sector. I have a clear unobstructed view line of sight to the Mountain top node about 6-7 miles away. we are running our system on ch -2 , 10 MHz bandwidth. I am running a nonostation on my tower at about 30 feet This is my current Neighbor list. K7MSH on top is the mountain top node, as you can see, the connection is good, but I always show 0 TXMbps.
if I try to go to K7MSH-WestMountain-NorthEast.local.mesh, it takes around 1 minute to load the main page. logging into the Mesh status page takes around 1-2 minutes to load. BUT once I get to the Mesh status page for the Mountain top node (K7MSH-WestMountain-NorthEast.local.mesh) this is what I see. Look at the third node down KD7VEA, Here I see 37.8TxMbps, and if I click on that link, I am back to my node page in under 2 seconds.
So I have a couple of questions,In the first screen shot, Where we are looking at K7MSH-WestMountain-NorthEast.local.mesh, 94, 84 and 0 TxMbps where does the 0TxMbps originate from is that K7MSH has 0 data going down to KD7VEA, or is it K7MSH does not see data coming up from KD7VEA.
The next question is what would cause this, and how could I fix this. It wasn't always like this, a few weeks ago I had a better connection to K7MSH mountain node. I restarted the mountain node today, and even reflashed my nanostaion today just to be sure there wasn't an issue there. Any help will be greatly appreciated, Im kinda lost at this point.
This is the throughput of a directed link (packets are flowing across it in a directed manner like access a page on some device at that node or through that node)
The traffic that goes across the link to establish the mesh is non-directed(multicast) so it doesn't trigger these numbers to be calculated.
Also when you click a link on a remote node to get to your local node the packets don't go to the remote node and then back to your local node they always go direct from your computer to the destination so faster access to your locks node be expected.
Bob W8ERD
Explanation: http://www.aredn.org/content/aredn-help-file-31610 (also available on every mesh node install by clicking "Help")
How should use: Honestly its just telling you what the effective RF data rate while transmitting across that link is, which doesn't necessarily mean your true data rate will be even remotely the same.
So I ran a trace route, and it didn't seem to help me here. 1.1 is my firewall, 1.200 is my NanoStation, and .77.197 is the mountain top node. I understand that I wont always see a TxMbps, but its odd that I see all of the other nodes and not the mountain top node. I don't know if maybe I am having interference issues, or what is happening, but I did order a Rocket Dish and rocket and hope to set that up this upcoming weekend. as my dedicated link to the mountain top node, and keep the NanoStation connecting to the locals.
My experience with the mountain top node from AD7QF-QTH2 and to Lake Mountain is in settings, to use the correct distance setting to the furthest node you want to reach. My experience with Nelson Peak was simuliar. Decent LQ and NLQ but zero though put until the distance was correctly set. Still am unable to make a solid link, due to low signal, but can load status. Throughput is about 2 now instead of zero as before.
traceroute to k7msh-westmountain-northeast.local.mesh (10.10.77.197), 30 hops ma x, 38 byte packets
1 K7MSH-WestMountain-northEast.local.mesh (10.10.77.197) 30.919 ms 2.914 ms 1.731 ms
Here is the strange part, just before I started the SSH session I tried to access West Mountain, and it was still very slow. after I did the taceroute seeing that it should be running pretty fast, I went back to my Mesh Status Page, clicked on the West Mountain node and it instantly loaded. all nodes past West Mountain are now being accessed quicker also. Where I was seeing 0TxMbps before, it is now showing 26TxMbps for the West Mountain node. I dont know how just starting an SSH session and doing a traceroute would have fixed the issue, but thats all that I did. now it works great??? any thought on what could have happened?
The furthest node that I see (and only on occasion) is about 10 miles away; all others are closer than 7 miles and I see and can communicate with them fairly well.
This furthest "10 miles away" node... about 50% of the time it doesn't even show on my status page. The other half of the time, it's either just showing an IP address... or the node name. If I click on this node, it's about a 1 in 10 chance I can bring up it's status page; its slow to load and often the browser just errors and times out.
Question; in order to maximize my nodes overall throughput, should I set my distance setting to 10 miles... or to 7 ?
Setting your distance parameter too low may cause re-transmits, which increase the potential for collisions. You need to read up on why that parameter is there and then set it. For N8NQH, you better set it to more than 10 miles. If you don't, you're almost ensuring that the node 10 miles away won't ever be able to reliably talk to you and it will cause contention/congestion. Better to wait an extra couple of milliseconds than to endure the CSMA/CD retry waits continuously.
Back to the original problem....The tracert DOES show two things. One, you aren't take a weird path to the mountain. That's good. The bad news is you have a really bad link. That failed first response (the *) and then the 653ms response shows me that you've either got your distance parameters set wrong on your nodes or that you don't have enough bandwidth for the amount of traffic.
http://www.aredn.org/content/bandwidthwhy-wont-work
Sounds like the same symptoms you have. Scroll to the bottom and work your way up if you want to get to the conclusion.
The next time it breaks change only the distance parameter on the mountain top node to something like 50 miles (80 km) and see what happens.
One bad setting could cause issues for every device in RF range of the trouble node (and the devices those nodes want to speak to, so essentially "for 2 hops."