Sponsored Content
Full Discussion: Bugs with clock()
Operating Systems Solaris Bugs with clock() Post 302180753 by smanu on Tuesday 1st of April 2008 04:17:16 AM
Old 04-01-2008
Bugs with clock()

Hi there!!!

Need your help in solving some tricky problems.

Since clock() as such is buggy on SUN OS 5 we have started using gettimeofday() in our RTOS applications based on Solaris 9.

The problems we actually encountered previously were - the applications kind of freeze/hang eternally on some Solaris hosts(Sun Fire V215). The problem is as such inconsitent both with respect to frequency & also host type.

Using gettimeofday() has solved us these inconsitent freezing problems
on various hosts(Sun-Fire-V215, SUN Blade).

So far so good :-) .

But sadly, those same old problems are recurring on Sun-Fire-V445 machines!!!

Now, the question!
Do you have any idea if we have any specific version of clock that can be used on Sun-Fire_V445?

My idea was that clock() & the patches/problems there off are basically dependant on OS version & the processor type should not really matter.

But it keeps me surprised that, using original buggy clock() works on V445.
So we need a common solution that works on all hosts.

Your help in this regard would be greatly appreciated.

Looking forward to your answers!

Please let me know if you need further information, if I was not specific anywhere.

/smanu.
 

4 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

Is it a bugs for find command? :(

Hi! When i am trying to use find command to seacrh files in current directory, it help me to search for it sub-directory also. Is there anyway to avoid it? I am using unix operating system. My friend told me that only linux did handle this, is it true? (4 Replies)
Discussion started by: AkumaTay
4 Replies

2. UNIX for Beginners Questions & Answers

Bugs in my new Ubuntu installation

I recently bought a new HP Spectre x360 laptop and installed Linux (Ubuntu 16.04 LTS 64 bit) for the first time. I am seeing various bugs. I don't know if the problems are due to: (a) Hardware problems with the new laptop. (b) Software issues, i.e. Ubuntu not working with the other... (7 Replies)
Discussion started by: twelth_hour
7 Replies

3. UNIX for Beginners Questions & Answers

Getting started with fixing bugs for Linux

Okay I want to try my luck at fixing bugs for the Fedora OS, but I guess this question deals with any Linux distro or any open source OS for that matter. I want to know how I can start fixing bugs on the OS level. For example the particular bug that I want to target is this logout bug I mean... (6 Replies)
Discussion started by: sreyan32
6 Replies

4. What is on Your Mind?

Meltdown and Spectre CPU bugs

This seems a bit serious: Meltdown, Spectre: The password theft bugs at the heart of Intel CPUs • The Register Vulnerability Note VU#584653 - CPU hardware vulnerable to side-channel attacks Project Zero: Reading privileged memory with a side-channel (8 Replies)
Discussion started by: Scrutinizer
8 Replies
ADJTIME(3)						     Linux Programmer's Manual							ADJTIME(3)

NAME
adjtime - correct the time to synchronize the system clock SYNOPSIS
int adjtime(const struct timeval *delta, struct timeval *olddelta); Feature Test Macro Requirements for glibc (see feature_test_macros(7)): adjtime(): _BSD_SOURCE DESCRIPTION
The adjtime() function gradually adjusts the system clock (as returned by gettimeofday(2)). The amount of time by which the clock is to be adjusted is specified in the structure pointed to by delta. This structure has the following form: struct timeval { time_t tv_sec; /* seconds */ suseconds_t tv_usec; /* microseconds */ }; If the adjustment in delta is positive, then the system clock is speeded up by some small percentage (i.e., by adding a small amount of time to the clock value in each second) until the adjustment has been completed. If the adjustment in delta is negative, then the clock is slowed down in a similar fashion. If a clock adjustment from an earlier adjtime() call is already in progress at the time of a later adjtime() call, and delta is not NULL for the later call, then the earlier adjustment is stopped, but any already completed part of that adjustment is not undone. If olddelta is not NULL, then the buffer that it points to is used to return the amount of time remaining from any previous adjustment that has not yet been completed. RETURN VALUE
On success, adjtime() returns 0. On failure, -1 is returned, and errno is set to indicate the error. ERRORS
EINVAL The adjustment in delta is outside the permitted range. EPERM The caller does not have sufficient privilege to adjust the time. Under Linux the CAP_SYS_TIME capability is required. CONFORMING TO
4.3BSD, System V. NOTES
The adjustment that adjtime() makes to the clock is carried out in such a manner that the clock is always monotonically increasing. Using adjtime() to adjust the time prevents the problems that can be caused for certain applications (e.g., make(1)) by abrupt positive or nega- tive jumps in the system time. adjtime() is intended to be used to make small adjustments to the system time. Most systems impose a limit on the adjustment that can be specified in delta. In the glibc implementation, delta must be less than or equal to (INT_MAX / 1000000 - 2) and greater than or equal to (INT_MIN / 1000000 + 2) (respectively 2145 and -2145 seconds on i386). BUGS
A longstanding bug meant that if delta was specified as NULL, no valid information about the outstanding clock adjustment was returned in olddelta. (In this circumstance, adjtime() should return the outstanding clock adjustment, without changing it.) This bug is fixed on systems with glibc 2.8 or later and Linux kernel 2.6.26 or later. SEE ALSO
adjtimex(2), gettimeofday(2), time(7) COLOPHON
This page is part of release 3.44 of the Linux man-pages project. A description of the project, and information about reporting bugs, can be found at http://www.kernel.org/doc/man-pages/. Linux 2008-06-22 ADJTIME(3)
All times are GMT -4. The time now is 12:32 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy