アカウント名:
パスワード:
やはり１秒多く課金されるのでせうか？
> うるう秒のとき１秒多く課金されるのか
これ中々おもしろい考察ですよ。というのも「コンピューターにとってうるう秒とは何か」を突き詰めるとややこしい話になってきます。
そもそも(例えばUnixでは)OSにとって「時間」とはつきつめるとハードウェア的なカウンタにすぎないわけです。カウンタが "1506009661" と毎秒積み上げてるだけなのを人間がこれは 2017/9/22 01:01:01 だな、と変換して解釈しているのですから。
ところがここにNTPが絡み出すと、現実の時間との同期が意識されます。ただのカウンタだったのが、現実に併せて進みを早くしたり遅くしたりしてカウンタの値を調整するのですね。このあたりから UTC、UT0、UT1 の知識が必要になってきます。
そして一般的にNTPでは、うるう秒は「長ーい1秒」として扱われます。あえて簡単に言うと、23:59:50 あたりから 現実の1秒を PC内では 1.1秒にして意図的にPC内の時間の流れを遅くすることでゆるやかに補正する感じです。
まあつまり結論を言うと、NTPがうるう秒なんて無かったことにしてくれるからAWSにおいてうるう秒はカウントされない(はず)、です。もちろんAWSの課金システムが本当にNTPを使ってるかは中の人しか知らないのでただの外野の推測にすぎませんが、一般的なシステム運用ならそうなるはずです。
興味ある人はぜひUTCとか「何となく知ってる」じゃなくじっくり調べてみて下さい。宇宙の（地球と太陽の）動きとかも絡んでくるかなり複雑な話になってくるのでなかなかに知的好奇心が満たされますよ。
そういう動作をする場合もあるようですが、ntpdにはleap indicatorの実装があるため、通常は上位ntpサーバから流されるleap bitを受け取り、これを解釈して明示的にうるう秒を挿入します。つまり長い1秒ではなく、追加の1秒を挿入します。
Linuxの場合、さらにtzdataパッケージにうるう秒挿入予定が記載されていれば、local timeとしてxx:xx:60が表現されます。記載が無い場合はxx:xx:59が2回繰り返されます。
2012年のうるう秒挿入ではバグによるkernel panicが多発したため、leap bitを受け入れない設定で動作しているホストも多いと思いますが、その場合はうるう秒が発生した後で徐々に上位サーバとの同期を取り直す動作になります。収束までの時間は構成によりますが概ね30分〜1時間程度掛かります。
事前に1秒の長さを伸ばして帳尻を合わせるのは電話時報などです。NTTの場合は100秒前から1秒表記の間隔を1010msに延長します。
補足ありがとうございます。私などよりはるかに素晴らしい専門知識をお持ちで参考になります。
leap indicator の話まで行くと私の知見レベルではただの下手な説明になるので省略しましたが、代わりに簡潔かつ正確に説明頂いて感謝です。
私の認識では、世の運用中サーバは殆どが、うるう秒をまともに扱うようなまっとうであれど危険であることはせず、SLEWモードで無視するだろうと勝手に思っていたのですが、ちょっと不安になって改めて調べてみたところ、どうやらAWSは SLEW と STEP とシステムによってバラバラのようです。
AWS でのうるう秒対応 - Qiitahttp://qiita.com/yyoshiki41/items/d63dbbb5d4bc8e38719a [qiita.com]
ConsoleはSLEWらしいので元コメの課金の話は「うるう秒でも１秒多く課金はされない」が正解のようですが・・・こんなバラバラとは思ってませんでした。恥ずかしながら長文だらだら書く前に検索しろって話でしたね。失礼しました。
スラドにこんなに詳しく技術的なコメントのできる方がいるなんて！geek向けサイトみたいですね。
こういう稼働時間の算出って、カレンダーを使うんじゃなくて、タイマー割り込みによって増加し続けるカウンタ（を参照できるAPIなど）をもとにするんじゃないの？
根本的に間違えてませんか？
たとえば１０秒掛かる処理があったとしますではこの処理は，うるう秒をまたぐと何秒で終わるでしょうか？
１０秒です．処理時間が変わるわけがありません
たとえば23時59分55秒に処理を開始したとしますうるう秒がなければ 00時00分05秒に処理は終わります．引き算すると10秒です
うるう秒が挿入されて，23時59分59秒の次が23時59分60秒その次が00時00分00秒となったとしますこの場合は 00時00分04秒に処理は終わります．この場合も引き算すると10秒です
それはEC2を10秒だけ動かして処理してすぐ止めたときの話だねでも巷のサーバは24時間ずっと動かしっぱなしで止めたりしないのがほとんどなのよそーゆー場合の課金額のことをみんな話してるのよん
UNIXの時間をUTCで運用すればそういう動作をする場合もあるだろうけど、TAIで運用すればNTPで同期したまま23:59:60がカウントされるわけで、「NTPを使っていたらカウントされない」とは言えないんじゃないですかね。
仰るとおりです。UTC, TAI, あるいは UT1 いずれで運用するかでそのあたりは変わってきます。
その辺まで書こうと思ったらかなり長文になっちゃうので私のコメントは「一般的な」という但し書きつきでの、専門特殊でない運用の話に限らせて頂いてました。
なので補足＆鋭いツッコミ感謝です。
UT1で運用することなどありえないと思いますがw
別ACですが、ありえますよ。航空系とか天文宇宙系とか、ようは現実世界とシステムとの間において１秒以下の誤差が致命的になるような分野ですね。そっち系は全部が全部UT1ってことも勿論ないですが、全然珍しくない程度にはあります。
UT1を使うっていうのとUT1でシステムを運用するっていうのは違うからね
ん？それ拘るところ？運用≒使う、でしょ、日本語的に。そういう用語の話は置いとこうぜ。
なんか反論あるなら、ちゃんと実例を出そうな。具体的な案件の話をしないなら、それはどうでもいい用語論争で荒らしてるだけだよ。
いつ起動していつ止めたかの引き算するだけだと思うんだけれども。
その引き算においてうるう秒を意識するかどうかだけだろうけど、意識しないだろうなぁ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
うるう秒の時 (スコア:2, すばらしい洞察)
やはり１秒多く課金されるのでせうか？
Re:うるう秒の時 (スコア:5, 興味深い)
> うるう秒のとき１秒多く課金されるのか
これ中々おもしろい考察ですよ。
というのも「コンピューターにとってうるう秒とは何か」を
突き詰めるとややこしい話になってきます。
そもそも(例えばUnixでは)OSにとって「時間」とは
つきつめるとハードウェア的なカウンタにすぎないわけです。
カウンタが "1506009661" と毎秒積み上げてるだけなのを人間が
これは 2017/9/22 01:01:01 だな、と変換して解釈しているのですから。
ところがここにNTPが絡み出すと、現実の時間との同期が意識されます。
ただのカウンタだったのが、現実に併せて進みを早くしたり遅くしたりして
カウンタの値を調整するのですね。
このあたりから UTC、UT0、UT1 の知識が必要になってきます。
そして一般的にNTPでは、うるう秒は「長ーい1秒」として扱われます。
あえて簡単に言うと、23:59:50 あたりから 現実の1秒を PC内では 1.1秒にして
意図的にPC内の時間の流れを遅くすることでゆるやかに補正する感じです。
まあつまり結論を言うと、NTPがうるう秒なんて無かったことにしてくれるから
AWSにおいてうるう秒はカウントされない(はず)、です。
もちろんAWSの課金システムが本当にNTPを使ってるかは中の人しか知らないので
ただの外野の推測にすぎませんが、一般的なシステム運用ならそうなるはずです。
興味ある人はぜひUTCとか「何となく知ってる」じゃなくじっくり調べてみて下さい。
宇宙の（地球と太陽の）動きとかも絡んでくるかなり複雑な話になってくるので
なかなかに知的好奇心が満たされますよ。
Re:うるう秒の時 (スコア:3, 興味深い)
そういう動作をする場合もあるようですが、ntpdにはleap indicatorの実装があるため、通常は上位ntpサーバから流されるleap bitを受け取り、これを解釈して明示的にうるう秒を挿入します。
つまり長い1秒ではなく、追加の1秒を挿入します。
Linuxの場合、さらにtzdataパッケージにうるう秒挿入予定が記載されていれば、local timeとしてxx:xx:60が表現されます。記載が無い場合はxx:xx:59が2回繰り返されます。
2012年のうるう秒挿入ではバグによるkernel panicが多発したため、leap bitを受け入れない設定で動作しているホストも多いと思いますが、その場合はうるう秒が発生した後で徐々に上位サーバとの同期を取り直す動作になります。
収束までの時間は構成によりますが概ね30分〜1時間程度掛かります。
事前に1秒の長さを伸ばして帳尻を合わせるのは電話時報などです。NTTの場合は100秒前から1秒表記の間隔を1010msに延長します。
Re:うるう秒の時 (スコア:3)
補足ありがとうございます。
私などよりはるかに素晴らしい専門知識をお持ちで参考になります。
leap indicator の話まで行くと私の知見レベルではただの下手な説明になるので
省略しましたが、代わりに簡潔かつ正確に説明頂いて感謝です。
私の認識では、世の運用中サーバは殆どが、うるう秒をまともに扱うような
まっとうであれど危険であることはせず、SLEWモードで無視するだろうと
勝手に思っていたのですが、ちょっと不安になって改めて調べてみたところ、
どうやらAWSは SLEW と STEP とシステムによってバラバラのようです。
AWS でのうるう秒対応 - Qiita
http://qiita.com/yyoshiki41/items/d63dbbb5d4bc8e38719a [qiita.com]
ConsoleはSLEWらしいので元コメの課金の話は「うるう秒でも１秒多く課金はされない」が
正解のようですが・・・こんなバラバラとは思ってませんでした。
恥ずかしながら長文だらだら書く前に検索しろって話でしたね。失礼しました。
Re:うるう秒の時 (スコア:1, おもしろおかしい)
スラドにこんなに詳しく技術的なコメントのできる方がいるなんて！
geek向けサイトみたいですね。
Re:うるう秒の時 (スコア:1)
こういう稼働時間の算出って、カレンダーを使うんじゃなくて、タイマー割り込みによって増加し続けるカウンタ（を参照できるAPIなど）をもとにするんじゃないの？
Re:うるう秒の時 (スコア:1)
根本的に間違えてませんか？
たとえば１０秒掛かる処理があったとします
ではこの処理は，うるう秒をまたぐと何秒で終わるでしょうか？
１０秒です．処理時間が変わるわけがありません
たとえば23時59分55秒に処理を開始したとします
うるう秒がなければ 00時00分05秒に処理は終わります．引き算すると10秒です
うるう秒が挿入されて，23時59分59秒の次が23時59分60秒
その次が00時00分00秒となったとします
この場合は 00時00分04秒に処理は終わります．この場合も引き算すると10秒です
Re: (スコア:0)
それはEC2を10秒だけ動かして処理してすぐ止めたときの話だね
でも巷のサーバは24時間ずっと動かしっぱなしで止めたりしないのがほとんどなのよ
そーゆー場合の課金額のことをみんな話してるのよん
Re: (スコア:0)
UNIXの時間をUTCで運用すればそういう動作をする場合もあるだろうけど、
TAIで運用すればNTPで同期したまま23:59:60がカウントされるわけで、
「NTPを使っていたらカウントされない」とは言えないんじゃないですかね。
Re:うるう秒の時 (スコア:2)
仰るとおりです。
UTC, TAI, あるいは UT1 いずれで運用するかでそのあたりは変わってきます。
その辺まで書こうと思ったらかなり長文になっちゃうので
私のコメントは「一般的な」という但し書きつきでの、専門特殊でない運用の話に
限らせて頂いてました。
なので補足＆鋭いツッコミ感謝です。
Re: (スコア:0)
UT1で運用することなどありえないと思いますがw
Re: (スコア:0)
別ACですが、ありえますよ。
航空系とか天文宇宙系とか、ようは現実世界とシステムとの間において
１秒以下の誤差が致命的になるような分野ですね。
そっち系は全部が全部UT1ってことも勿論ないですが、全然珍しくない程度にはあります。
Re: (スコア:0)
UT1を使うっていうのとUT1でシステムを運用するっていうのは違うからね
Re: (スコア:0)
ん？それ拘るところ？
運用≒使う、でしょ、日本語的に。
そういう用語の話は置いとこうぜ。
なんか反論あるなら、ちゃんと実例を出そうな。
具体的な案件の話をしないなら、それはどうでもいい用語論争で荒らしてるだけだよ。
Re: (スコア:0)
いつ起動していつ止めたかの引き算するだけだと思うんだけれども。
その引き算においてうるう秒を意識するかどうかだけだろうけど、
意識しないだろうなぁ。
Re: (スコア:0)
・23:59:60に相当する1秒が存在する
・その前の一定期間で1秒が引き伸ばされていて23:59:60に相当するカウントは存在しない
で課金額変わってくるんじゃないの
って話してんだけど