The LAN terrain is rolling hills with elevation above mean sea level
difference less than 200' vertical among all nodes.
Often trees topping off at 60'.
The local mesh is 49 stations spanning 32 kilometers.
(Use 49 nodes when considering the size of a link broadcast.)
Of the 26 nodes on 2397 MHz, Channel '-2':
3 high profile nodes (>100' agl); 2 a single node, always an omni.
(Way above the trees.)
3 medium profile nodes at 60-70', usually multi-band, typically an omni.
(At the tree tops.)
20 residential users, typically single port, with a mix of omni,
sector, and dish antennas. Antennas at 30-40' agl. (In the trees.)
I (screen) copied a link broadcast to .txt and counted the bytes.
4144 bytes. So, at 1 Mbps a link broadcast takes 4 ms.
(Please confirm or deny these values and math. I am likely in error.)
There will be 260 SSID beacons per second.
How long, in seconds, is a SSID beacon?
How long, in seconds, is a 4k node beacon link broadcast?
How often is a node beacon link broadcast?
Of this 26 node LAN, how much of a period of time is consumed by SSID and link beacons?
(IOW, what is available channel time compared to maintenance time
consumed by these 26 nodes on the same frequency?)
-----
Yet another Distance to Farthest Node setting scenario:
(I can visualise the mesh gurus rolling their eyes.
"Jeezel pete, not another DTFN thread in the Forum!"))
Station A only hears station B.
Station B hears station A and C.
Station C only hears station B.
Station A sends data to station B, which B receives error free, then
station C sends a link broadcast before station B is ready to send the 'ACK'.
The time consumed by station C's link broadcast is 4 milliseconds(?).
Although an 'ACK' is granted 'high priority', station B will
obey CSMA and not yet transmit a return 'ACK' if it is hearing
that link broadcast. Right? It would wait the 4 ms?
If DTFN=5 kilometers at station A, how many retries will occur in 4 ms? 28?
If DTFN=32km: 4?
Assuming B hears A and C with equal SNR:
Would station A's retries corrupt stations C's link broadcast?
You are here
Congestion, Maintenance, and Distance to Farthest Node
Wed, 01/17/2018 - 07:56
#1
nc8q
Congestion, Maintenance, and Distance to Farthest Node
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
"There will be 260 SSID beacons per second."
Actually there should only be ~52 beacons per second on 2GHz devices as we set it to approximately 2Hz some time back.
The beacon packets length is influenced by your SSID choice as that changes the packet size which changes the transmission time.
"I (screen) copied a link broadcast to .txt and counted the bytes. 4144 bytes. So, at 1 Mbps a link broadcast takes 4 ms."
A quick note that on channel -2 @ 5MHz the link rate is only 250Kbps (1Mbps is from the full 20MHz width, 10MHz is 500kbps)
Which messages did you capture? A link broadcast packet contains several types of messages, some messages are sent only directly to nodes that can hear (the majority are in this area) some however are received and rebroadcast in the next transmission (2 hops) and others are sent to the whole mesh network (255 hops) (these are the rarest ones to be sent the majority is kept in the link-local scope, this is why it can take a little file for a far away device on a bad link to find out about a node at the far side of the mesh) -- Size will depend upon information in each message, node name lengths, etc. The "HELLO" interval is currently once every 2s (this is what tells a local node "HEY I'm here") TC_INTERVAL and HNA_INTERVAL is 5s (these are messages about others the node knows about and its list of networks it knows about, along with other control messages) again most of these are sent as 1 hop with a backoff to multihop and whole mesh being less frequent.
"Station A sends data to station B, which B receives error free, then
station C sends a link broadcast before station B is ready to send the 'ACK'.
The time consumed by station C's link broadcast is 4 milliseconds(?)."
First off for this to occur it would need to be a smaller than maximum size packet, larger packets trigger the 802.11 RTS/CTS which will actually cause node C to hold off as it will hear from Node B that it wants to exchange traffic with node A (node A sends an RTS, and when node B sends its CTS node C hears and knows to hold off its beacon) So this scenario can happen in some cases but in other cases it can not.
"that link broadcast. Right? It would wait the 4 ms?
If DTFN=5 kilometers at station A, how many retries will occur in 4 ms? 28?
If DTFN=32km: 4?"
There is a limit on a max number of retransmits. Retransmits contain a random backoff chosen by the device and also include IIRC a logarithmic decay (it gets longer each backoff). You are on the right path though that the distance parameter does lengthen the backoff time so that less attemps are made in the same time window.
This may be more technical than you are looking for but you seem to have a fairly good rough understanding of what is going on and may find the 802.11 standards to be an informative read to know what is going on at the very low RF level. These are one of the few standards that are made available online free of charge by the IEEE.
http://ieeexplore.ieee.org/document/7786995/
"Assuming B hears A and C with equal SNR:
Would station A's retries corrupt stations C's link broadcast?"
The answer is a Maybe depending on how you are using the numbers, for example the SNR shown on the page are done for beacon packets, these are sent at the lowest datarate and highest power, directed packets (packets aimed at a signel node) however are sent at higher speed and lower RF power (higher speed requires a backdown on the power to maintain linearity) So the packets may or may not corrupt C's report depending on a large number of factors.
Sorry I don't have any hard numbers for you at the moment (busy work day) but just wanted to clear up a few items to start with.
What we've seen locally in practice is exactly the example in this post, plus consider that station C has a nearby neighbor D (which does not have line of sight to B, the tower). So not only did we have the "hidden node" problem, we had the "exposed node" problem: https://en.wikipedia.org/wiki/Exposed_node_problem .
If Node D wants to VOIP to Node A, then the throughput could be cut down to ~33% (and more loss due to overhead) of what is possible as compared to changing channels across each hop--omni at the tower. The latency is also degraded by several factors. If only 1 of the 3 half-duplex links can transmit at a time, except when both A and D are able to transmit at the same time. It could be 20% or less thoughput when considering all the nodes and traffic patterns. If all links can transmit at the same time, then you always go end to end with maximum thoughput to get data from A to D.
Locally, I've be recommending to groups that they begin to use more 3Ghz or 5Ghz and sectorize multiple node coverage at the towers and cell sites. Benefit is that you have the channels available to cross over through tower hops, cell site hops, etc. Locally here in OC, we can reach the edge of the network from end to end over ~30 hops and still have <100msec latency and many Mbytes of throughput with many users and heavy loads on the network.
Joe AE6XE