スラッシュドット・ジャパン

まぐまぐ！が過去に配信したメールマガジン [mag2.com]によると、@5msで248日になるそうです。あとがきより引用します。

また、タイマの値も４３億までで、１０ミリ秒ごとに１つずつ値を
増加させると４９７日と少しで４３億となります。
５ミリ秒ごとだと２４８日と少しです。
WindowsやLinuxでは４９７日問題や２４８日問題というものがあり
ます。
これは３２ビットOSの問題なのでネットワーク機器でも起こりえます。
こういうところからも、OSは定期的にリブートしておいたほうが
無難、という結論が得られます。

「調子が悪かったらとりあえず電源を入れ直す」なんてのは、一般人の方が逸般人よりありがちじゃないですかね。
問題は「いきなり電源を切っちゃヤバイもの」でも平気でコンセントから引っこ抜いちゃいすることで…

1週間ほど前、自宅の無線LANが不調になって、結局アクセスポイントの再起動で復旧したということがありました。
でもって数日前、私が在宅じゃない時に、妻のノートPCでインターネットが出来なくなったのですが、上記トラブル対応を上辺だけ真似して、「アクセスポイントの他にルーターなどネットワーク機器が繋がっている大元の電源プラグ」を何度か「引っこ抜いて挿す」→「直ったかどうか試す」なんてことをやられてしまいました。

自宅サーバでWWW/メールとかも受けてるので、ネットワーク接続を常時監視しているのですが、その頃、私は職場にいて、ネットワークが切れたのを知りあせりました。
フレッツ光でプロバイダは2つ併用していますがどちらも不通なのでプロバイダは無実と推定。NTTの工事・故障情報にもなにもなし…
って途方に暮れかけたところでネットワークが復旧。帰宅してから顛末を聞いて脱力です。

#「インターネット出来ない」のトラブルはPC側が原因で、無線LAN用PCカードのドライバを再インストールしたら直りました。

元の表現の「当然ですが」は後側に掛っています。ここを勘違いしているなら読みなおしてくれ。で、

> 結論に達するのはよっぽど自分に自信があるんだな。
そうだよ。「x, yが(unsigned) intの範囲外かもしれないが、x-yがintの範囲内であることが保証される場合」というのが正確な条件の表現だよ。
もちろん、「xやyが範囲外かもしれない」という表現からも分かるようにx,yなどはMathematical Valueで考えるよ。

> 0x80000000以上の変化が存在するときは正常に比較できないことだ。
これは間違い。

例えば、(以下多くの処理系が採用しているようにintはsignedで32bitとする)
int x = y = 1
x += 0x90000000;
x -= 0x80000000;
の場合は0x80000000以上の変化が存在するが(x-yのMathematical Valueは0x10000000でintの範囲内だから) x - y > 0 で正常に比較できる。

iny x = 0;
int y = -0x7fffffff;
++x;
の場合は0x80000000以上の変化が存在しないが(x-yのMathematical Valueは0x80000000でintの範囲内でないから) x - y > 0 で正常に比較できない。

すなわち「0x80000000以上の変化が存在するかどうか」はx-y>0で正常に比較できるかどうかと関係ない。
あくまでも比較可能である条件は私の書いたのが正確。

ちなみに君が勘違いした理由かもしれないものの一つを挙げておくと、
「片側の変数が変化しない場合に限り、もう片側の変数のトータルの変化が0x80000000以上の変化が存在しない」は「x-y>0で正常に比較できる」ことの必要条件である(上記の反例の通り、十分条件ではない)。

「ほら、全部Nが付いてるよな。」
「あ！、NTT東日本とNTT西日本か。」

うちはルーター機能も止っていたので、熱暴走かと思ってましたよ。

ある日帰ってくるとPPPoEセッションが切れたまま、再接続できないし...

しかし、メーカーの違う光ルーター両方で同じ問題を出すとは...
同じOSでも使ってたんでしょうかね？

ウォッチドッグの基本は
「正常に動作しているなら、カウントダウン(アップでもいいけど)が進まないようにする」
「従って、異常になったら進む(場合もあり、それが検出対象)。一定値まで行ったら異常検出と見なす」
なので、今回の件とは関係無い。

249日も余裕を見たウォッチドッグだとしたら存在自体がギャグ。

NT系列には497日問題 [microsoft.com]がありました。こっちは10ミリ秒単位で32ビット符号無しかな。今回の問題の2倍。