Hot answers tagged

21

You could use rsync (over ssh), which uses a single connection to transfer all the source files. rsync -avP cap_* user@host:dir If you don't have rsync (and why not!?) you can use tar with ssh like this, which avoids creating a temporary file: tar czf - cap_* | ssh user@host tar xvzfC - dir The rsync is to be preferred, all other things being equal, ...


12

It's the negotiation of the transfer that takes time. In general, operations on n files of b bytes each takes much, much longer than a single operation on a single file of n * b bytes. This is also true e.g. for disk I/O. If you look carefully you'll see that the transfer rate in this case is size_of_the_file/secs. To transfer files more efficiently, ...


9

date +%s%N will give the nano seconds since epoch To get the micro seconds just do an eval expr `date +%s%N` / 1000


8

There's no much point asking for this kind of precision in a shell script, given that running any command (even the date command) will take at least a few hundreds of those microseconds. In particular, you can't really use the date command to time the execution of a command with this kind of precision. For that, best would be to use the time command or ...


7

if the user is allowed to use at command, this is the perfect use for that: $ at 08:00 022116 at> myscript.sh at> <----------- ctrl-d here job 9 at 2016-02-21 08:00 if you get a message like "user blah is not able to run at", ask the syadmin to add this user to at.allow file or remove from at.deny file, depending on how it is used in your ...


6

The accounting utilities (e.g. GNU's implementation) track user activity and provide a number of tools to report on it; for example, lastcomm will list the last commands executed, and sa (run as root) will provide an activity summary. To show the amount of time a given process ran, do something like sudo sa | grep chromium This will output a number ...


6

@wurtel's comment is probably correct: there's a lot of overhead establishing each connection. If you can fix that you'll get faster transfers (and if you can't, just use @roaima's rsync workaround). I did an experiment transferring similar-sized files (head -c 417K /dev/urandom > foo.1 and made some copies of that file) to a host that takes a while to ...


6

You could use bc and printf: printf "%0.f" "$(bc <<<"$(date +"%s.%N")*1000")" This gives the number of miliseconds since january 1970. I didn't use the scale=n option of bc on purpose, because that would not round the value, instead it cuts the rest away (I know, it's pedantic). bc reads from file or from the standard input. <<< is a ...


6

The socket idea is the old venerable time protocol documented in RFC 868. The utility that synchronizes system time based on that protocol is called rdate. You're better off using NTP because NTP will track how the clocks of the two systems naturally drift apart over time and correct for it. The time protocol should be reserved for situations where NTP is ...


5

The structure of a pipeline doesn't allow time in the middle, only at the start of the pipeline. Also, time is a "shell keyword", as shown by type time. But nothing forbids the use of compound commands (and time each): time comm1 | ( time comm2 ) So, you could workaround using a sub-shell, like this: echo "12" | ( time python3 -c "a=input("");print(a)" ...


5

For -daystart the manual says: -- Option: -daystart Measure times from the beginning of today rather than from 24 hours ago. So, to list the regular files in your home directory that were modified yesterday, do find ~/ -daystart -type f -mtime 1 The '-daystart' option is unlike most other options in that it has an effect on ...


4

Using last you can find this information. The following may be useful: last <username> | less It will return something like this: benlavery@Talantinc:bin $>last benlavery | less benlavery ttys005 Mon Aug 31 09:58 still logged in benlavery ttys005 fe80::105e:6b27:29ff:d967%en0 Mon Aug 31 09:14 - 09:36 (00:22) benlavery ...


4

As you said date +%s returns the number of seconds since the epoch. So, date +%s%N returns the seconds and the current nanoseconds. Dividing date +%s%N the value by 1000 will give in microseconds.i.e echo $(($(date +%s%N)/1000))


4

