Question Detail
I get the message "Not enough address table entries for optimum efficiency" when I compile my code. Is this serious? Will it impact performance?
Solution
A Neuron Chip has up to 15 outgoing message ports. Ports are also known as "address table entries" or "address table slots". Each bindable message tag consumes one port, whether bound or not. Network variables can share ports, but there must be at least one port available. However, if there aren't enough entries available for each output network variable to have its own port, you will get this warning. This is because the binder would then have to share the remaining address table entries among the network variables.
Example: If there are three network variables (each going to a different destination) and there are only two address table entries, then at least two of the network variables would have to use the same address table entry (if they are all connected). Now let's assume that all the variables are connected, each as a point-to-point connection to a different node. If each variable had its own address table entry, the LonTalk messages would all use subnet/node (i.e. point-to-point) addressing. However, for the two variables sharing the same entry, a group will be constructed. This means that when either variable is updated, the updates will go to all members in the group. This does not cause a problem, as the nodes which don't have that variable throw the update away. The inefficiency that the compiler is warning about, though, is that each destination in the group, regardless of whether it uses the message, will respond with an acknowledgment message. This situation thus leads to an increased number of unnecessary acknowledgements, or extra network traffic.
Example: If there are three network variables (each going to a different destination) and there are only two address table entries, then at least two of the network variables would have to use the same address table entry (if they are all connected). Now let's assume that all the variables are connected, each as a point-to-point connection to a different node. If each variable had its own address table entry, the LonTalk messages would all use subnet/node (i.e. point-to-point) addressing. However, for the two variables sharing the same entry, a group will be constructed. This means that when either variable is updated, the updates will go to all members in the group. This does not cause a problem, as the nodes which don't have that variable throw the update away. The inefficiency that the compiler is warning about, though, is that each destination in the group, regardless of whether it uses the message, will respond with an acknowledgment message. This situation thus leads to an increased number of unnecessary acknowledgements, or extra network traffic.
Related Products
- LonBuilder 3.01
- Neuron C
- NodeBuilder 1.5
- NodeBuilder 3.0
- NodeBuilder 3.1
Comments