問題タブ [time-precision]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
java - 非常に正確な繰り返し/継続的なコード実行
私の会社では、UDP を介して、私たちの管理下にないリモート システムにデータを送信する必要があるプログラムがあります。
データは7981859ns (=7.98 ミリ秒) +/- 0.001ms ごとに送信する必要があります。
悲しいことに、データを送信するのが遅すぎると、そのリモート システムの古いバージョンが機能しなくなります。また、送信が速すぎたり早すぎたりすると、データが不足します (リアルタイム データ生成)。
現時点では、UDP パケットを次の方法で送信しています。
ログを追加すると、データが 6 ミリ秒から 11 ミリ秒の間に送信されていることがわかります。これは、私たちにとっては大きすぎる範囲です。
これを最適化する方法を考えました。
最後の送信のナノタイムスタンプで変数を設定することは可能でしょうか (どのようにそれを取得しますか?私は知っています。System.currentTimeMillis())
ループを少し速く実行し (または単にループでwhile(true)
)、「currentNanoTime - lastNanoTime > 7981859」まで待ちます)。send(..)
?を実行する前に
私の問題は、ナノ秒、ミリ秒だけ待つ方法が見つからなかったことです。
c# - C# および SQL Server での DateTimeOffset 解決
ドキュメントには、.NET サーバーと SQL サーバーの両方で解像度が 100ns であると記載されています。
DateTimeOffset 値の時間コンポーネントは、ティックと呼ばれる 100 ナノ秒単位で測定されます- C# 精度 - 100 ナノ秒- SQL Server
ただし、SQL は最後の桁を削除するようです (たとえば、2013-08-15 09:19:07.2459675 -04:00 を保存しようとすると、SQL は 2013-08-15 09:19:07.2459670 -04:00 を保存します - 注意)下一桁が変わります。)
これは同じマシンで発生するため、ハードウェアに依存しません。
実際にこの解決策が必要というわけではありませんが、日付の比較が難しくなります..そして私はただ興味があります.
linux - PostgreSQL: CURRENT_TIMESTAMP と CLOCK_TIMESTAMP 解決策: Windows vs. Linux?
ですから、PostgreSQL のタイミング関数には興味深い問題があります。
これが状況です。開発中のアプリケーションを格納する本番前のサーバー (Linux) があります。また、サーバーでさらに重要な作業が行われている場合に備えて、その DB (Windows) のローカル コピーに対して作業を行います。最近、ローカル DB コピーのログ テーブルで主キー違反が発生するという問題に遭遇しました。CLOCK_TIMESTAMP (現在のシステム時刻) を主キーとして使用していたので、これは不可能だと思いました。さらに、本番前のサーバーでテストしたところ、問題なく動作しました。というわけで色々調べてみました。最終的に、サーバーで「SELECT CLOCK_TIMESTAMP()」を実行すると、時間がマイクロ秒まで返されることがわかりました。ローカルホストで実行すると、ミリ秒までしかかかりません。そのため、タイマーが次のミリ秒に到達する前に複数の更新が発生すると、問題が発生します。
だから私の質問はこれです。なぜこれが起こっているのですか、どうすれば修正できますか? これは、まだ見つけられていないあいまいな設定ですか?それとも、Windows と Linux のタイマー解像度の違いですか?
編集:CURRENT_TIMESTAMP、NOW()、およびその他すべてのタイムスタンプを返す組み込み関数でも同じことが起こります。
ありがとう
java - Java ScheduledExecutorService BAD 精度
こんにちは、ScduledExecutorService.schedule() 関数の精度をテストする簡単なプログラムを作成しました。
テストは遅延を設定し、必要な遅延と有効な結果の間の有効な距離をチェックします。
テストは、OpenJDK 1.7 と Oracle JDK 1.7 の両方を使用して、Linux 3.8 x86_64 を実行する i7 マシンで実行されました。
テストの結果は非常に悪いです。ここに、推定遅延と実際の遅延の間の平均デルタを示すリストがあります。
伝説:
- Sleep(ms) : 必要なミリ秒単位の遅延
- deltaAVG(ms) : 必要な遅延と有効な遅延の平均差(ミリ秒単位)
- deltaAVG_PERC : 必要な/有効なエラー率
- delta MIN/MAX : 必要な遅延と有効な遅延の間の最小/最大差
ご覧のとおり、deltaAVG と呼ばれる平均エラーは、遅延に対して相対的に増加しています。
遅延でより良い結果を得るにはどうすればよいですか? つまり、i7 マシンで 10 マイクロ秒で 300% のエラー率は多すぎるということです。
テストに使用したコードは次のとおりです。
sql - DBMS の小数秒精度
いくつかの例を挙げて、何が何であるかを知りたいFractional Second Precision
です。
また、さまざまな DBMS がそれをどのようにサポートしていますか?