Find the answer to your Linux question:
Results 1 to 4 of 4
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    [SOLVED] why does 'nice' slow down execution when there is no load?

    I used "at" to schedule some (single threaded) timing runs (using /usr/bin/time) of a computationally intensive, I/O unintensive (as in just 2-3 pages of text output) program I'm working on last night. (OS is Ubuntu 7.10) The output this morning showed that each run of the program had taken ~2-3x as long to run as normal, i.e., the reported user time is 2-3x as large as when I run interactively. I just looked at a small subset of the test, and, yep, the program does run more slowly under at. Just checked using "crontab" to do the same thing and did not see any slowdown from running interactively. The only hint I saw is that with "at" the program is niced to 2 while with crontab the program runs at a nice of 0. Sure enough, when I run interactively with a nice value of 2 I see the same slow down -- which puzzles me because while running with a nice of 2, top reports that I am getting 100% of a CPU. BTW, the runs are long enough to be significant -- ~105 seconds of CPU time, ~300 sec under "at". So my 2 questions are: 1) how can I tell "at" not to nice my job? 2) why would running with a nice of 2 when there's no load on the machine slow my job down so? Any thoughts would be appreciated.

  2. #2
    Not hip with what you are trying to do. So just throwing this out there.

    Ubuntu Manpage: nice - change process priority

    [ubuntu] "Nice" - Ubuntu Forums

    Using "at" command - Ubuntu Forums

    [all variants] Problems with the "at" command. - Ubuntu Forums

    You will need to go through next comment to read replies on next link

    You can also in terminal check
    man at
    for more details

    I am just a home using Linux biker. So that is the best I can do for you.

    Happy Trails, Rok
    I refuse to let fear and fear of others rule my life. It puts my humanity at risk.
    Accepting Death is the only way to stay alive.

  3. #3

    "nice" slowness is somehow related to my system configuration

    I've determined that this problem has something to do with how my system is configured. Here's my current take on it:

    I've just noticed that "nicing" long running computationally intensive, I/O unintensive, single-threaded executables on my system increases the CPU run time of those executables (as reported by /usr/bin/time as well as by wall clock) by a factor of 2-3 even in the absence of any load, i.e., "top" tells me that my program is getting 100% of a CPU. For example:

    %coot 248: /usr/bin/time -p ./a.out > out
    real 97.47
    user 85.64
    sys 0.94
    %coot 249: nice +4 /usr/bin/time -p ./a.out > out
    real 248.31
    user 231.94
    sys 1.68
    %coot 250:

    My system is running Ubuntu 7.10. If I run the same executable on two other machines I have access to -- one running Fedora 5 and the other Ubuntu 9.10 -- I don't see any discrepancy between the runtimes using nice and not using nice.

    This behavior is executable independent, compiler dependent, and language dependent -- I'm seeing it across the board. I'm assuming I've somehow configured my system to behave this way, but I have no idea what I may have done. Also, this was the first time I'd ever done timing runs with "nice" (actually, "at"), so I'm not sure how long my system's been configured (if configured is the right word) this way.

    Any suggestions?

  4. $spacer_open
  5. #4
    The solution via another forum was

    sudo /etc/init.d/powernowd stop

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts