Subj : Re: Solaris real-time thread capabilities
To   : comp.unix.solaris,comp.programming.threads
From : Greg Menke
Date : Tue Sep 06 2005 07:42 pm


capnwhit@yahoo.com writes:

> Hello Greg, Thanks for your reply. My current question is related to
> real-time scheduling capabilities of Solaris 8 and/or Solaris 9. The
> problem can be boiled down to the following very simple tests:
> 
> 1. Can I use nanosleep to try to wake up every 10 ms (on average)?
> 2. Can I use SIGALRM instead?
> 3. Can I use gethrtime instead?

Have you run empty loops using those various techniques to see if you
can achieve the timing you're looking for?  If yes (and I imagine
nanosleep and gethrtime will be a reasonable way to approach it), then
the problem is elsewhere.  Perhaps you can do the empty loop test with
nanosleep and SIGALRM and see which gives you the minimum jitter.
 

> For the time being, you can completely ignore the network, transfering
> data, IP, TCP, UDP and/or jitter buffers...

Once you've confirmed you can run a simple for loop at something close
to your target rate, then these will be the next hurdle.  That is almost
certainly where the problems are coming from.

 
> Greg Menke wrote:
> > It sounds to me as if you have not designed your system to
> > handle real-world characteristics of computers and networks.
> >
> Wow... that's why I hate posting on Usenet... because people jump into
> conclusions... I'm sorry Greg... I appreciate your taking the time to
> share your knowledge, but you know _NOTHING_ about the design of my
> "real-world" application... all you know is the PROBLEM STATEMENT as
> stated in my opening post: "--How to obtain reliable 10 ms timing from
> Solaris on a 450 MHz UltraSparc2?"... Even though my post was very well
> articulated, you start making assumptions about delays in intervening
> switches and routers and claiming that "it sounds like I have not
> designed my system properly"... That's quite a disappointing response
> from someone like yourself who could probably offer something positive
> to the community...

Your post certainly was articulated, but lacked essentially all the
detail needed to evaluate the problem- which lead to my (hasty)
assumption.  Most of the length of your post is detailing the scheduling
parameters you were changing around- but there wasn't even the results
of prstat showing how busy the cpu was while executing your job.

Latency and jitter don't happen in isolation, they are effects and the
first set of those to examine are the things your code does.  In order
to try and find your problem we need details about what "packages" are,
how you acquire them, how long it takes to process them, how you send
them, etc..  more than likely your latency problem is coming from some
of these processing steps.  The more detailed your question, the more
detailed the answer.

I do apologize for jumping off the handle.  At work I get a lot of
questions about bugs in operating systems which have almost all been due
to trivial bugs, assumptions and misunderstandings made by the
applications programmer.  For some reason its often easier for people to
suspect a subtle problem in the OS than a simple one in the program
they're writing.

Gregm

.