Comment 1 for bug 1970776

Reviewed: https://review.opendev.org/c/starlingx/utilities/+/839795
Committed: https://opendev.org/starlingx/utilities/commit/9183ef96db02faa9beeaa4021ad59e06ae6627ce
Submitter: "Zuul (22348)"
Branch: master

commit 9183ef96db02faa9beeaa4021ad59e06ae6627ce
Author: Cole Walker <email address hidden>
Date: Thu Apr 28 11:58:02 2022 -0400

    [PTP SyncE] Set niceness -10 for ice-gnss threads

    Problem: the master offset value in ts2phc intermittently spikes and
    causes the system to be incorrectly adjusted.

    This behaviour is seen when using the Intel Westport Channel NIC and ice
    driver 1.7.16 on a realtime kernel.

    Analysis of the issue shows that the ice-gnss thread responsible for
    reading from the GNSS and writing to the tty for consumption by ts2phc
    is sometimes getting delayed on realtime systems. Examination of
    typical workloads on the platform cores and discussion between Intel -
    the driver supplier - and the StarlingX communitiy has lead to an
    agreement to increase the priority of this thread.

    Most of the processes ordinarily running on the platform cores run at
    the default niceness of 0, so -10 has been selected to elevate the
    ice-gnss thread above those while leaving room on either side for other
    process tuning. It is also worth noting that the ice-gnss thread is
    being left as SCHED_OTHER, so processes assigned to SCHED_FIFO may still
    preempt it.

    Testing:

    PASS: Applied change to AIO-SX with Westport Channel NIC, ice-gnss
    thread is set to nice -10 after host lock/unlock.

    PASS: Cumulative 24 hours of ts2phc logs show no replication of fault
    when thread niceness is set to -10. When the thread is nice 0, fault
    occurs multiple times per hour.

    Closes-bug: 1970776

    Signed-off-by: Cole Walker <email address hidden>
    Change-Id: I1f45530f37ded11ab7406a5a1068f896a06c8843