With GNU date: d=1456478048306 s=${d%???} ms=${d#"$s"} date -d "@$s" +"%F %T.$ms %z" # or: date -d "$s.$ms" '+%F %T.%3N %z' With BSD date: date -r "$s" +"%F %T.$ms %z" With GNU awk and recent versions of mawk (since 1.3.4 20121129): echo 1456478048306 | awk '{ print strftime("%F %T." substr($0,length-2) " %z", substr($0, 1, length-3))}' For ...


3

I'm going to assume you're on CentOS 7+ or Ubuntu 15.04+ which both come with systemd. Systemd has some great tools for figuring out how long your system took to boot along with some visualizations to see why. For the most basic output just run systemd-analyze and you'll get a nice summary like so Startup finished in 853ms (kernel) + 3min 50.610s (initrd) ...


3

You need to execute 'time' command. Here is an example of how much time it takes to execute 'updatedb' command root ~ $ time updatedb real 0m0.047s user 0m0.015s sys 0m0.029s root ~ $


3

There is two types of time commands. One is shell built-in, belongs to bash. That's the one you see in your first example. Second one , is /usr/bin/time, that's the second one you saw. As for why it's different output, it's because you cannot pipe output to shell builtins. More on that here


3

When the network is configured via DHCP as it is here, that can set the timezone. See serverfault.com/questions/333348/ DHCP can also set the ntp server but you say that ntpd is not running so that wouldn't matter here. But as the solution indicates, ntpdate can also be run. So expanding upon my initial comment, you should make sure ntpdate is not around ...


3

The unix system is designed to run on UTC, timezones are a convenience for us mere humans who prefer to see a local time. Two users working on the one system, could sit in different timezones and therefore have different timezones set in their environment. It appears that you want to force the system to run in your timezone, but you also say that you want ...


2

NTP does have the ability to run without a drift file, so if one is not specified, I believe you would be running without it. from: http://doc.ntp.org/4.1.0/ntpd.htm The ntpd behavior at startup depends on whether the frequency file, usually ntp.drift, exists. This file contains the latest estimate of clock frequency error. When the ntpd is started ...


2

Browsing the busybox ntp sources seems to indicate that no driftfile is used, and the only options read from the conf file are the server lines.


2

next0900=$([ $(date +%H) -lt 9 ] && date -d "09:00" || date -d "tomorrow 09:00") If the current hour is less than 9, then give me "9:00" otherwise give me "tomorrow 9:00"


2

You nearly had it right, just a couple of back ticks too many $ d=$(($(date +%s%N)/1000000)) $ echo $d 1445422618527 $ d=$(date +%s%N) $ echo $d $(( d / 10 )) $(( d / 1000000 )) 1445422673712321597 144542267371232159 1445422673712


2

Sample to try timerscript.sh: #!/bin/bash #timing in minutes with %m start=`date +%m` echo 'Start:' $start #do something e.g. wait for 1.30 minutes sleep 90 `end=`date +%m` echo 'End: '$end echo 'runtime: '$runtime


2

Note: Although NTP had this idea of a nanokernel which could be used to patch OS's that don't use NTP, in Linux in particular is not in this case. The NTP code is in the kernel itself as you allude to in question 1. 0: How does this Nanokernel manage to deliver an accuracy less than the system clock tick (such as ns accuracy)? Accuracy greater than ...


2

If you have configured all of the Raspberry Pis to a local NTP Server, i.e. you've set up an NTP Server on your LAN, then their synchronization should be adequate for your video frame timestamping task. Both Bash and Python need to make a system function call to retrieve the system time. There's no advantage in using Bash to make that call. Both Python ...


2

There's no standard definition for “fully start”. If you come up with a definition, there may or may not be a way to detect it. If your definition of “fully start” is “wait until the application becomes idle, waiting for user input”, then you can trace its system calls and look how long it takes to start reading user input. strace -o myapp.strace -tt myapp ...


2

ntpdate is giving you the "socket in use" error because you have a NTP daemon running. This is good. Now, the problem with VMs is that they tend to have a huge time offset (because of being frozen and restarted), and by default NTP panics and exit when the clock skew is too big. Add the following lines to /etc/ntp.conf: tinker panic 0 server ...


2

Mac OS X doesn't ship with the GNU stack. You have "BSD Time" time.c,v 1.9. You can verify this by typing: strings /usr/bin/time | grep c,v BSD time doesn't support --verbose, but it does support /usr/bin/time -lp: $ /usr/bin/time -lp echo hi hi real 0.02 user 0.00 sys 0.00 700416 maximum resident set size 0 ...


2

The answer is: You can not! Linux is no real time system. The idea of UNIX and therefore Linux, too, is to provide minimum answer times, while the system is shared between multiple users and system processes. Depending on when you start the command, you might have to wait for a important system process to give you your share of processor time. Further the ...



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