Re: TSC instead of ACPI: powerd doesn't work anymore (to be expected?)

From: Poul-Henning Kamp (phk_at_phk.freebsd.dk)
Date: 10/31/05

  • Next message: Maxim Konovalov: "Re: kern/67919: Why nobody take serious to fix this bug?" 
    To: Robert Watson <rwatson@FreeBSD.org>
Date: Mon, 31 Oct 2005 12:03:48 +0100

    In message <20051031102424.V11619@fledge.watson.org>, Robert Watson writes:

    >- Modify time(3) so that it relies on a timer-driven clock, since it needs
    > to provide only one second granularity. Applications using second
    > granularity are probably not all that concerned with high resolution
    > timing.

    Provided we are ok with clock_gettime(CLOCK_REALTIME) and time(3) not
    agreeing at all times, then I have no objections to this one.

    >- Leave clock_gettime(2) as-is, since applications making use of this
    > clock are likely looking for high resolution.

    Here we have to be more specific, we could add more CLOCK_FOO values
    without affecting the existing.

    CLOCK_REALTIME and CLOCK_MONOTONIC should return precise results IMO.

    >- I'm not sure what to do about gettimeofday(). My leaning is to look at
    > lowering the quality to improve performance.

    An entirely different take on this is to make it a per-process
    (per-thread ?) option if timestamps are precise or not.

    We'd just need to give the processes a bit to flip to state their
    preference.

    This makes for far smaller patches to applications than anything
    which adds new timescales or functions.

    >- Add an interface for extracting high resolution time data, such as the
    > Solaris interface, and start migrating applications that care to that
    > interface.

    No opinion yet, I havn't studied the solaris interface.

    >- Further investigate the TSC issue. For example, allowing multiple
    > time counters to be used depending on the API. Right now, all APIs
    > source from the same timecounter, but you could imagine gettimeofday()
    > using the TSC (with synchronization added?), and having clock_gettime()
    > continue to use the higher quality source. I think this is the thrust
    > of the Solaris approach -- allow direct access to timecounters of
    > varying quality.

    Ok, let me get one thing very clear: As long as we are talking
    timestamps out of the timecounter code, there is by design and
    definition only one piece of hardware that controls. To change
    that would require somebody to dump a couple of months into the
    code.

    If we are talking timestamps in the sense of calling rdtsc(), then
    it is an entirely different matter.

    >- Investigate the quality offered by various other systems. One of the
    > claims made is that we offer better time keeping than Linux systems,

    It's more that we default to known safe configs where Linux takes a
    more "it worked for me" attitude to their hardware selection.

    If somebody with access to the necessary docs (ie: Intel + AMD NDAs)
    writes a piece of code that can tell us if using the TSC is safe,
    then we can also use the TSC in those cases.

    But lacking that function, enabling the TSC by default when so many
    machines has trouble with it would be counter to our normal attitude
    to system stability.

    > If all systems offer low quality time
    > sources for the POSIX APIs, then applications will be written to that
    > assumption, meaning that offering high quality time there doesn't
    > necessarily help them (does this follow?).

    Just because Linux doesn't see major problems in timekeeping doesn't
    really guarantee that their timekeeping isn't causing major problems.

    Problems originating in timekeeping tend to be classified as
    heisenbugs because they are hard to reproduce.

    As recently as a couple of weeks ago, I saw how a commercial UNIX
    make a dent in a project plan because the kernel jumped a few
    milliseconds when a lot of text scrolled by in an Xterm. You get
    to guess how many weird theories they had tried out before I nailed
    that diagnosis.

    Another thing to remember is that the TSC and ACPI hardware is not
    the only thing we have to deal with: Any solution we implement
    needs to also work on other architectures, including i486 with only
    i8254 timecounters etc.

    And finally, WinTel know that the ACPI timer sucks, thats why more
    recent hardware has HPET timers, I'm working on support for that. 

    -- 
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Maxim Konovalov: "Re: kern/67919: Why nobody take serious to fix this bug?"

    Relevant Pages

    • Re: got very slow
      ... - Uninstalled unknown/unneeded applications in Add/Remove Programs? ... What hardware do you have? ... What to Know Before You Download and Install Windows XP Service Pack 2 ... You also have hardware on your machine that requires drivers to interface ...
      (microsoft.public.windowsxp.general)
    • Re: OT (Maybe): ERPs
      ... >what hardware, O/S, etc, we run all Intel based systems. ... Boxed off-the-shelf applications, games, ... "TPC benchmarks also differ from other benchmarks in that TPC ... The most frequent transaction consists of entering a new order which, ...
      (comp.lang.cobol)
    • Re: OT: Re: Jobst Brandt vs. Tire Glue
      ... The winning combination was generic hardware and bundled software. ... in the sense that they are server apps that don't have to deal with a plethora of peripherals and are singular applications that don't have to integrate with a lot of others. ... Who would put up somebody with a stutter as a presenter? ...
      (rec.bicycles.tech)
    • Re: Announce: Impulse C-to-RTL Version 2 now available
      ... is a useful replacement for VHDL and/or Verilog programming. ... There is also little benefit in doing "baby applications" ... hardware equivalents or pre-optimized library blocks ... HDL programming. ...
      (comp.arch.fpga)
    • Re: Limitations of VMs?
      ... Would anyone with direct experience of working with VMs like to comment on this review and/or on the limitations of other VM products? ... Memory or data Intensive applications and/or critical applications can have their own OS dedicated to that one application. ... No other applications outside applications that would normally running on a single instance server. ... Consolidation of Hardware: Instead of 5 servers, each with an OS, you can choose to buy one redundant server with multiple CPUs and lots of RAM and create VMs based upon need on that one box. ...
      (borland.public.delphi.non-technical)