Nathan Clark wrote:
I'm looking for a distro which uses ideally a real time clock, or a
clock with a deviation of less than 1 millisecond to support
applications that require real time, or a near enough real time
environment. Why? I'm porting a time critical telephony product from
Solaris to Linux.
I think you're confusing the jargon word "real time" with 'accurate time'.
You'll find NTP will easily maintain this sort of resolution, and there
is a world full of NTP applicances which sync with GPS or CDMA time
sources and then provide a stratum 1 NTP service.
The question then is what is the kernel's scheduling policy and maximum
latency so that your timestamp application runs within some bounds. The
good news is that the scheduler delay can be adjusted by applications,
see the code at the end of this posting.
The bad news is that kernel latency can be quite high on older Linux
kernels. The newer low-latency kernel compile option also occassionally
leads to machine locks :-(. Red Hat have taken another path, there
default kernel yields to the scheduler during high latency tasks.
Despite your customer's wishes, you're best off with a custom kernel.
Has anyone had any experience at hacking either of these distro's so
they use a real time clock or been able to tweak the clock so there is
less than 1 millisecond deviation?
Yep, we use NTP synced to GPS to provide a timesource for SDH bearers.
I've looked at RTLinux, but I highly doubt the support they can buy for
SUSE or Red Hat will include support for this.
The real time vendors have better support than Red Hat or SuSE, you just
have to pay for it.
A warning that your customer's requirements for a supported platform are
somewhat misplaced. No vendor aiming at the broad Information Technology
market (eg: Red Hat, Novell, Sun or IBM) is going to support the specific
requirements you place on the operating system. If it doesn't work you
will have to fix it.
If that worries you, go and talk with one of the NTP appliance manufacturers.
If you e-mail me privately I'll tell you my views of the ones we tested.
Cheers,
Glen
/* Lower jitter from system activities on this process.
*
* Lock the processes pages to stop them paging, increase scheduling
* priority, reduce jitter from scheduler.
*/
static void
lower_jitter(void)
{
struct sched_param sp;
log_debug("Lowering process jitter");
/* Don't page this process. */
if (mlockall(MCL_FUTURE) == -1)
{
log(LOG_WARNING,
"mlockall() failed, this process may page, continuing");
}
/* Increase our priority when the OS schedules processes to the
* maximum possible.
*/
errno = 0;
setpriority(PRIO_PROCESS, getpid(), -20);
if (errno) {
log(LOG_WARNING,
"setpriority() failed, will run at normal priority, "
"continuing");
errno = 0;
}
/* Select a deterministic scheduling algorithm. */
memset(&sp, 0, sizeof(sp));
if ((sp.sched_priority = sched_get_priority_max(SCHED_FIFO)) == -1) {
log(LOG_WARNING,
"sched_get_priority_max() failed, won't alter scheduler, "
"continuing");
errno = 0;
}
else {
if (sched_setscheduler(0, SCHED_FIFO, &sp) == -1) {
log(LOG_WARNING,
"sched_setscheduler() failed, "
"will run with standard scheduler, continuing");
errno = 0;
}
}
}
--
Glen Turner Tel: (08) 8303 3936 or +61 8 8303 3936
Australia's Academic & Research Network www.aarnet.edu.au
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
