64 bit long
データ型を任意のデータ型に変換する方法を知りたい16 bit
です。この機能は、イーサネット アプリケーションでタイム スタンプを含めるために必要です。タイムスタンプを含めるために利用できるのは2 バイト( 16 ビット)だけです。しかし、からのタイムスタンプ値を取得しています。そのため、64 ビット データ型から 16 ビット データ型への変換が不可欠です。64 bit long
Win API
4 に答える
64 ビットの情報を 16 ビットのストレージに収めることはできず、情報の一部が失われます。
したがって、タイムスタンプを量子化または切り捨てる方法はあなた次第です。たとえば、ナノ秒の精度でタイムスタンプを取得するとしますが、秒の精度でのみ保存する必要があります。その場合、64 ビット数を 1000000000 で割り、秒が残ります。次に、16 ビットに収まるかどうかはわかりません (16 ビットは 65535 秒までしか格納できません)。
収まらない場合は、タイムスタンプが定期的にラップされます。繰り返しますが、これはあなたの場合に問題になるかもしれませんし、問題にならないかもしれません。
いずれにせよ、タイムスタンプを必要とする既存のライブラリとのインターフェースが必要な場合は、そのタイムスタンプに必要なものを見つけてください (クロック ティック? 秒? 年?)。次に、使用している Windows times 関数が何を返すかを調べます。次に、Windows の時間単位を、使用するライブラリの時間単位に変換します。
タイムスタンプが必要なものに応じて、16 ビットで十分な場合と不十分な場合があります。ほとんどの場合、小さすぎるか、少なくとも不便です。ただし、これが機能する可能性のある例としては、タイムアウト、パケットのラウンドトリップ時間の測定、時間間隔の大まかな測定 (時間情報をユーザーに表示するのに適している場合があります) などがあります。
一方、パケットの並べ替えにはおそらく役に立たないでしょう。この場合は、タイムスタンプをシーケンス カウンターに置き換えることをお勧めします。ストリーム内の典型的なパケット数によっては、数ビットを切り捨てて他の目的に使用できる場合もあります。これは、シーケンス カウンターの方がラッピングをより簡単に処理できるためです。
他の人が言ったように、最初の問題は正しいスケーリングを決定することです。解像度と希望する最大範囲のバランスを取る必要があります。それについて考える 1 つの方法は、必要なビットあたりの秒数を決定することです。1 ビットあたり 1 秒を使用すると、1 秒から 65536 秒または ~1000 分までの値を表すことができます。1 ビットあたり 1 ミリ秒で、0.001 秒から 65.5 秒まで可能
変換を行う 1 つの方法を次に示します。
#define seconds_per_bit .0001 <--YOUR VALUE HERE.
#define bits_per_second (1/seconds_per_bit);
int16 timestamp()
{
Int64 counts_per_second,counts;
QueryPerformanceFrequency(&counts_per_sec);
QueryPerformanceCounter(&counts);
return (UInt16)(counts * bits_per_second / counts_per_second);
}
タイムスタンプを何に使用するかによって完全に異なります。あなたはイーサネットに言及しているので、私が想像できる明らかな用途の1つは、パケットの注文です。その場合、本当に必要なのはカウンターだけです。「このパケットは 5 月 14 日の午後 14 時 35 分に送信されました」というタイムスタンプの代わりに、単に「これは 4023 番目のパケットです」と言うことができます。
実際のクロック時間を記録する必要がある場合は、関連する部分を選択するだけです。16 ビットを使用すると、65536 個の値を使用できます。それらを秒で表したいですか?その後、タイムスタンプは 18 時間ごとにラップアラウンドします。
または、数分になることもあります。それから彼らがラップアラウンドするまでに45日かかります. または数日、またはマイクロ秒、それはすべて必要なものに依存します.
しかし、64 ビットの値を 16 ビットの値に変換できる唯一の方法は、48 ビットのデータを削除することです。どれを選ぶか