[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