Time inside Kernel

Time inside Kernel

Post by Joseph Steinbe » Mon, 31 Jul 1995 04:00:00



What is the proper way to read the system clock from within the kernel
(inside a device driver)?
JS
 
 
 

Time inside Kernel

Post by Andrew Gabrie » Mon, 31 Jul 1995 04:00:00




Quote:> What is the proper way to read the system clock from within the kernel
> (inside a device driver)?

If you mean the current date and time, sorry no idea.

If you mean the HZ clock, it's held in a variable called lbolt,
and incremented HZ times a second. You can just read it if you
declare it as an extern.

Someone told me once that the name lbolt is short for lightning bolt,
but I've no idea if this is true, or quite what the significance is.
--



 
 
 

Time inside Kernel

Post by Paul Philli » Tue, 01 Aug 1995 04:00:00




>If you mean the HZ clock, it's held in a variable called lbolt,
>and incremented HZ times a second. You can just read it if you
>declare it as an extern.

In the interest of writing portable and maintainable code, lbolt
should be accessed via drv_getparm() rather than being accessed
directly.  This allows the kernel implementor to shield internal
changes from the device driver author.  I don't know whether this
advice holds outside of SVR4.  

I'm also curious about the origin of lbolt...

 -PSP

--
"I resent that because I was FORCED into ALL those mental hospitals by
 this government, wihch I am going to SUE TO HIGH HEAVEN, and by enemies
 who can read minds, etc..."
     -- Gary Stollman

 
 
 

Time inside Kernel

Post by Joseph Steinbe » Tue, 01 Aug 1995 04:00:00


What I want to do is read the TIME and DATE from inside the kernel (in a
device driver).
How is this done?
JS


: >If you mean the HZ clock, it's held in a variable called lbolt,
: >and incremented HZ times a second. You can just read it if you
: >declare it as an extern.

: In the interest of writing portable and maintainable code, lbolt
: should be accessed via drv_getparm() rather than being accessed
: directly.  This allows the kernel implementor to shield internal
: changes from the device driver author.  I don't know whether this
: advice holds outside of SVR4.  

: I'm also curious about the origin of lbolt...

:  -PSP

: --
: "I resent that because I was FORCED into ALL those mental hospitals by
:  this government, wihch I am going to SUE TO HIGH HEAVEN, and by enemies
:  who can read minds, etc..."
:      -- Gary Stollman

 
 
 

Time inside Kernel

Post by John Hax » Tue, 01 Aug 1995 04:00:00


|> Someone told me once that the name lbolt is short for lightning bolt,
|> but I've no idea if this is true, or quite what the significance is.

Processes sleeping on lbolt are woken once a second.  If you have something
like
        sleep (&lbolt);

you'll be woken on the next 1 second tick--all processes sleeping
on lbolt are woken on the one second tick, something like a bolt of
lightning going off inside the computer.  It's used just to get a short
delay in the hope that things might be better later.

--

ISODE Consortium                                        +44 181 332 9091

These are my opinions and have nothing to do with my employer.

 
 
 

Time inside Kernel

Post by Thong » Wed, 02 Aug 1995 04:00:00


: What I want to do is read the TIME and DATE from inside the kernel (in a
: device driver).
: How is this done?
: JS

        I cannot imagine why you would want to do this.  For metric
        collection you can just use the "lbolt" variable via the
        drv_getparm(3D) function as suggested by other posters.

        However, there are ways to get at the TIME and DATE (time since epoch)
        but these are extremely system dependent (depending which Unix
        you are using, which hardware platform and also which release).



: : >If you mean the HZ clock, it's held in a variable called lbolt,
: : >and incremented HZ times a second. You can just read it if you
: : >declare it as an extern.

: : In the interest of writing portable and maintainable code, lbolt
: : should be accessed via drv_getparm() rather than being accessed
: : directly.  This allows the kernel implementor to shield internal
: : changes from the device driver author.  I don't know whether this
: : advice holds outside of SVR4.  

: : I'm also curious about the origin of lbolt...

: :  -PSP

--
Thong Ly                        Unix Products Development, NOVELL Japan, Ltd.


 
 
 

Time inside Kernel

Post by Andrew Fitzgibb » Wed, 02 Aug 1995 04:00:00



