Re: Variable timer tick rate?

From: Poul-Henning Kamp (phk_at_phk.freebsd.dk)
Date: 10/18/03

  • Next message: David Schultz: "Re: Variable timer tick rate?" 
    To: Nate Lawson <nate@root.org>
Date: Sat, 18 Oct 2003 22:05:40 +0200

    In message <20031018130119.T47207@root.org>, Nate Lawson writes:

    >This is an interesting approach. If there are no upcoming timeouts,
    >decrease the tick rate. Of course, you have to amortize the cost of
    >resetting the timer over the period of no ticks.
    >
    >http://kerneltrap.org/node/view/1006

    Yes, unfortunately we may have a couple of timeout() (ab)users which
    use it to implement "as fast as possible polling" by calling timeout
    with a 1 tick argument, so last I looked (a couple of years ago)
    it fired every tick. 

    -- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: David Schultz: "Re: Variable timer tick rate?"

    Relevant Pages

    • Re: Lahman, how ya doing?
      ... That allowed one to define the scheduling in the way Timer::add_task() was invoked rather than embedding the scheduling rules in the implementation of Timer. ... They should not be concerned with sequencing their activities within the overall solution context. ... More important, given your explanation below, is that ChartRecorder should not know about the rules and policies that determine the correct sequencing in the overall flow of control. ... Just have it enforce the simple rules that multiple events on the same tick are issued in the order that they were defined. ...
      (comp.object)
    • Re: Lahman, how ya doing?
      ... Object* recipient; int event_id; ... Timer ... Not relevant to my simulation, but generalizing to a case where any amount of time can pass between when an event is pushed on to the queue and when it is popped off and processed, it seems you can have two identical events going to the same object. ... given tick. ...
      (comp.object)
    • Re: Lahman, how ya doing?
      ... That allowed one to define the scheduling in the way Timer::add_task() was invoked rather than embedding the scheduling rules in the implementation of Timer. ... In your problem Timer has to churn out events on a schedule that is based on counting time units (clock ticks or simulation ticks). ... Just have it enforce the simple rules that multiple events on the same tick are issued in the order that they were defined. ... By employing true event-based processing you completely separate the concerns of determining when the Beam should do its thing from the concerns of what it needs to do. ...
      (comp.object)
    • Re: Lahman, how ya doing?
      ... >>>so far can be accommodated by the way the events are registered with Timer. ... >>>in the real controller). ... >>>tick is done. ... >>>sequencing of Chart's responsibilities, especially relative to other ...
      (comp.object)
    • Re: Lahman, how ya doing?
      ... >But Timer doesn't know anything about what responses go with those events. ... >that all it needs to know is what the event ID is, how often (the tick ... somewhere in the design one needs to ensure correct sequencing when ... and simply be told to register with timer in the way they see ...
      (comp.object)
    • Quantcast