TClockスレッド part34

**名無しさん＠お腹いっぱい。** · 2025/10/12(日) 15:38:54.57

>>633
マジで？
起動中はカーネルが時計を持ってるもんだと思っていたが
だからマザボのRTCがぶっ壊れててもいったん起動してしまえば時刻はそれなりに合う
という認識だったんだがいつのまにか仕様変更されとったんか

**名無しさん＠お腹いっぱい。** · 2025/10/12(日) 17:30:27.95

ソフトだけでどうやって1秒数えるんだよ

**名無しさん＠お腹いっぱい。** · 2025/10/12(日) 20:04:36.12

今のCPUにはカウンターが内蔵されてるから、基準の時刻さえわかれば現在時刻もわかる仕組みになってる

ただ、「カーネルが持ってる時計」ってのがなんだか意味不明に思える
ソースがあったら貼ってくれないか
俺もマザーのRTCを都度参照してるもんだと思い込んでるんで

**名無しさん＠お腹いっぱい。** · 2025/10/12(日) 20:18:21.73

時刻を知りたい時はRTCで、各種タイマー処理は内蔵タイマー、だろうな
どっちにしろハードウェア依存

RTCとCPUの内蔵タイマーはクロックソースが別だけど、
時計用に作られた方が時計としては正確なのでは

**名無しさん＠お腹いっぱい。** · 2025/10/12(日) 23:00:51.02

・Windowsでは「マルチメディアクラススケジューラサービス」というサービスが提供されている
　※昔でいう「マルチメディアタイマー」
　カーネルは、このサービスにより時間(システムクロック)を管理している
　https://learn.microsoft.com/ja-jp/windows/win32/procthread/multimedia-class-scheduler-service

・WindowsがNTPにて更新しているのはシステムクロック
　https://learn.microsoft.com/ja-jp/windows-server/networking/windows-time-service/windows-server-2016-improvements

・Windowsアプリケーションでの時刻の取得は、このサービスを叩く「timeGetSystemTime 関数」を
　用いてシステムクロックを取得するのが標準的(NTPで同期されているから)
　https://learn.microsoft.com/ja-jp/windows/win32/multimedia/obtaining-the-system-time
　https://learn.microsoft.com/ja-jp/windows/win32/api/timeapi/nf-timeapi-timegetsystemtime

それとは別に
・RTCから時刻を読みだす際は、GetSystemTime 関数により行う
　https://learn.microsoft.com/ja-jp/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtime
　Windowsがこれを使うのは以下の場合
　・OS起動時
　・NTPによる同期が設定されていない・エラーで同期されていない、等の場合(複数条件有り)

・RTCを更新する際は、SetSystemTime 関数により行う
　https://learn.microsoft.com/ja-jp/windows/win32/api/sysinfoapi/nf-sysinfoapi-setsystemtime
　Windowsがこれを使うのは以下の場合
　・NTPが成功している状況下での、W32timeサービスの停止時(≒シャットダウン時)
　・net time /setコマンド実行時
　・Step modeでの時刻同期成功時

RTCの精度は、どこかに論文があったが、温度に影響をうけるので、精度は環境・用途次第だ、と
なので、RTCはアテにせずに済むならそれに越したことはなかろうなと

**名無しさん＠お腹いっぱい。** · 2025/10/13(月) 04:08:16.08

時刻の利用頻度に対してRTCはアクセスするのが糞遅いデバイスだし秒以下の精度もないからOS起動後はHPET等で時刻進める

**名無しさん＠お腹いっぱい。** · 2025/10/13(月) 08:18:32.92

みんな同じことを言ってる
間違ってるのは>>636だけ

**名無しさん＠お腹いっぱい。** · 2025/10/13(月) 10:30:49.76

