of what an engineer can conceivably influence for a timing design, it does not help to go into further depth. However, something that the operator can influence is PTP message rates. 9.3.1 Packet/Message Rates One issue that provokes debate among engineers is the choice of the appropriate message rate needed to accurately carry time. The widespread adoption of the G.8275.1 profile has helped some- what calm this debate because the rates in that profile are fixed and there is nothing to disagree about. In many implementations, the rates cannot be changed because, once the profile is con- figured, the rates are automatically set to the values in the recommendation. Some other, non-tele- com profiles also fix the rates of some message types (see Chapter 7 for details on other profiles). For the PTPoIP cases of G.8275.2 (and G.8265.1 for frequency), there is still flexibility because the engineer can still decide what is the desired rate for each of the messages. In the authors' experi- ence, most customers tend to deploy those two profiles with a rate in the range of 32-64 messages per second, with 64 being the most common. Increasing the message rate obviously effects the scalability of the clock, because exchanging more messages for every slave means that the master can support fewer slaves. Operators deploying PTP for use cases with lower accuracy requirements and more scalability tend to migrate toward lower rates (one example being the cable industry). The main drivers behind increasing the traffic rate are as follows: Having more messages results in the slave having more data, which should theoretically im- prove accuracy, lock times, and general performance. Having more messages means a better selection and more chance of being able to receive a set of timestamps that represent the minimal transit time. If the messages suffer a lot of PDV, then having more to choose from gives a better chance of good timestamps arriving unhindered. If the operator is struggling to get a slave to lock to a master because of ex