Tag Info

Hot answers tagged

21

look at the time man page on your system, some implementations have format options to include I/O, CPU and Memory stats (-f). For instance, GNU time, with -v will show all available info (here on Linux): /usr/bin/time -v ls Command being timed: "ls" User time (seconds): 0.00 System time (seconds): 0.00 Percent of CPU this job got: 0% Elapsed (wall ...


13

There are DST-free timezone definitions provided which just define the GMT-offset, called Etc/GMT±X: $ date Mon Apr 7 11:08:56 CEST 2014 $ TZ=Etc/GMT-1 date Mon Apr 7 10:09:16 GMT-1 2014 $ Just link/copy the one you need to /etc/localtime and you should be fine and DST-free: $ ln -s /usr/share/zoneinfo/Etc/GMT-1 /etc/localtime Edit: For non-integer ...


12

If I understand what you're asking for I this will do. I'm using the commands ls ~ and tee as stand-ins for ./foo and bar, but the general form of what you want is this: $ ( time ./foo ) |& bar NOTE: The output of time is already being attached at the end of any output from ./foo, it's just being done so on STDERR. To redirect it through the pipe you ...


10

By using strace, I saw that the line number=$(expr $number + 1) causes a fork, path search, and exec of expr. (I'm using bash 4.2.45 on Ubuntu). That filesystem, disk, and process overhead led to bash only getting around 28% of the CPU. When I changed that line to use only shell builtin operations ((number = number + 1)) bash used around 98% of the ...


9

.INIT. 16 u That's not fine. You either queried the state to soon, or your ntpd can't connect to those servers at all. When it is synced, it should display IP addresses or host names in the refid column, and values like 2 or 3 in the st column. The output of a working ntpd should look like this: iserv ~ # ntpq -p remote ...


7

No. Process/context switches aren't free. How much other processes running will slow yours down is very system-dependent, but it consists of things like: Every time a processor switches to a different address space (including process), then the MMU cache must be flushed. And probably the processor L1 caches. And maybe the L2 and L3 caches. This will slow ...


5

Correct, usually shell built-ins have help pages instead since their usage isn't usually that involved. If the built-in commands were all that complicated, there would have likely been an effort to simplify shell logic by pushing that functionality into its own executable, at which point it would get a man page. You can get information on time by using ...


5

Assuming it is a shell script, this should work: while [ $(date +%H:%M) != "04:00" ]; do sleep 1; done That's for 24 hour times. If you want this to continue both at 4:00 AM and 4:00 PM, use this instead: while [ $(date +%I:%M) != "04:00" ]; do sleep 1; done


5

Tip for debugging what's going on I would suggest turning on the debug facility of your shell, assuming you're using Bash. $ set -x This output will show you what's happening behind the scenes when you run a command that produces this output. The output That output is from the time /usr/bin/time command being prefixed to every command you run. In order ...


5

Just to illustrate what has been said, with a two threaded processes doing some calculation. /*a.c/* #include <pthread.h> static void * dosomething () { unsigned long a,b=1; for (a=1000000000; a>0; a--) b*=3; return NULL; } main () { pthread_t one, two; pthread_create(&one,NULL, ...


5

time sends its output to stderr instead of stdout by default. You just need to redirect that where you want it. You say "On the other hand, if I wanted to time foo, and redirect the output of time I could write, time (./foo) | bar." but this is actually incorrect. In this case, the output of time would still be displayed on your console, only stdout would ...


5

On OS/X or FreeBSD, it's the -U option. Linux now also stores the birth/creation time on most of its native file systems, but there's no API to retrieve it yet. On ext4 filesystems, you can use debugfs to get it though: $ sudo debugfs /dev/some/fs stat /some/file [...] crtime: 0x53208d7a:9045625c -- Wed Mar 12 16:38:18 2014 [...] (where /some/file is the ...


5

No, you should not be prompted for a password again. The script will be running as root due to the gksudo. In my experience, sudo never asks for password if you are already root (although I couldn't find this explicitly documented).


5

The usual solution to this problem is to put your time command in a group: $ { time wc test >wc.out; } 2>time.out


4

Ironically, time might have answer for you but this should be not shell-built-in time but standalone one: $ /usr/bin/time -v uname Linux Command being timed: "uname" User time (seconds): 0.00 System time (seconds): 0.00 Percent of CPU this job got: 2% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.12 ...


4

time is a reserved word in zsh. It is only recognized at the beginning of a command. It's a reserved word, and not a builtin, because when you write time foo | bar, it is the compound command foo | bar that is timed and not just foo. Where time isn't recognized as a reserved word, it's interpreted as the name of an external command. Your system, for ...


4

On most systems, you can use the ulimit command when you start the program to limit the amount of CPU time it can use. Under the hood, this calls setrlimit with the argument RLIMIT_CPU. After the program has used that much time, the program is killed. (ulimit -t 3600; myprogram) You can refine further by setting a soft limit after which the program ...


4

Call time myprogram. This reports wall clock time, user time and system time. User time is the time spent by the process in computations. If the program is multithreaded and the machine has multiple processors, the time spent on all processors is summed (so for a sufficiently parallel program, the user time can be more than the wall clock time). The system ...


4

On Linux, the info is available in fields 14 to 17 of /proc/$pid/stat (see proc(5) for details): Fields are: 14: user time (in number of clock ticks) 15: sys time 16: user time of waited for children 17: sys time of waited for children (all the threads of a given process have the same values there) They are not directly reported by ps. ps reports 14 + ...


4

You can run a command (including a shell and all of its children) with an arbitrary faster clock frequency by using the warp command from the ast-open package. It uses LD_PRELOAD, so won't work with setuid or setgid or (now relatively rare) statically-linked programs. From the warp man page: warp [ options ] date [ command [ arg ... ] ] warp ...


3

I tried the following in my .bashrc: echo -ne "$PS1" while IFS= read -er line;do eval "time $line" echo -ne "$PS1" done This roughly does what you want with several caveats: Your prompt is practically ruined (the shell usually interprets sequences like \W and so on in your prompt before echoing it). You lose command line editing capabilities ...


3

Since $GPSDATE is being reported as Sun Aug 8 06:08:11 PKT 2010 the date -s command is doing exactly what you are telling it to do. Why is it reporting a wrong year (or nothing at all)? I have no idea. Since you are already using ntpd why are you not content to let NTP do its thing? Is this an "I'd like gpsdate to work because it is there" issue? The ...


3

BASH isn't that bad for this problem. You just need to use the very powerful, but underused date command. for i in {1..10}; do hrmin=$(date -u -d@$(($i * 10 * 60)) +"%H:%M") outfile=${hrmin/:/-}.mp4 ffmpeg -i video.mp4 -ss ${hrmin}:00 -t 00:10:00 -c copy ${outfile} done date Command Explained date with a -d flags allows you to set which date you ...


3

What you're looking for is ntpd with the --panicgate option. The panicgate option allows the first adjustment after ntpd starts to be any size. This is exactly for the use case you described where a machine comes up and it's clock is wildly inaccurate. When ntpd starts with this option enabled, it can take a moment for it find a server and establish ...


3

From usr/share/doc/at/timespec, it doesn't look like it. But you can always use date to convert your timestamp, eg: at "$(date --date=@1393419435 +'%D %T')" date takes a timestamp in seconds, so don't forget to trim fractions of seconds if needed.


3

Printing to a console (especially a remote console) is a fairly expensive operation if done in a tight loop that's executed frequently. Most Ruby I/O is blocking, so it will drastically slow down the execution of the program. You should get a much more reasonable result if you send the output to a file (or /dev/null, if you don't care about it) instead: ...


3

It's because you're echoing all the numbers out to the screen via the puts. These then have to be sent over the SSH connection which extends the amount of time the scripts takes to run. The output is also buffered locally but the effects aren't as noticeable. You can confirm this by dumping all the output to a file instead. Examples local on laptop to ...


3

The command strace can be useful, you can limit the trace to only count -c or a subset of system calls, -e trace=set Trace only the specified set of system calls. The -c option is useful for determining which system calls might be useful to trace. For example, trace=open,close,read,write means to only trace those four ...


3

If you can get the pid, which shouldn't be hard with either ps, /proc/self or $! depending on whether or not you background it you can find this in: /proc/$pid/stat: utime %lu (14) Amount of time that this process has been scheduled in user mode, measured in clock ticks (divide by ...



Only top voted, non community-wiki answers of a minimum length are eligible