>>639
RTCは正確とは言い難い
↓はエプソンの高機能RTCの説明資料ど、このP.4にあるグラフ緑線が通常RTCの精度だけど
通常のRTCは利用環境の温度が丁度良い範囲を外れると精度が下がっていく
マザボのRTCも、高く見積もってもこの程度の精度だろう
ttps://www.epsondevice.com/crystal/en/products/rtc/pdf/rtc-module-selectionguide-ht-en.pdf

RTCは、NTPで同期されるまでの繋ぎと考えるべき程度のものだな
バックアップ時計なのだから

**名無しさん＠お腹いっぱい。** · 2025/10/13(月) 11:10:14.83

だいたい合ってればいいんだよ
前後関係さえ正しければタイムスタンプの機能は果たす
精度が必要なのは別のサーバとの前後関係が問われる場合のみ

**629** · 2025/10/13(月) 15:55:45.36

>>644
俺もだ。
だからWindows11Pro(24H2)機＋「ExplorerPatcher」の環境下で利用している「TClock-Win10」では秒数も表示させてるが、
時刻の正確さは正直あまり重視してないつもり。
https://pbs.twimg.com/media/GoTANjLWYAAjVB6.jpg
https://pbs.twimg.com/media/GoTAYL7XEAAoO-O?format=png&name=4096x4096

何らかの事情で「ExplorerPatcher」を使えない時(更新失敗時など)は、Windows11Proの24H2では
「ElevenClock」(元号表示不可)，「TWatch」，「アナログ時計DX」(元号表示不可)いずれかを利用している。
https://pbs.twimg.com/media/Gj1UgLibYAApF4I?format=png&name=4096x4096
https://pbs.twimg.com/ext_tw_video_thumb/1273069315449733120/pu/img/nCzjNyjVtrnDpbvx.jpg

「マウスのお供」「窓枠時計」(これらも元号表示不可)も「ExplorerPatcher」の無いWindows11Pro(24H2)機で利用できるが、
これらは個人的には何となく使う気になれん。

ちなみにWindowsパソコンとAndroidスマートフォンをUSBケーブルで繋いでスマートフォン側に画像ファイルを転送する際は、
JPEGファイル内のExif情報を全て除去した後に有料化後の「Neo FileTimeChange」で各タイムスタンプを累積的に変更する
事により、スマートフォン側のGoogleフォトで画像を望み通りの順番で表示可能。
そんな面倒な事まで必要ない場合は、俺が10年ちょっと前に購入した「秀丸ファイラーClassic」でタイムスタンプを変更している。
いずれも各ファイル更新時刻の前後関係を思い通り調整するためにやっている事であって、時刻の正確さをそれほど重視しているわけではない。

**名無しさん＠お腹いっぱい。** · 2025/10/13(月) 15:57:23.39

>>637
1秒はタイムスタンプカウンターとかタイマー割り込みとかで作るよ
RTCを読み書きするのは起動直後とあとは時計を合わせるときくらいだと思う

**名無しさん＠お腹いっぱい。** · 2025/10/13(月) 16:00:37.56

タイマー割り込み使うようなのはソフトだけではなく、むしろハードだけ

**629** · 2025/10/13(月) 17:09:24.22

そういや元々4GBを超えるLZH書庫の作成/展開/自己解凍書庫作成やUnicodeにも対応している「UNLHA32.DLL」
https://www.vector.co.jp/soft/win95/util/se020193.html に付属の"API.TXT"や"COMMAND.TXT"によると、
exFATやFAT32より前にMS-DOS時代から一般的だったFAT16(16ビットのFAT(ファイルアロケーションテーブル))では
秒を5ビットで表すため、2秒単位でしか秒数を表現できない仕様だったらしい。
その上、Windows95/98/MeだけでなくWindowsNT/2000/XPにもタイムスタンプ関連のバグや制限事項が存在していたらしい。

そのあたりが近年のWindows11などで一体どうなっているのかは知らんが、あまり時刻の正確さに拘るのはナンセンスと言うべきかも？