It appears that Red Hat 7 process nice values range is 0-99 with 0 being the lowest priority.
On other Linux distributions, various forums talk about nice values ranges -20 to 19. In Red Hat, higher priority values are higher number, in the other case the more negative value assign higher priority to a process. Is this correct? Why such a difference?

All indications I see on my RHEL7 system say it still does the -19 to 20 with lower numbers being higher priority. The man page for setpriority has a nice discussion of this.

What are you seeing that makes you think it is 0 - 99?

I used chrt command to find out minimum and maximum valid priorities for each scheduling algorithm and I've got this:
# chrt -m
Output:
SCHED_OTHER min/max priority : 0/0
SCHED_FIFO min/max priority : 1/99
SCHED_RR min/max priority : 1/99
SCHED_BATCH min/max priority : 0/0
SCHED_IDLE min/max priority : 0/0

I then found out in another LQ post that values 1-99 are used to set Real Time priority for when an RT scheduling policy like SCHED_FIFO or SHED_RR is set. So, calues -20 to 19 are for non real time processes and I believe the scheduler order would be
to pick first a process in a RT scheduling class (if that exist/is set) then in the other scheduling policy, and within each scheduling policy the process with highest priority (i.e: for RT , higher values near 99, for others policies non RT, then lower nice values have higher priority, like near -20).
I haven't tried to set my own scheduling policies for set of processes, so what ever I stated here may not be exactly working as I stated.
Thanks.

1 members found this post helpful.

You are correct that the priority (nice ...) value ranges are different for the different available schedulers.

Linux would not be my choice for a true "real-time" application. Linux is a general purpose operating system, and this permeates its entire design. True RTOSes are not the least bit "friendly" to interactive users and generally do not support them at all.

For the "ordinary" scheduler, the nice setting is only one of several inputs that are considered, and usually the only thing that really matters is that "the setting is 'nice.'" It doesn't matter so much "how 'nice'" it is. You're simply giving the scheduler a clue that this particular unit of work isn't interactive and can afford to receive "less, but longer" time slices. (If the work does a lot of I/O or otherwise creates high non-CPU demands on the machine, it won't be very "nice" no matter what you say.)

1 members found this post helpful.

Perfectly agree with you, but was just trying to set some specific process to RT to see the effects on a benchmark.
Thanks!