[Spread-users] Multiple spread daemons on the same machine &real-time scheduling?
Matthew Gillen
mgillen at bbn.com
Fri Dec 1 09:29:56 EST 2006
Matt Garman wrote:
> Several weeks ago, I prompted a small thread about running spread with
> real-time priority.
>
> http://commedia.cnds.jhu.edu/pipermail/spread-users/2006-October/003077.html
>
>
> I just had a thought: has anyone ever considered using the POSIX
> real-time scheduling API to achieve this result? E.g., functions like
>
> sched_getscheduler()
> sched_get_priority_max()
> sched_setscheduler()
> sched_getparam()
>
> At least on Linux, you have to run as root to get real-time priority.
> But in the sample programs I've written using the above (and related)
> functions, it's pretty easy to make a whole process real-time. In
> other words, I was thinking you could probably just insert a few of
> the right POSIX real-time priority functions into spread's main()
> function, and recompile.
>
> Thoughts?
You could certainly do that, and I'm sure you'd get good results.
I did something a little "cheaper" (in both quality and effort) when I lowered
the timeouts in membership.c to the ~50ms range and started seeing a lot of
spurious leaving and re-joining (since there were > 100ms stretches where the
spread daemon didn't get scheduled by the OS: I just renice'd the spread
daemon to a higher priority. You can't get your process in the real-time
scheduling class that way, but it worked well enough for me.
I had a script that started the spread daemon, then did something like this:
sudo renice -20 -p $!
Which sets the last pid to the highest priority.
If you're using Solaris, or even newer linux kernels (>=2.6.18; after the
inclusion of bunch of pre-emption/real-time patches), then using the POSIX api
to actually put your process into the real-time scheduling class will
probably yield more consistent results with respect to scheduling.
Matt
More information about the Spread-users
mailing list