> [...] all processes sleeping
> on lbolt are woken on the one second tick, something like a bolt of
> lightning going off inside the computer.  It's used just to get a short
> delay in the hope that things might be better later.

Just out of interest -- I've never known about lbolt before.  Couldn't this
lead to performance problems if many processes are woken at about the same
time.  I can imagine a situation where one resource is heavily used, and
many processes sleep on lbolt for a retry, then all retry at the same time.

A.

--

Artificial Intelligence, Edinburgh University.               +44 031 650 4504
<a href=http://www.dai.ed.ac.uk/staff/personal_pages/andrewfg> Home Page </a>
                         "Never say there is no way" -- me.

 
 
 

Time inside Kernel

Post by Joseph Steinbe » Wed, 02 Aug 1995 04:00:00


The answer to my ? was to use microtime().
JS


: >
: > [...] all processes sleeping
: > on lbolt are woken on the one second tick, something like a bolt of
: > lightning going off inside the computer.  It's used just to get a short
: > delay in the hope that things might be better later.

: Just out of interest -- I've never known about lbolt before.  Couldn't this
: lead to performance problems if many processes are woken at about the same
: time.  I can imagine a situation where one resource is heavily used, and
: many processes sleep on lbolt for a retry, then all retry at the same time.

: A.

: --

: Artificial Intelligence, Edinburgh University.               +44 031 650 4504
: <a href=http://www.dai.ed.ac.uk/staff/personal_pages/andrewfg> Home Page </a>
:                          "Never say there is no way" -- me.

 
 
 

Time inside Kernel

Post by Thong » Thu, 03 Aug 1995 04:00:00



: |> Someone told me once that the name lbolt is short for lightning bolt,
: |> but I've no idea if this is true, or quite what the significance is.

: Processes sleeping on lbolt are woken once a second.  If you have something
: like
:       sleep (&lbolt);

: you'll be woken on the next 1 second tick--all processes sleeping
: on lbolt are woken on the one second tick, something like a bolt of
: lightning going off inside the computer.  It's used just to get a short
: delay in the hope that things might be better later.

This sounds strange ...

In my understanding, if a process sleeps on an event then it only wakes
up if someone executes a wakeup on the same event.  The 1 a second
clock handler does not usually issue wakeup calls for lbolt.

--
Thong Ly                        Unix Products Development, NOVELL Japan, Ltd.


 
 
 

Time inside Kernel

Post by John Hax » Thu, 03 Aug 1995 04:00:00



|>

|> >
|> > [...] all processes sleeping
|> > on lbolt are woken on the one second tick, something like a bolt of
|> > lightning going off inside the computer.  It's used just to get a short
|> > delay in the hope that things might be better later.
|>
|> Just out of interest -- I've never known about lbolt before.  Couldn't this
|> lead to performance problems if many processes are woken at about the same
|> time.  I can imagine a situation where one resource is heavily used, and
|> many processes sleep on lbolt for a retry, then all retry at the same time.

yes.  in 4.2BSD, lbolt was used when you ran out of clist blocks and a
process would sleep on lbolt in the hope that things would get better in
a second.  Of course, if you had a chronic clist storage, the system
would thrash like mad.  lbolt wasn't all that heavily used though.

--

ISODE Consortium                                        +44 181 332 9091

These are my opinions and have nothing to do with my employer.

 
 
 

Time inside Kernel

Post by Jim Re » Thu, 03 Aug 1995 04:00:00


   yes.  in 4.2BSD, lbolt was used when you ran out of clist blocks and a
   process would sleep on lbolt in the hope that things would get better in
   a second.  Of course, if you had a chronic clist storage, the system
   would thrash like mad.  lbolt wasn't all that heavily used though.

Indeed. It still isn't. In NetBSD (4.4BSD), there are a handful of
lbolt sleeps. None look as if they're called often - most are for tty
ioctls to/from background processes or probing Sun keyboards. There a
couple for NFS over TCP and one for the swapper. lbolt doesn't even
get used to trigger the once a second process priority calculations
anymore: schedcpu calls itself via a timeout and actually performs the
wakeup(&lbolt) call.

 
 
 

Time inside Kernel

