TimeKeeper will move itself to the last CPU on the system (highest numbered CPU) unless configured to do otherwise with the CPU= configuration variable. This is designed to reduce the impact on other applications. If a user wants to reduce TimeKeeper impact further by reducing CPU consumption there are a few options available to do that.
The greatest impact on TimeKeeper CPU consumption is the time source accuracy. If a source is very noisy, inaccurate or shows high jitter TimeKeeper will apply extra filtering and use more data to establish a good time estimate which consumes more CPU. The more accurate a time source is the less CPU TimeKeeper requires.
CPU intensive options
Setting the LOWQUALITY=1 option will cause TimeKeeper to apply extra filtering and use more data for clock modeling. This uses quite a bit more CPU than the default of LOWQUALITY=0. Turning this option off will greatly reduce CPU use.
SOURCECHECK=1 will cause Timekeeper to cross-check all time sources and do a great deal more work than with this option disabled. Setting this value to the default of SOURCECHECK=0 will reduce CPU consumption.
Number of sources
The more sources that TimeKeeper must query, model and manage the more CPU TimeKeeper will use. Reducing the number of sources will reduce the amount of CPU that TimeKeeper consumes.
Each time TimeKeeper queries a time source it must update the clock model and time estimates. This is where TimeKeeper consumes most CPU. Reducing the query rate can greatly reduce CPU consumption. For NTP sources this can be changed at the client side but for PTP sources must be configured on the server.
PTP vs NTP
PTP is a more complicated protocol than NTP and requires additional CPU in
order to process. Using NTP instead of PTP can decrease CPU use slightly.
One useful feature of NTP is that the client defines the query rate rather than the server allowing multiple query rates from different clients using the same server.
The LOWCPU=1 option will cause TimeKeeper to use different clock models that require far less CPU than the default clock models. They are less accurate and less able to reject outliers. This option will make a significant difference in CPU consumption at the cost of a small amount of accuracy.