date +%s%N
vai dar os nano segundos desde a época Para obter os micro segundos basta fazer um eval
expr 'date +%s%N' / 1000
Eu quero saber a hora atual do sistema com resolução de microssegundos.
date +%s retorna o tempo em segundos desde a época (1-1-1970). Como posso obter tempo em resolução de microssegundos? Quanto atraso está em consultar esse valor? Por atraso, quero dizer, suponha que no momento t s eu consulta e me dá valor t + t' o que é t' ?
Meu caso de uso: estou gravando vídeos usando vários Raspberry Pis simulatenously. Agora quero registrar o tempo de cada quadro de vídeos para que eu possa alinhá-los. Atualmente para timestamp está usando o tempo de boot (tempo desde a inicialização). O tempo de inicialização é preciso, mas é diferente para cada Raspberry Pi. Eu configurei todos os Pi's para um servidor NTP, assim todos têm a mesma hora do sistema. Então, basicamente, eu quero que o timestamp da hora do sistema não seja o Boot Time. Como posso fazer isso?
date +%s%N
vai dar os nano segundos desde a época Para obter os micro segundos basta fazer um eval
expr 'date +%s%N' / 1000
Não há muito sentido em pedir esse tipo de precisão em um script shell, já que executar qualquer comando (mesmo o comando date ) levará pelo menos algumas centenas desses microssegundos.
Em particular, você não pode realmente usar o comando date para cronometrar a execução de um comando com esse tipo de precisão.
Para isso, o melhor seria usar o comando time ou palavra-chave.
Algumas implementações permitem alterar o formato para fornecer o tempo decorrido apenas com precisão de subsegundos.
$ bash -c 'TIMEFORMAT=%3R; time date +%s'
1432210052
0.001
$ ksh -c 'TIMEFORMAT=%3R; time date +%s'
1432210094
0.001
$ zsh -c 'TIMEFMT=%*E; time date +%s'
1432210123
0.001
Várias shells têm várias formas embutidas (portanto com atraso mínimo) para você ganhar tempo:
ksh93 e zsh têm uma variável $SECONDS que lhe dará precisão de subsegundo se você alterar seu tipo para float :
$ zsh -c 'typeset -F SECONDS=0; date; echo "$SECONDS"'
Thu 21 May 13:09:37 BST 2015
0.0012110000
$ ksh -c 'typeset -F SECONDS=0; date; echo "$SECONDS"'
Thu 21 May 13:09:42 BST 2015
0.0010249615
zsh tem uma variável $EPOCHREALTIME especial (disponível no módulo zsh/datetime ):
$ zsh -c 'zmodload zsh/datetime; echo $EPOCHREALTIME; date; echo $EPOCHREALTIME'
1432210318.7319943905
Thu 21 May 13:11:58 BST 2015
1432210318.7333047390
ksh93 e versões mais recentes de bash suportam o formato %(format)T no seu printf incorporado, no entanto bash não suporta %N (mesmo que seja uma extensão GNU) e discordam como expressar agora .
$ ksh -c 'printf "%(%s.%N)T\n" now;printf "%(%s.%N)T\n" now'
1432210726.203840000
1432210726.204068000
(como você pode ver, 228 desses microssegundos ainda se passaram entre as duas invocações daquele comando interno).
Como você disse, date +%s retorna o número de segundos desde a época.
Então,
date +%s%N retorna os segundos e os nanossegundos atuais.
Dividindo date +%s%N o valor por 1000 resultará em microssegundos.i.e
echo $(($(date +%s%N)/1000))
Se você configurou todos os Raspberry Pis para um servidor NTP local , ou seja, configurou um servidor NTP em sua LAN, a sincronização deles deve ser adequada para a tarefa de registro de data e hora do quadro de vídeo .
Tanto o Bash quanto o Python precisam fazer uma chamada de função do sistema para recuperar a hora do sistema. Não há vantagem em usar o Bash para fazer essa ligação. Ambos Python & Bash script são linguagens interpretadas e as sobrecargas de tempo envolvidas na execução de scripts geralmente serão maiores do que com uma linguagem compilada, OTOH, scripts Python são compilados para bytecode Python antes da execução, o que geralmente os torna mais eficientes do que scripts Bash, que não possuem qualquer forma de compilação. E nesse caso específico de registro de data e hora do quadro de vídeo, um script escrito em Python é muito mais preciso do que um escrito em Bash.
No entanto, ao fazer coisas assim em um sistema operacional multitarefa, você terá vários atrasos imprevisíveis devido ao fato de que sua CPU está alternando entre executar seu trabalho e lidar com várias outras tarefas. Portanto, faça o melhor para minimizar essas outras tarefas e execute o script de registro de data e hora em alta prioridade para reduzir o impacto dessas outras tarefas. Observe que fazer uma chamada do sistema para obter o tempo enquanto o kernel está no meio da leitura ou gravação no HD provavelmente não é uma boa ideia. :)
Se você estiver fazendo o seu material de timestamp em um loop apertado, poderá rastrear a diferença de tempo entre cada timestamp. E se essa diferença ficar muito alta ou variar muito, seu script pode decidir que os timestamps atuais podem ser inadequados. OTOH, supondo que sua taxa de quadros seja de 50 quadros / segundo, ou seja, 20 milissegundos / quadro, então a precisão em milissegundos provavelmente é mais que suficiente para essa tarefa.
FWIW, aqui está um pouco do Python rodando na minha máquina de 2GHz com prioridade normal com uma carga de tarefas típica (incluindo baixar e tocar música com o VLC).
>>> from time import time as tf
>>> t=[tf()for _ in range(9)];['%0.3f'%(1E6*(u-v))for u,v in zip(t[1:],t)]
['2.146', '0.954', '1.907', '1.192', '1.907', '1.907', '1.192', '0.954']
Como você pode ver, a variação no nível de microssegundo não é tão ruim.
Você não precisa de resolução de microssegundos, milissegundos serão suficientes para cerca de 20 a 60 quadros por segundo.
Se você conseguir a hora do sistema para todos os Pis de um servidor NTP uma vez, eles serão desalinhados depois de algum tempo novamente, porque cada relógio interno pode ter um erro individual de cerca de 100 ppm (parte por milhão). Depois de 200 segundos, você pode ter uma diferença de até 20 ms.
Eu duvido que todos os Pis estejam alinhados com a precisão de sub-milissegundos logo depois que eles tiverem o tempo do servidor NTP.
É claro que a taxa de quadros de cada Pi terá um erro individual de cerca de 100 ppm também.
Eu pensaria em uma fonte de clock central para todos os Pis.
Boa sorte, você precisará disso.
Tags time clock ntp timestamps