シェルスクリプトで使用する必要があるため、sleep端末で試してみましたが、遅延が発生して一貫性がなく、非常に不正確でした。たとえば、sleep 320秒に近い遅延が発生します。これらの遅延は、同じ時間が指定されると変動する可能性があります。一般に、ラテンシーは、値が増加するほど指数関数的に増加するようです。
UbuntuとDebian VMで試しましたが、結果は同じではありませんでした。 VMコンポーネントが私の役割を果たしているとは思いません（timeout 10Windows VMで実行してもかまいません）。
各コマンドのタイミングに合わせて、システムクロックは正しく実行されていると思いますが、そうではありません。以下の例をご覧ください。
括弧内の時間は実際の経過時間（近似値）です。
$ time sleep 1 (7 secs)
real 0m1.040s
user 0m0.003s
sys 0m0.016s
$ time sleep 1 (5 secs)
real 0m1.028s
user 0m0.009s
sys 0m0.013s
$ time sleep 1 (5 secs)
real 0m1.027s
user 0m0.013s
sys 0m0.007s
$ time sleep 1 (5 secs)
real 0m1.029s
user 0m0.007s
sys 0m0.016s
$ time sleep 3 (17 secs)
real 0m3.036s
user 0m0.000s
sys 0m0.021s
$ time sleep 5 (29.5 secs)
real 0m5.026s
user 0m0.007s
sys 0m0.013s
デフォルトは明らかに秒単位ですが、s時間を追加しても違いはありません。
ディスクやCPUを消費できる他の何もホストで実行されていません。
VMを再起動すると、最初の数回の試みは改善されるように見えますが、それ以降は精度が悪化します。
何が問題なのか知っていますか？
編集する:
ランニング
declare -p PS1リターンdeclare -- PS1="\${debian_chroot:+(\$debian_chroot)}\\u@\\h:\\w\\\$ "ランニング
command -V sleepリターンsleep is hashed (/usr/bin/sleep)ランニング
declare -p PATHリターンdeclare -x PATH="/home/debwp/mycmds:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"Paul_Pedantによる投稿の結果：
~$ date '+%T.%N'; time sleep 5; date '+%T.%N' 22:47:49.679497552 ^[[A ^[[A ^[[A ^[[A real 0m5.033s user 0m0.005s sys 0m0.014s 22:47:54.788302324 ~$ date '+%T.%N'; time sleep 5; date '+%T.%N' 22:47:54.830674809 real 0m5.043s user 0m0.008s sys 0m0.012s 22:47:59.934542825 ~$ date '+%T.%N'; time sleep 5; date '+%T.%N' 22:47:59.994006022 real 0m5.057s user 0m0.004s sys 0m0.018s 22:48:05.159303996 ~$ date '+%T.%N'; time sleep 5; date '+%T.%N' 22:48:05.241043114 real 0m5.099s user 0m0.004s sys 0m0.021s 22:48:10.383158635 ~$ date '+%T.%N'; time sleep 5; date '+%T.%N' 22:48:10.435520982 real 0m5.028s user 0m0.004s sys 0m0.012s 22:48:15.497877219 ~$date毎秒 1 回端末に入力すると、次のような結果が得られます。$ date Mon 31 Aug 20:42:25 CEST 2020 $ date Mon 31 Aug 20:42:25 CEST 2020 $ date Mon 31 Aug 20:42:25 CEST 2020 $ date Mon 31 Aug 20:42:26 CEST 2020
ベストアンサー1
この動作は間違いなくハイパーバイザーに関連しています。
time(7)説明する：
リアルタイムは、過去の標準点（以下の起源とカレンダー時間の説明を参照）、またはプロセス寿命の特定の点（開始など）（経過時間）など、いくつかの固定点で測定された時間として定義されます。 ）。
プロセス時間は、プロセスが使用するCPU時間の量として定義されます。時には、ユーザーコンポーネントとシステムコンポーネントに分けられます。ユーザーCPU時間は、ユーザーモードでコードを実行するのに費やされた時間です。システムCPU時間は、プロセスに代わってシステムモードでカーネルを実行するのにかかる時間です（たとえば、システムコールの実行）。 time(1) コマンドを使用すると、プログラムの実行中に消費された CPU 時間を確認できます。
これに基づいて、次のような結論を下すことができます。
$ time sleep 1
real 0m1.002s
user 0m0.002s
sys 0m0.000s
realリアルタイムとは、プロセスに費やされた実際の時間を意味します（壁時計時間とも呼ばれます）。 userは、ユーザーモードでコードを実行するのに費やされたCPU時間（CPUサイクル*頻度）、はカーネルsysプロセスの代わりにシステムモードで実行するのに費やされたCPU時間（CPUサイクル*頻度）です。
問題を説明してください。
なぜ報告時間がないのですか
real？time(1)私の時計に合うでしょうか？
ベアメタルでオペレーティングシステムを実行する場合、通常、バッテリ駆動の水晶発振器は一定の周波数で動作します。このハードウェア時計は、エポックの後の時間を追跡します。ドリフトを修正するために1秒あたりの振動数を調整できます（参照：hwclock(8)）。
time(7)また、次のように言いました。
タイムアウトを設定し（例：select（2）、sigtimedwait（2））、CPU時間を測定する（例：getrusage（2））、さまざまなシステムコールの精度はソフトウェアクロックの解像度によって制限されます。カーネルで、 jiffy 測定時間で測定されます。 jiffy のサイズはカーネル定数 HZ の値によって決まります。
ハードウェアクロックはシステムクロックを初期化するために使用されます（それ以外の場合は起動後の時間のみがわかります）。あなたのハイパーバイザー（virtualbox）がhwclockを使って時間を初期化しているようです。その後、ソフトウェア時計が代わりになります。
rtc(4)説明する：
[ハードウェアクロック]カーネルによって維持され、gettimeofday（2）とtime（2）を実装し、ファイルにタイムスタンプを設定するために使用されるソフトウェアクロックであるシステムクロックと混同しないでください。
ここで学んだことはtime(2)（これはユーティリティによって使用されるライブラリ呼び出しです）。time(1)）実際には、ハードウェア時計ではなくシステム時計から情報を取得します。
ソフトウェアクロックはカーネルによって保持され、時間を測定しますjiffies。カーネル定数によって決定される時間単位です。私が理解しているように、特定のCPUサイクルの数がジップを追加します。そのため、OSではCPUが2.0GHzで実行されていると思いますが、CPUが実際に1.0GHzで実行されている場合、壁時計と比較するとジッピーは実際に予想される1msではなく2msかかります。
物理ハードウェアで実行するときは、実行速度をCPUに指示し（電力節約のために速度を下げ、パフォーマンスのために速度を上げます）、物理ハードウェアがこの時点に達したため、ハードウェアが約束したとおりに実行すると仮定します。秘訣は、「ハードウェア」が仮想の場合、ハイパーバイザーが物理法則ではなく仮想CPUを制御する方法を決定するということです。
ユーザースペース（仮想マシンなど）で実行されるハイパーバイザーは、ホストカーネルの助けを借りて必要なサイクルを提供します。ホストシステムが1000台の仮想マシンを実行している場合、各ゲストVMは予想されるCPUサイクルの一部のみを取得するため、推測されたシステムクロックがより遅い速度で増加すると想像できます。ハイパーバイザーが必要なすべてのリソースを入手しても、適切であると判断されたようにリソースを制限することを選択できます。これにより、ゲストオペレーティングシステムが理由を理解していない限り、予想よりも遅くなる可能性があります。