docs: Amend page on RFNoC properties

Add an additional paragraph on back-edges, and when *not* to declare them.

1 files changed, 12 insertions, 2 deletions

diff --git a/host/docs/properties.dox b/host/docs/properties.dox
index 8de4a50ab..a8f505382 100644
--- a/host/docs/properties.dox
+++ b/host/docs/properties.dox
@@ -342,12 +342,22 @@ frequency offset digitally, and then apply some custom DSP before transmitting
 the signal again, using the same radio block. In order to create a valid graph
 that UHD can handle, one of the edges needs to be declared a back edge.
 
-Edge properties are not propagated across back edges, however, they must still
+Edge properties are not propagated across back edges. However, they must still
 match up after property resolution is done. For example, if the DDC were to be
 configured to decimate the sampling rate, and the custom DSP block would not
 correct for that, the output edge property `samp_rate` of the custom DSP block
 would be mismatched compared to the input edge property `samp_rate` of the radio.
-
+In that case, UHD will throw an exception when trying to resolve properties,
+even if it is declared a back-edge.
+
+Note that property propagation along edges is required for certain operations.
+Therefore, it is highly recommended to not declare edges as back-edges unless
+necessary. In the graph above, any of the three edges could have been declared
+a back-edge to result in a topologically valid graph that can still resolve its
+properties, but the one chosen is the most intuitive selection. If any *two*
+edges were declared back-edges, at least one of the DDC or Custom DSP blocks
+might cease to function, e.g., because it doesn't have access to the tick rate
+property.
 
 \section props_unknown Handling unknown properties