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, e.g.,

at -f script 23:59

where "script" in invoking the program a number of times.

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. For what it's worth, I'm running Ubuntu 7.10, but I'm pretty sure this unrelated to the distro.

2 is the default nice value of atd. Try 'echo "sleep 2s; nice"|at -q A now; echo "sleep 2s; nice"|at -q Z now;' to see the difference and nice limits of queues.

All the "batch" family of utilities (at, batch, atq, atrm) execute a designated program at a lower priority by design. That has also been traditionally true for anything you execute in background -- it runs at a lower priority.

You can use nice to make things speed up, but that kind of defeats the purpose of running in the middle of the night. The values of "nice" range from -20 to 19 where -20 is go all out and 19 is go whenever nothing else is running (that's why a "nice" value of 2 runs slower -- you use negative values of nice to go faster). As a user, you can't increase the priority to more that "0" (you can specify a negative value to nice but that won't matter); the super user can specify a negative value, however.

The idea of the batch utilities is to run stuff that requires a lot of resources or a long time to complete so other users aren't bothered by them; i.e., it's the way they're supposed to work.

Why you're using a lot of CPU would be something to look into in your program design I would think. Without knowing what the program does and how it does it... well, I dunno.

So, basically, it's working the way is should be and I wouldn't worry about it (or, use cron; as you've noted it'll run faster).

Hope this helps some.

> Why you're using a lot of CPU would be something to look into in
> your program design I would think.
> Without knowing what the program does and how it does it...
> well, I dunno.

Well, it turns out it has nothing to do with the program itself. I took the same program, ran it on my officemate's machine (Ubuntu 9.10), and saw no difference in run time between "no nice" and "nice +4".

My machine must be somehow configured differently, but in what way I don't have a clue.

I've determined that the problm has something to do with how my machined is configured. I'm going to mark this thread as "solved" and post a new thread with a more correct version of the problem I'm having.