You are here

100% lq 100%nlq 0TxMbps

17 posts / 0 new
Last post
100% lq 100%nlq 0TxMbps

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.

kg9dw's picture
Run a traceroute (or tracert if you're on Windows) from the LAN of your node on your tower to the mountain top node. Let's see what path it is taking. 
It's normal for the link to
It's normal for the link to show 0 Mbps when not in use. 

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.
Please explain exactly what
Please explain exactly what the Tx MPS number means and how we should use and interpret it.  Thanks!

Explination: http://www.aredn

Explanation:  (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.

kg9dw's picture
Do still run a traceroute as
Do still run a traceroute as you have some type of a problem here in getting to the mountain node, especially with the nanostation seeing the mountain and the mountain seeing the nanostation. 
tracert not helping

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.

Set distance

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.

Fixed it, but not sure how
OK, Im going to throw this out there,  I was asked by N0KVN down the road from me to SSH into my node and then perform a Tracroute to West Mountain. so I opened up Putty, I started an SSH session, ran a traceroute to west mountain and here are the results

traceroute to k7msh-westmountain-northeast.local.mesh (, 30 hops ma x, 38 byte packets
1 K7MSH-WestMountain-northEast.local.mesh ( 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?
N8NQH's picture
Distance Setting

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 ?
kg9dw's picture
In my opinion, always set the
In my opinion, always set the distance parameter to a higher distance.  

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.
kg9dw's picture
Read this:http://www.aredn
Read this:

Sounds like the same symptoms you have. Scroll to the bottom and work your way up if you want to get to the conclusion. 

My distance parameter is set
My distance parameter is set close to 10 and the mountain site is 7 miles away, but I will read up on that. It is working now, so I'm hoping it stays that way
kg9dw's picture
The mountain node is set to
The mountain node is set to 10 miles? All of the nodes meshed in are within 10 miles of the mountain?
distance setting
No, My nanostation that is connected to the mountain top node is set to 10 miles which is at least a couple of miles more than the actual distance.  The mountain top node is set to 32 miles as there is a station about 29 miles north that is connected to it.
kg9dw's picture
Up to you...may be worth making sure you've got it set to miles and not kilometers. At that range there's a big difference. 

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. 
It is also equally important
It is also equally important everyone else also has their distance settings correct as well.

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."

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer