アカウント名:
パスワード:
まれにしかロールオーバーしないので、まれなロールオーバーの設計に不備が入りやすいもっと頻繁にロールオーバーする設計にすれば、すぐに欠点が見つかり修正される数か月に一度ロールオーバーするように設計するとか、そもそも週データを持たずに毎週ロールオーバーする設計にするとかで
>まれにしかロールオーバーしないので、まれなロールオーバーの設計に不備が入りやすい
GPS 衛星が放送している時刻情報「週番号」は、そのサイズが 10BIT、すなわち 0 から 1023 の範囲で出力されており、1024 週の次は 0 に戻ることが GPS 衛星の仕様として一般に知られています。
1024週目 ~ 約19年半で必ずロールオーバーする仕様を「まれ」なことにしちゃいますか。まぁ、数年で壊れて使われなくなる前提の製品設計だとそれもありかもしれませんね。たまたま壊れずに使われてたら悲劇。
バグとかじゃなくて、仕様としてロールオーバー1回分にしか対応していない機器はあるよ。というか、組み込みでファームアップデート無しなら、むしろそっちが普通なくらい。20世紀の頃に年を2桁で現して 80-99 なら 1900年代、00-79 なら2000年代とかやってたのと同じ感覚で週番号から年を推測する仕様。
前回のロールオーバー後の 15〜19年前くらいに設計された機器なら仕様としてロールオーバーそのものに対応していない可能性はおおいにある。
そもそも、「GPSからの情報だけを元にした」場合、一周分を超えた週番号のロールオーバー判定は原理的には対応できないよね。簡単に言えば「時分秒だけ表示される時計を見て、日付も特定せよ」みたいな問題なわけで、別途「不揮発メモリを使ってロールオーバー回数を記録する」とか「年月日情報を別ルートから仕入れる」といった補完方法を用意しないと無理。
…と、ここまで書いたところで、ちょっとググったら、GPSからの情報だけでも・閏秒情報を見る(GPS時刻は閏秒がなくUTCとはずれているので、別途UTCとのズレも送信されている)・衛星番号を見る(衛星の寿命は20年もないから、衛星番号からどのサイクルか判定できる)などといったアドホックなロールオーバー判定方法があるにはあるみたいです。でも、過去のデータからのサイクル判定はともかく、20年後の未来のサイクル判定に使うにはちょっと不確実過ぎて当てにするのは無謀そう。
まぁロールオーバー回数ならめったに変化せずどこまで高寿命でも大した状態数は要らないので、古の物理的に焼き切るヒューズビットみたいなのでも問題なく記録できそう。
ヒューズビットまでいくと不揮発メモリ呼びして良いのだろうか……
ロールオーバーを判定するためには「前回よりも週数が減っている」ことの検出が必要なので、「最後に測位した時の週数」も不揮発記憶する必要があるかと。
ずっと電源オフで20年ぶりに電源オンとかされたら、もうどうしようもない。
ドライブレコーダーなんて録画をロールオーバーしない製品の方が多いしな断片化対応はけっこう面倒
2000年問題やその後の二桁西暦保持実装を思い返せば何ら不思議ではない話だと思うのだが。その教訓を活かしてないって意味なら確かにお粗末だが、そういう実装がある事自体は当然というか、むしろ無いほうが驚くレベル。
閏年を実装していない(デジタル)時計もあるし、日本でも元号制定=「大化」前は、干支紀年法が使われていた。
# 前にも「GPSロールオーバー」騒動があった記憶があるが、あれからもう20年たったのか。
内部時計を持っていない、かつGPS以外と通信する機能を持たない機器だと「今が何年何月何日」を特定するのはGPSの週番号以下だけが頼り。雑な実装だとは思うけど、低価格でそれほど長期間使用することを想定していない機器なら、「週番号がロールオーバーしたらダメ」とか「製造日から1024週経過したらダメ」というのはありうる。
Windowsの49.7日問題とか思い出しますね。なんかぐぐるとWindows 10で特定のディスプレイドライバか何かに同様の問題があるみたいな書き込みも見かけますが……
未だに49.7日に起因する問題はたまにでてますよ。数年前にあったのは、WindowsServer2012R2で、モニタをつけっぱなしに設定していた場合でも、49.7日でモニタの電源が切れてしまう問題とか。
Windows Updateですでに修正済みですが、インターネットにつながっていない環境で、しかも24時間の監視システムなので、モニタが勝手に切れるのは困るんです
まともなエンジニアなら10年に一回だろうが、一日一回だろうが、同じ話ですよ。
テストケースを一つ追加して、ロールオーバー時にバグが出ないか試すという試験項目を追加するだけです。
ロールオーバーの間隔は本質的な問題ではありません。ロールオーバーを考慮するかしないか、そのテストをちゃんと行うかどうかという話です。
毎週のロールオーバーで救えるのはテストを考えてない行き当たりバッタリのエンジニアとか趣味でプログラムを書いているアマチュアだけです。
理屈はあくまでそうやとしても、リスクは別やな。発生する頻度が少ないと、発生したときにちゃんと対処できてるのか、という不安自体がリスクやろ。そして、実際に対処できてないことも少なくないから、現実にトラブルになっとる。
他コメで言い合いみたいになっとるけど、やればできるはずの理想かやってもできないかもしれん現実か、見てるとこがまったく違うんやから、結論なんかないで。w
そういえばソースは忘れたけど、まれなサーバークラッシュに対処する単発リストアがそのときに限って(でもないやろけどw)失敗してまうので、いっそ逆に、リストアフローを恒常的にまわしたる、みたいなとこがあったな。
なんで文章に方言?
清く正しく美しい日本語を守るために訛っている「なんで」という語ではなく「なぜ」という語を用いるべきです。
また、体言止めは語の省略であり読者に対して語の補完を強いるものです。それは読者毎に補完する語が異なり複数の解釈を許すということでもあります。特に疑問文においては文意が不明瞭になりやすく時に方言よりも読解が困難になることさえあります。作文が苦手なうちはついつい多用してしまいがちですが可能な限り使用を避けるのがよいでしょう。
> テストケースを一つ追加して、ロールオーバー時にバグが出ないか試す> という試験項目を追加するだけです。 理論的に美しい職場環境にいらっしゃるようで羨ましい。
自動券売機障害のとこにも湧いてるけど、とても現場を経験したことなさそうな理想論振りかざして、ダメとかクソとか言うやつなんなんだろうね。どこにお勤めか聞かせてほしいわ。
これくらいで理論的に美しいとかプログラマ向いてないのでは?転職をおすすめします
「ロールオーバー時に」「バグが出ないか試す」前半の条件は有無だけの簡素な(模擬信号計算の手間は除く)条件だが、後半が前半と競合しない全ての検査項目を含みうるってーのが分からん人も向いてない気がするな。
# 美しいというか不明瞭。その定義で全部自動テストが通るんならすごく美しいと評せるかもだが。
過去日を扱わないシステムで、うるう年を完全に実装するかと言われると... AND 3 で決定しちゃいそう。次の例外って80年後...
せやな [wikipedia.org]
#「すべてがFになる」って、もう20年前の作品なんだ。
いわゆる理系に分類されるキャラクター達がリアルだなぁと思った最初の小生だなぁ。なつかしい。
ロールオーバーの間隔は本質的な問題だよ。これ、問題が起きるのは設計に問題があるからではなくて、仕様上機器が対応していないからだから。20年間隔のロールオーバーだから、製品仕様として成り立つのであって、1週間ごとに更新なら仕様上対応しないなんてことはない。
仕様でどこまでカバーするかは、プロなら必ず確認する事項だよね?コスト無限の仕事でも無い限り、何でもかんでも仕様に盛り込むことは出来ない。コストを考慮して適切な仕様にすることが、プロの仕事。
仕様を100%満たす実装にするのか使用する分だけ満たせばいいのか使用する箇所でも問題になっても個別対応で済むものは切り捨てていいのか
それを決めるのはエンジニアとは限らないし、コストや納期との兼ね合いで妥協しなければならないこともあるそもそも決定権を持つ人間がテストまで書いてるのが稀だろう
それこそ趣味でプログラム書いてるアマチュアの言い出しそうなことだと思ったよ
>ロールオーバー時にバグが出ないか試すこれで済むんだったら、製品としてバグがないか試すの1つだけで済む気がします。
SNMPv1のカウンタが4Gくらいで一周してしまって、前回との差分がマイナスになったりしたのを思い出しますね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
設計が悪い (スコア:0)
まれにしかロールオーバーしないので、まれなロールオーバーの設計に不備が入りやすい
もっと頻繁にロールオーバーする設計にすれば、すぐに欠点が見つかり修正される
数か月に一度ロールオーバーするように設計するとか、そもそも週データを持たずに毎週ロールオーバーする設計にするとかで
Re:設計が悪い (スコア:1)
>まれにしかロールオーバーしないので、まれなロールオーバーの設計に不備が入りやすい
GPS 衛星が放送している時刻情報「週番号」は、そのサイズが 10BIT、すなわち 0 から 1023 の範囲で出力されて
おり、1024 週の次は 0 に戻ることが GPS 衛星の仕様として一般に知られています。
1024週目 ~ 約19年半で必ずロールオーバーする仕様を「まれ」なことにしちゃいますか。
まぁ、数年で壊れて使われなくなる前提の製品設計だとそれもありかもしれませんね。
たまたま壊れずに使われてたら悲劇。
Re: (スコア:0)
バグとかじゃなくて、仕様としてロールオーバー1回分にしか対応していない機器はあるよ。
というか、組み込みでファームアップデート無しなら、むしろそっちが普通なくらい。
20世紀の頃に年を2桁で現して 80-99 なら 1900年代、00-79 なら2000年代とかやってたのと同じ感覚で週番号から年を推測する仕様。
前回のロールオーバー後の 15〜19年前くらいに設計された機器なら仕様としてロールオーバーそのものに対応していない可能性はおおいにある。
Re:設計が悪い (スコア:2)
そもそも、「GPSからの情報だけを元にした」場合、一周分を超えた週番号のロールオーバー判定は原理的には対応できないよね。
簡単に言えば「時分秒だけ表示される時計を見て、日付も特定せよ」みたいな問題なわけで、別途
「不揮発メモリを使ってロールオーバー回数を記録する」とか「年月日情報を別ルートから仕入れる」といった補完方法を用意しないと無理。
…と、ここまで書いたところで、ちょっとググったら、GPSからの情報だけでも
・閏秒情報を見る(GPS時刻は閏秒がなくUTCとはずれているので、別途UTCとのズレも送信されている)
・衛星番号を見る(衛星の寿命は20年もないから、衛星番号からどのサイクルか判定できる)
などといったアドホックなロールオーバー判定方法があるにはあるみたいです。
でも、過去のデータからのサイクル判定はともかく、20年後の未来のサイクル判定に使うにはちょっと不確実過ぎて当てにするのは無謀そう。
Re: (スコア:0)
まぁロールオーバー回数ならめったに変化せずどこまで高寿命でも大した状態数は要らないので、
古の物理的に焼き切るヒューズビットみたいなのでも問題なく記録できそう。
ヒューズビットまでいくと不揮発メモリ呼びして良いのだろうか……
Re: (スコア:0)
ロールオーバーを判定するためには「前回よりも週数が減っている」ことの検出が必要なので、「最後に測位した時の週数」も不揮発記憶する必要があるかと。
ずっと電源オフで20年ぶりに電源オンとかされたら、もうどうしようもない。
Re: (スコア:0)
ドライブレコーダーなんて録画をロールオーバーしない製品の方が多いしな
断片化対応はけっこう面倒
Re: (スコア:0)
2000年問題やその後の二桁西暦保持実装を思い返せば何ら不思議ではない話だと思うのだが。
その教訓を活かしてないって意味なら確かにお粗末だが、
そういう実装がある事自体は当然というか、むしろ無いほうが驚くレベル。
Re: (スコア:0)
閏年を実装していない(デジタル)時計もあるし、日本でも元号制定=「大化」前は、干支紀年法が使われていた。
# 前にも「GPSロールオーバー」騒動があった記憶があるが、あれからもう20年たったのか。
Re: (スコア:0)
内部時計を持っていない、かつGPS以外と通信する機能を持たない機器だと「今が何年何月何日」を特定するのはGPSの週番号以下だけが頼り。
雑な実装だとは思うけど、低価格でそれほど長期間使用することを想定していない機器なら、「週番号がロールオーバーしたらダメ」とか「製造日から1024週経過したらダメ」というのはありうる。
Re: (スコア:0)
Windowsの49.7日問題とか思い出しますね。
なんかぐぐるとWindows 10で特定のディスプレイドライバか何かに同様の問題があるみたいな書き込みも見かけますが……
Re: (スコア:0)
未だに49.7日に起因する問題はたまにでてますよ。
数年前にあったのは、WindowsServer2012R2で、モニタをつけっぱなしに
設定していた場合でも、49.7日でモニタの電源が切れてしまう問題とか。
Windows Updateですでに修正済みですが、インターネットにつながっていない環境で、
しかも24時間の監視システムなので、モニタが勝手に切れるのは困るんです
Re: (スコア:0)
まともなエンジニアなら10年に一回だろうが、一日一回だろうが、同じ話ですよ。
テストケースを一つ追加して、ロールオーバー時にバグが出ないか試す
という試験項目を追加するだけです。
ロールオーバーの間隔は本質的な問題ではありません。
ロールオーバーを考慮するかしないか、そのテストを
ちゃんと行うかどうかという話です。
毎週のロールオーバーで救えるのは
テストを考えてない行き当たりバッタリのエンジニアとか
趣味でプログラムを書いているアマチュアだけです。
Re:設計が悪い (スコア:2)
理屈はあくまでそうやとしても、リスクは別やな。
発生する頻度が少ないと、発生したときにちゃんと対処できてるのか、という不安自体がリスクやろ。
そして、実際に対処できてないことも少なくないから、現実にトラブルになっとる。
他コメで言い合いみたいになっとるけど、やればできるはずの理想かやってもできないかもしれん現実か、見てるとこがまったく違うんやから、結論なんかないで。w
そういえばソースは忘れたけど、まれなサーバークラッシュに対処する単発リストアがそのときに限って(でもないやろけどw)失敗してまうので、いっそ逆に、リストアフローを恒常的にまわしたる、みたいなとこがあったな。
Re: (スコア:0)
なんで文章に方言?
Re: (スコア:0)
なんで文章に方言?
清く正しく美しい日本語を守るために
訛っている「なんで」という語ではなく「なぜ」という語を用いるべきです。
また、体言止めは語の省略であり読者に対して語の補完を強いるものです。
それは読者毎に補完する語が異なり複数の解釈を許すということでもあります。
特に疑問文においては文意が不明瞭になりやすく
時に方言よりも読解が困難になることさえあります。
作文が苦手なうちはついつい多用してしまいがちですが
可能な限り使用を避けるのがよいでしょう。
Re: (スコア:0)
> テストケースを一つ追加して、ロールオーバー時にバグが出ないか試す
> という試験項目を追加するだけです。
理論的に美しい職場環境にいらっしゃるようで羨ましい。
Re: (スコア:0)
自動券売機障害のとこにも湧いてるけど、とても現場を経験したことなさそうな理想論振りかざして、ダメとかクソとか言うやつなんなんだろうね。
どこにお勤めか聞かせてほしいわ。
Re: (スコア:0)
これくらいで理論的に美しいとか
プログラマ向いてないのでは?転職をおすすめします
Re: (スコア:0)
「ロールオーバー時に」「バグが出ないか試す」
前半の条件は有無だけの簡素な(模擬信号計算の手間は除く)条件だが、
後半が前半と競合しない全ての検査項目を含みうるってーのが分からん人も向いてない気がするな。
# 美しいというか不明瞭。その定義で全部自動テストが通るんならすごく美しいと評せるかもだが。
Re: (スコア:0)
というパターンかな。
ついでに「すぐできますよね」と念を押しておきながら決裁を止めていたりする。
Re: (スコア:0)
過去日を扱わないシステムで、うるう年を完全に実装するかと言われると... AND 3 で決定しちゃいそう。
次の例外って80年後...
Re: (スコア:0)
せやな [wikipedia.org]
#「すべてがFになる」って、もう20年前の作品なんだ。
Re: (スコア:0)
#「すべてがFになる」って、もう20年前の作品なんだ。
いわゆる理系に分類されるキャラクター達がリアルだなぁと思った最初の小生だなぁ。なつかしい。
Re: (スコア:0)
ロールオーバーの間隔は本質的な問題だよ。
これ、問題が起きるのは設計に問題があるからではなくて、仕様上機器が対応していないからだから。
20年間隔のロールオーバーだから、製品仕様として成り立つのであって、1週間ごとに更新なら仕様上対応しないなんてことはない。
仕様でどこまでカバーするかは、プロなら必ず確認する事項だよね?
コスト無限の仕事でも無い限り、何でもかんでも仕様に盛り込むことは出来ない。
コストを考慮して適切な仕様にすることが、プロの仕事。
Re: (スコア:0)
仕様を100%満たす実装にするのか
使用する分だけ満たせばいいのか
使用する箇所でも問題になっても個別対応で済むものは切り捨てていいのか
それを決めるのはエンジニアとは限らないし、コストや納期との兼ね合いで妥協しなければならないこともある
そもそも決定権を持つ人間がテストまで書いてるのが稀だろう
それこそ趣味でプログラム書いてるアマチュアの言い出しそうなことだと思ったよ
Re: (スコア:0)
稀だとしても、決定だけしてその決定が実施されたかどうか全く確認しないという人間に決定権を持たせるべきではありませんね。
Re: (スコア:0)
>ロールオーバー時にバグが出ないか試す
これで済むんだったら、製品としてバグがないか試すの1つだけで済む気がします。
Re: (スコア:0)
SNMPv1のカウンタが4Gくらいで一周してしまって、前回との差分がマイナスになったりしたのを思い出しますね。