Post by Jim Re » Fri, 04 Aug 1995 04:00:00


   In my understanding, if a process sleeps on an event then it only wakes
   up if someone executes a wakeup on the same event.  The 1 a second
   clock handler does not usually issue wakeup calls for lbolt.

Something *will* issue a wakeup(&lbolt) call once a second. I've yet
to meet a UNIX system which doesn't. The once a second lightning bolt
is one of those things that probably will never go away. Too much
kernel code - device drivers mainly - has been written by people who
"just know" that sleeping on lbolt will cause a 1 second delay for
this to be deprecated without a lot of weeping and gnashing of teeth.

How the lbolt wakeup is issued is implementation dependent. One way or
the other, it will come from the real-time clock interrupt handler. In
some cases, this routine does the wakeup directly - this was how it
was done in V6 and V7. In BSD kernels, it's done by schedcpu which
runs once a second. That routine schedules another run of itself using
timeout() which is of course driven off the real-time clock interrupt
routine.

 
 
 

Time inside Kernel

Post by Jim Re » Thu, 10 Aug 1995 04:00:00



   Just out of interest -- I've never known about lbolt before.  Couldn't this
   lead to performance problems if many processes are woken at about the same
   time.  I can imagine a situation where one resource is heavily used, and
   many processes sleep on lbolt for a retry, then all retry at the same time.

In theory, yes. In practice, no. lbolt sleeps are very rarely used
these days. For example 4.4 BSD only seems to use them for handling
signals to/from background processes on a tty. Some device drivers may
use lbolt sleeps for things like waiting a "long time" for something
to happen like a controller to reset itself. I very much doubt if any
system sees more than a negligible number of lbolt sleeps during its
lifetime.

There used to be performance problems with multiple wakeups in early
NFS implementations. Every nfsd would get woken up every time an NFS
request arrived. One would process that request and the others would
go back to sleep whenever they got to run. This also had a * habit
of thrashing the MMU contexts on the Sun-3 and early Sparcs: information
in the MMU about probably more useful processes would get blootered by
all those redundant contexts for nfsd. This got promptly fixed:

        % nm /vmunix | grep wakeup
        ....
        0e0993b8 D _nfs_wakeup_one_biod
        0e09b9d8 D _nfs_wakeup_one_nfsd
        ....

 
 
 

Time inside Kernel

Post by Nick Gianniot » Fri, 11 Aug 1995 04:00:00



>What is the proper way to read the system clock from within the kernel
>(inside a device driver)?

On SunOS 4.1, the global system time is available in a global var "time"
declared thusly:

        #include <sys/time.h>

        extern struct timeval time;

and then just reference the fields

        time.tv_sec &
        time.tv_usec.

Nick

 
 
 

Time inside Kernel

Post by Richard Tob » Sat, 12 Aug 1995 04:00:00



>One would process that request and the others would
>go back to sleep whenever they got to run. This also had a * habit
>of thrashing the MMU contexts on the Sun-3 and early Sparcs: information
>in the MMU about probably more useful processes would get blootered by
>all those redundant contexts for nfsd. This got promptly fixed:

If I remember correctly, it was also changed so that nfsds didn't have
MMU contexts (which they don't need, since they're in a non-returning
system call all the time).

-- Richard

--
"... we were extremely sceptical, like most people, about '*
 theories of history' ..."        - The Holy * and the Holy Grail

 
 
 

1. Getting system time inside a device driver? (Interactive)

Hello.

I am trying to read the system time (ala gettimeofday) in a device
driver for a SunSoft Interactive Unix system. There must be some
kernel service to do this, or some global time structure I can
access, right?

Anyone know how to do this?

AdvThanks,

-- Gil.
--
--------------------------------------------------------------------
-- Gil Tene                     "Some days it just doesn't pay     -

--------------------------------------------------------------------

2. Retrieving the title of an (n)xterm window?

3. "Linux Inside": Spoof of Intel Inside

4. screenlock

5. authorization inside the LAN takes a - l o n g - time

6. Problem compile Apache with php3 on HPUX

7. change time on all machines inside a LAN

8. nfs problem

9. Formattet output inside variable / line brak inside variable

10. FTP client inside linux firewall communicating with FTP server inside another linux firewall

11. time problem inside dialer program...

12. Windows XP time server update from box inside firewall

13. convert UT time in local time / local time in UT time