Soft Timers

What can we squeeze in between finishing an interrupt and returning
back to what we were running before?

What happens when there is an event you want to schedule and no soft
timer opportunity occurs?  They set a long hardware interrupt to make
sure they get scheduled occasionally.

Problem with having the soft timer run -before- handling the exception
or the syscall is that 1) the exception really might need to be
operated on and should have high priority and 2) there might be stuff
in the cache for a syscall to use.

Alpha/Intel in experiments.  One does hardware TLB, one software.

They not only jump to the soft timers after interrupts, but
occasionally put jumps to them within long-running OS code, like TCP.

They do not discuss the impact of soft timers on other programs.  Bad!

Benefits of using the 6k file are that there is no chance of disk I/O
(and it will probably stay in the L2 cache).

Soft Timers: Efficient Microsecond Software Timer Support for Network 
Processing -- Aron -- 1999

Kind of Paper:
--------------
   -- an interesting new idea
   -- possible applications of the new idea
   -- idea evaluation

General Summary:
----------------
This paper presents a novel operating system facility for generating very fine
grain clock interrupts. The authors claim that there is a class of situation in
which timer interrupts with granularity of tens of microseconds can be
extremely useful. The currently available programable hardware timers are not
well suited for the job since the overhead of switching becomes prohibitive at
such granularity. The authors solve the problem by a new mechanism which
involves placing timer checks in already existing kernel entry points such as
syscalls, exception handlers, device interrupt handlers. Since these trigger
states occur randomly, soft timers are probabilistic in nature and it is
possible for a handler to be invoked with some delay. A significant portion of
the paper, however, attempts to examine how long this delay is and how this
depends on the particular system workload. The conclusions are that for the
vast majority of cases 20 microsecond soft timer resolution is available and
the possible delays are accepably small. The ramainder of the paper examines
how soft timers can be employed for efficiently implementing TCP rate-based
clocking and network packet polling.   

Details and Applications:
-------------------------
    -- pending timer expiration checks are place in the TCP/IP processing loop,
    TCP/IP timing loop, the idle loop, syscalls, exception handlers, etc.
    
    -- the maximum delay for a soft timer is bounded because the soft bound
    facility shcedules a periodic hardware timer interrupt that is used for
    dispatching any overdue events.
    
    -- rete-based clocking -- TCP transmission is not governed by the ACKs
    comming back. Packets are sent more or less periodically to achieve a
    target transmission rate.
    
    -- network polling -- packet processing is not driven by an interrupt for
    every packet.Instead, the interfaces are periodically check for new packets.

Comments on Ideas, Methodology, and Performance Analysis:
---------------------------------------------------------
    -- This paper is yet another example how the really good ideas are the ones
    that seem really simple and obvious when one reads about them.
    
    -- the performance section does a good job of illustrating the overhead of
    hardware timers when compared to soft timers. Also, since the paper
    presents a novel probabilistic kernel facility, it is really informative to
    see results which give some insight as to what time granularity can be
    supported with soft timers and how large can the timer delay be depending
    on different workloads.
    
    -- one possible improvement which can lead to a smaller deviation between
    actual and scheduled timer handler activation is calling handlers a bit
    before their scheduled time if the gap is sufficiently small. The
    decision of what is sufficiently small can be based on a running
    average of the intervals between trigger states.
    
    -- Using the networking applications of soft timer for motivating the idea
    is good but the paper devotes too much attention on those applications. In
    my opinion, the sections on rate-based clocking and network polling
    logically belong to a seperate paper.

    -- there seems to be a bit of circularity in the agrument of using soft
    timers for network polling. Table 2, giving the percent distribution of the
    various trigger states, indicates that about 40% percent of all trigger
    states are related to network interrupts. On the oter hand networl polling
    targets the reduction of the number of network related interrupts. Then in
    order to know that polling is feasible on needs to be convinced that soft
    timers retain their granularity if all network related trigger states are
    eliminated.