冬はPCに負荷をかけても温度が上がりにくいということで、distributed.netの季節だ。
私もいよいよ、OGR-NGプロジェクトで世界上位600位に食い込めそうなところまで来た。
http://stats.distributed.net/participant/psummary.php?project_id=28&id=45965
現有戦力を全開でぶん回せば年内に600位達成できるだろうか。
しかしながら、20年の歴史があるd.netで、3年前からやってるプロジェクトの参加者が全部で45000人程度、今アクティブにやってるユーザーが1500人程度、という有様で、もうちょっとどうにかなんないかなー、と思う。
基本的にはCore i3-6100を一台回してるだけの私が、45000人中600位につけてるというのは、凋落激しくて寂しい。
もうちょっとユーザー増えないかな、と思うので、微力にも程があるけど少し煽ってみたい。
なお、色々書いてたら18000字にもなってしまってるので、実に長い記事である。distributed.netの歴史から具体的な参加方法まで、けっこうよく網羅してると思う。そんな長文書いても読まれんとは思うのだが、しかしこんな年単位で長々と続ける遊びに対して、たかが18000字を読むことを厭うような短気さではどうせ参加しても続かんので、こんな記事読もうと思うような気の長い人にさえリーチすりゃよかろうと思う。この長い段落読む必要ないけど。
しかし、今更distributed.net(以下d.net)を少しなりとも流行らす術なんてものがあるのかどうか、さっぱりわからない。
趣味的なことなんて、やってて楽しいという話を吹聴するに如かずだとは思うものの、あんまりわかりやすい楽しさがあることでもない。
その代わり、始めてしまえば特に手間もかからないので、飽きるというようなこともない。だらだらと長期間、思いついた時に止めたり、思い出した時に始めたり、そんなこんなで私はもう15年くらいやっている。
まあ、とにかく手間はかからない。時間はかかる。
この手間のかからなさと長い時間のかかることを、なにか他のことに例えようと考えたら、「屋根からいつも水滴が滴るところに好みの石を置いて穴が穿たれるのを眺める」なんてのが近いかもしれない。
分散コンピューティングとは
distributed.netは、もう20年くらい前からやっているという老舗中の老舗の、分散コンピューティングプロジェクトのひとつ。
分散コンピューティングとは、スーパーコンピューターでも解決に長い時間がかかるような問題を、細かく分割してインターネット経由で配布して、参加者のパソコンで処理して返送する。大勢の参加者があれば、難問も数の力で突破できる、というやつ。
例えば、素数を探すGIMPSは、知られている世界最大の素数を次々と発見してきた。
地球外生命体を探すSETI@homeは、宇宙から降り注いでいる電波を細かく調べ、説明のつかない不自然な電波を見つけている。また、分散コンピューティングの効果自体も研究対象で、それがBOINCという複数の統合プラットフォームに発展してもいる。
タンパク質の折りたたみ構造を解析するFolding@homeは、病気の原因を調べたり創薬につなげたりといった研究をしている。
もう終わったけど、United Devicesのガン研究・創薬プロジェクトが「命を救え」とか煽られつつ日本でも流行ったこともあった。
いずれも、科学の進歩にわずかながら寄与できる。
活発なプロジェクトなら、GPGPUのような新しい技術を早々と取り入れて、解析を加速化しているので、それに触れることもできる。
また、ユーザーランキングがあったりして、誰がどれだけ処理できたかの記録が残され、それを眺めてにやにやしたりできる。
マニア向けのものであることは否定しようがないけれど、ささやかな科学への貢献と、ささやかな自己満足は得られる。
ちなみに、科学の進歩には寄与しないが、Bitcoinなんかも内容的には近い。これが一番流行ったのがなんか寂しいけれど。世は資本主義の、マネーの時代だ。
distributed.netの場合
distributed.netはもともと、RC5暗号の解読を目指して始まった。
もう古い話だけれど、Windows 95くらいの頃は、アメリカが強力な暗号技術の輸出に規制をかけていた。だから、Windowsやブラウザが、米国版では128bit暗号が使えたのが、日本などでは40bitまで弱体化されていた。
40bit暗号なら許可なしに輸出できるものの、20年前のパソコンでも総当たり攻撃で破れるほど弱い。米政府や米軍からすれば、他所がそんなの使ってるなら一方的に傍受できて便利だけど、我々一般人は、インターネットでクレジットカード番号などを送るのも恐ろしい。
40bitの暗号なら輸出していい、なぜなら容易に解読できるから。だったら、もっと強力な暗号だって、実際に解読できることを示せば、その輸出規制を解除する話に持っていけるのでは。
ということで、RSA Data Securityという会社が、賞金付きでRC5暗号の解読者を募った。そこにdistributed.netが乗って、分散コンピューティングの手法で解読にかかった。
RSA社の暗号解読コンテストで「56bit RC5」が破られる (INTERNET Watch)
まずは、RC5の56bit暗号を、97年2月から10月の間で解読成功した。
そして56bit DES暗号3種のうち2種（ひとつは協力相手の解読専用機が見つけてしまった）、56bit CS暗号と、次々解読していったのが98年ごろ。
パソコン一台で数日で解読できる程度だった40bit暗号、その65536倍強力になる56bit暗号も解読できると証明してみせた。おら56bitくらい輸出させろ、という政府へのアピールになった。
distributed.netが64ビット暗号「RC5-64」の解読に成功
56bitの256倍強力なRC5-64bitも、2002年7月に解読した。正解キーを引き当てたのが日本人だったらしく、賞金の一万ドルもその人が受け取ったとか。
そして次にチャレンジするのが、RC5-64の256倍強力な、RC5-72となった。
これは2002年に始まり、2016年末現在なお終わっていない。やっと全体の4.3%ほど進んだが、いつ終わるんだろうか……
なお、みんなAmazonで買い物していることからもわかる通り、米政府はすでに輸出規制を緩和していて、ブラウザなどでも強力な暗号が使えている。
RSA Data Security社の賞金提供も2007年に終わってしまった。RC5-72は、いつか解けても1万ドルはもう出ない。まあ、d.netが代わって賞金を出すらしいけれど。（そんなカネ持ってるのかな）
d.netは、暗号解読以外に、数学系のプロジェクトとして「Optimal Golomb Ruler（最短ゴロム定規）」の探索もやっている。
ゴロム定規、というのも、一度わかれば大して難しいことじゃないのだけど、馴染みがないとピンと来づらいので、説明を試みる。
ひとつの直線の定規に、0 1 3 9にだけ目盛りを打ってる定規があるとしてみよう。これはゴロム定規のひとつ。
この4つの目盛りから、2つ取り上げてその間の長さを見てみる。要するに目盛りを使って測れる長さね。
0-1の間は当然長さ1。1-3の間は長さ2。3-9の間は長さ6。
0-3は長さ3、0-9は長さ9。1-9は長さ8。
すべて、測れる長さが違っている。被りはない。これがゴロム定規の定義。
まあ、単なるゴロム定規なら、全体の長さ（要は最後の数字）を伸ばしていけば無数に作れる。
では目盛りの数が4つのゴロム定規の中でも、特に「0 1 4 6」はどうか。
長さ1なら0-1の間で。2なら4-6の間。3なら1-4の間。4なら0-4の間。5なら1-6の間、6なら0-6の間で、定規の長さまでにある長さをすべて測れる。
こういうのを完全ゴロム定規という。
しかし、目盛りの数が5つになると、完全ゴロム定規は作れない。これは数学的に証明されている。
なので目盛り5つ以上では、定規の長さが最も短いものを求める。それを最短ゴロム定規という。
目盛り5つの最短ゴロム定規は、0 1 4 9 11と0 2 7 8 11の2通りになる。(0 2 7 10 11とか0 3 4 9 11のような左右逆転してるのは除外ね）
0 1 4 9 11は6が測れないし、0 2 7 8 11だと10が測れない。なので完全ゴロム定規とはいえない。
もし完全ゴロム定規が存在すれば、全体の長さは10になりそう（0+1+2+3+4=10)なんだけど、それは存在しない。
なら、全体の長さが11でゴロム定規になっているものが最短ゴロム定規。目盛り5つなら長さ11で見つかるからいいけど、見つからないなら伸ばしていきながら探すしか無い。
目盛り5つくらいならともかく、20とかになるともう大変。数字の組み合わせのパターンもどんどん増えるし、長さがどうなるかもわからない。
0 1 8 11 68 77 94 116 121 156 158 179 194 208 212 228 240 253 259 283がOGR-20だけども、見てるだけで目が回る。
まあ、まさかこんなもん手計算で求めてるとも思えず、とにかくコンピューターで求めたんだろうと思う。そのやり方がスマートな計算じゃなく、総当り的な力技であれど、ともかくできるんだろう。むしろそれだからこそ分割して配布する分散コンピューティングが使えるような気はするし。
目盛り23個のものまでは、最短ゴロム定規が特定されていた。
しかしこれ以上はちょっと計算量が膨大過ぎる、ということで、d.netが着手。
24目盛りのOGR-24を、1572日かけて特定した。
OGR-25は3006日かかった。OGR-26は簡単だったらしくて24日で済んだ。OGR-27は1822日で特定した。
もちろん目盛りが増えると計算量も急増するはずだけど、参加者のコンピューターが高性能化していることもあって、大体5年に一回程度のペースで特定に成功してきている。
今やっているOGR-28は、1000日ほどかけてまだ25%弱しか進んでいない。
1000日前に比べてさほど民間のCPU性能が上がっているとも思えず、また参加者も減っているだろうから、苦戦が続きそうだ。
で、私が何年も参加しているのが、このOGR探索。
OGRはフェイズドアレイレーダーとか電波望遠鏡に応用されているらしいけれど、まあ、地味な数学的問題には違いない。
華々しく重要と思われ、解決すれば商売になるから投資しましょう、というような問題ならそうなってるわけで、そうはならない地味な問題だからこそ、分散コンピューティングで微力を寄せ合って解くことの自己満足度が高いように思う。
d.netがやらなきゃ放置されてしまう問題に思えるし。私が参加せねば誰もやらないぞ、と。
まあOGRの儲かる利用法が見つかったら、いきなり投資が集まって凄い勢いで解決されていくかもしれんけど。
どのプロジェクトに参加するか
で、すでに挙げている通り、d.netに限らず、こういう分散コンピューティングプロジェクトは色々ある。
入れるソフトウェアと登録手続きが違うだけで、インストールが終わればあとはやることに差はない。プログラムを実行して放置するだけ。
私はd.netを勧めはするけれど、RC5-72解読はもう、特にやる意義もなくなってしまったプロジェクトではある。
OGRは意義がなくなったりはしないのだけど、あまりGPGPUとか新CPUの新命令への対応など、技術的な更新が多くない。あまり面白みはないかもしれない。(RC5-72はGPGPU対応)
科学に貢献するにしても貢献する内容は他のがいいというなら、色々選べるBOINCでも、医学に早く役立ちそうなFolding@homeでも、素数でよく目立てるGIMPSでもいいわけだから、好みのプロジェクトを選べばよし。
GPGPUとかを活用したいなら、各プロジェクトの対応状況をチェック。GPGPUなら対応してるところのほうが多いと思うが、例えばd.netのRC5-72なら、GeForceよりRADEONの方がかなり強力になる傾向が以前はあったりもしたらしい。
d.netの場合、というか他のやつでもあると思うけど、参加者個人の貢献度を記録・集計するstatisticsがある。
プロジェクトが始まってから現在までの処理量、経過日数、平均処理速度などなど、毎日更新されている。
参加時にメールアドレスを登録しておくと、個人のstatisticsも見られる。
stats.distributed.net - OGR-28 Participant Summary for Mubou-an
私のOGR-28 statsはこれ。参加開始からの総計と、昨日の計算量とが、日本時間で午前10時ごろに更新される。
過去の日毎の計算量を見返すこともできる。すでに終了したプロジェクトのものも参照できる。
私はOGR-25に2002年12月24日に参加したのが最初だった。23歳のクリスマスイブをこのような地味な遊びに費やしていたことが今頃発覚。いや、2002年当時って、RC5-64解読成功で結構華やかだったけど。
2002年当時に私が使ってたPCのCPUというと、多分Celeron 850MHzか、AthlonXP 1800+か。486DX4-75MHzのPC-9821Npもちょっと投入したりしてたな。
長くやってると、こういうじじくさい振り返りもできる。
また、これはサーバーに返送された回答についての集計なので、あえてサーバーに返さず溜め込んで（設定するとできる）一気に返送し、デイリーランキングをジャックするようなことも可能。
これは参加初期から可能だから、数日溜め込んで一気に放出すれば、デイリー100位以内くらいならわりと容易にいけるよ。
どんなPCでやるべきか
さて、こんな話に興味を持つような人であればそれなりのPCを使ってることかと思うが、やっぱりこういうのに投入しないほうがよいPCもある。
d.net華やかなりし頃、会社のPCで勝手にクライアントを走らせて横領に問われた事例がある。最近の企業ではそんなことできないところが多いとは思うけれど。
あくまで私物のPCで、自宅なり電源の使用を許される場所で。
驚異的なことに、勝手にd.netクライアントを走らせるコンピューターウィルスを作って撒いた奴がいて、往時の必死さが感じられる。
おかげで、未だにd.netクライアントがセキュリティソフトに誤検知されたりするからホントろくでもない。
基本的にインターネット接続が必要なので、セキュリティに問題があるXP以前のPCは勧めにくい。まあ、オフラインでd.netの問題・結果データをやりとりして実施することは可能ではあるけれど。
また、常にCPUが、GPUも使うならGPUまでフル稼働状態になるため、放熱性能が低いPCも好ましくない。
特にモバイルPCなどでは、一般的な使用状況に対して十分な冷却、くらいで設計されているので、CPUがフル稼働し続けるというのは想定外になってしまう。
やってみて、ファンがやたらと高回転になってうるさいとか、ノートPCやタブレットなら外装まで触りづらいような熱さになるとか、そういう場合は控えたほうがいいかと思う。
経験的にいうと、ノートPCだと、外装が温かいを通り越して熱くなるのは避けたほうがよさそう。また、クーリングファンの音があまりにもうるさくなるとかそういうのも。
Ultrabookやモバイル系のもので、特にCore i系を積んでるようなハイスペックタイプは危ない感じ。
デスクトップPCなら、よほど小型のものでなければ放熱に余裕はあるように思う。
ノートでも、大型筐体のデスクノートの類なら比較的余裕があるようだ。ファンの回転が上がるのが音でわかるな、という程度。
いずれにせよ、ある程度状況がわかるまでは、自分が目の前にいて、問題があったらすぐ中止できる状態でやるべき。数時間掛けてじわじわとすごい温度まで熱くなる、なんてパターンもあるので。
家庭用のPCなんて24時間フル稼働できるように作ってない。
特に最近のPCは、省電力機能が進歩して、処理をしていない時には大幅に消費電力・発熱が減る仕様が当たり前になった。それを踏まえて、平均的な使用状況を想定して冷却系も設計するから、フル稼働を続けると冷却設計を超える発熱になりやすい。
そのかわり、オーバーヒートしそうになったら省電力機能が働き、壊れる前に温度を下げにかかるようにもなった。おかげで、オーバーヒートからそのまま焼死するような事態にはなりにくくなった。
一日で熱で壊れた、とかは、よほど酷い設計の製品でなければないと思う。
ただ、年単位の長期で見て寿命が縮むというのはある（特にモバイルノート）ので、そこは買い替えサイクルを踏まえながら判断を。
インストールと実行
ここまできて、ようやく実行方法に入るのだ。前フリが長い。
ダウンロード・インストール
公式サイトのクライアントダウンロードページから、自分のシステムに適したものをダウンロード。
64bit版Windowsを使っているなら、Windows 64bitの[AMD64]というのを選ぶ。IntelのCPUでもAMD64。
32bit版Windowsを使っているなら、Windows 32bitの[Zipped]を選ぶ。(Installerはやや古いバージョンな上、そもそもZIPを解凍して実行するだけだから別に必要ないと思う)
64bit版Windowsで、32bit版クライアントを動かすこともできるが、64bit版クライアントを使うほうが断然処理が速いので、間違えると損。
dnetc.exeにアンチウィルスソフトウェアが反応することがあるけれど、ちゃんと公式サイトからダウンロードする分には大丈夫。
Linuxの場合は、まあLinuxを使う人ならどれ使うかの判断くらいできると思うので省略。適当に選ぶがよし。
またUbuntuだったら、sudo apt install distributed-netでもインストールできた。バージョンがひとつ古かったけれど。
また、RC5-72をやる場合は、GPGPU処理をしてくれるクライアントもある。
Windows 32bitの[x86/OpenCL]が、GeForceでもRADEONでも、またIntelのHD Graphicsでも使えるクライアント。
GeForceであれば、[x86-CUDA3.1]とかを使う、といいたいところだけど、ちょっと前のバージョンで止まっている。OpenCL版でいいと思う。
CPU用クライアントとGPU用クライアント、両方同時に使うこともできるから、やる気なら両方いこう。
初回実行
ここからは、Windows版の話。Linux版はまあ、実行ファイルの呼び出し方が違うのと、コンソールアプリになってる程度の差なので、同じようにしてください。
ダウンロードしたZIPファイルを、適当なフォルダに解凍する。フォルダ内で読み書きを行うので、WindowsだとProgram Files以下にはしないほうがいい。
でもってdnetc.exeを実行すると、
distributed.net client configuration:
--------------------------------------------------------------------------
1) General Client Options
2) Buffer and Buffer Update Options
3) Performance related options
4) Logging Options
9) Discard settings and exit
0) Save settings and exit
Note: You have not yet provided a distributed.net ID. Please go to the 'General Client Options' and set it.
Choice -->
こんなのが出る。
まず書いてることを書いてるとおりに読んでその通りにするんだけど、まず 1 を選択する。キーボードで。
distributed.net client configuration: General Client Options
--------------------------------------------------------------------------
1) Your email address (distributed.net ID) ==>
2) Complete this many packets, then exit ==> 0 (no limit)
3) Run for this long, then exit ==> 0:00 (no limit)
4) Pause flagfile Path/Name ==>
5) Exit flagfile Path/Name ==> exitdnet.now
6) Enable restart on .ini file change ? ==> no
7) "Pause if running" ==>
8) Pause if running on battery power ? ==> yes
9) Run detached/disable all screen output ? (quiet mode) ==> no
10) Crunch-o-meter (progress indicator) style ==> -1 (auto-sense)
0) Return to main menu
Choice -->
そうするとこうなる。で、また 1 を選ぶ。キーボードで。
distributed.net client configuration: General Client Options
--------------------------------------------------------------------------Your email address (distributed.net ID):
Completed work sent back to distributed.net are tagged with the email address of the person whose machine completed that work. That address is used as a unique 'account' identifier in four ways :
- This is how distributed.net will contact the owner of the machine that submits the winning key.
- This is the address your participant stats page password will be sent to upon request.
- The owner of that address receives credit for completed work which may then be transferred to a team account.
- The number of work-units completed may be used as votes in the selection of a recipient of the prize-money reserved for a non-profit organization.Default Setting:
Current Setting:
New Setting -->
で、メールアドレスを登録する。
登録しておくと、statsページのユーザー情報を設定できたり、チームに参加したり、後々メアドが変更されても移行処理ができたり、もしRC5-72の正解キーを引き当てたら連絡が来て賞金がもらえたり、といったメリットがある。
これで最低限の設定は終わり。少なくともメアドだけは登録しないともったいない。
0を選んでメインメニューに戻る。
RC5-72, OGR-NGの選択
私みたいにRC5-72はやらないとか、逆にOGR-NGはやる気がない、という場合は、それを指定する。デフォルトでは両方やる。
distributed.net client configuration:
--------------------------------------------------------------------------
1) General Client Options
2) Buffer and Buffer Update Options
3) Performance related options
4) Logging Options
9) Discard settings and exit
0) Save settings and exit
Choice -->
このメインメニューで、2 を選ぶ。
distributed.net client configuration: Buffer and Buffer Update Options
--------------------------------------------------------------------------
1) Buffer in memory only ? (no disk I/O) ==> no
2) In-Buffer Filename Prefix ==> buff-in
3) Out-Buffer Filename Prefix ==> buff-out
4) Checkpoint Filename ==>
5) Disable buffer updates from/to a keyserver ==> no
6) Keyserver<->client connectivity options
7) Disable buffer updates from/to remote buffers ==> no
8) Remote buffer directory ==>
9) Load-work precedence ==> OGR-NG,RC5-72
10) Additional buffer-level checking ==> 4 (update on empty in-buffer)
11) Buffer-level check interval ==> 0:00 (on buffer change)
12) Preferred packet size (X*2^32 keys/packet) ==> RC5-72=-1
13) Fetch work threshold ==> OGR-NG=0,RC5-72=0
14) Fetch time threshold (in hours) ==> RC5-72=0
0) Return to main menu
Choice -->
ここで 9 を選ぶ。
distributed.net client configuration: Buffer and Buffer Update Options
--------------------------------------------------------------------------
Load-work precedence:
The order specified here determines the order the client will look for work each time it needs to load a packet from a buffer.
For example, "OGR-P2,RC5-72,..." instructs the client to first look for work for OGR-P2 and, if it doesn't find any, to try RC5-72 next, and so on.
You can turn off a project by setting ":0" or "=0" after the project's name - for instance, "XYZ:0" tells your client not to work on, or request work for, the XYZ project.It is possible to have the client rotate through this list, updating its buffers only once for each pass. To do so, 'Dialup-link detection' and 'Additional buffer-level checking' must be disabled since a buffer update (new work being made available) would otherwise cause the client to go back to the beginning of the load order.
Default Setting: OGR-NG,RC5-72
Current Setting: OGR-NG,RC5-72
New Setting --> OGR-NG,RC5-72
OGR-NGをやりたくないなら、OGR-NG:0と書き換える。RC5-72をやりたくないなら、RC5-72:0と書き換える。
また 0 でメインメニューに戻る。
ログの設定
せっかくだから、ログもとっておくほうが面白い。
distributed.net client configuration:
--------------------------------------------------------------------------
1) General Client Options
2) Buffer and Buffer Update Options
3) Performance related options
4) Logging Options
9) Discard settings and exit
0) Save settings and exit
Choice -->
メインメニューで、4 を選ぶ。
distributed.net client configuration: Logging Options
--------------------------------------------------------------------------
1) Log file type ==> none
2) Log by mail spool size (bytes) ==> 0 (mail disabled)
0) Return to main menu
Choice -->
1 を選ぶ。
distributed.net client configuration: Logging Options
--------------------------------------------------------------------------
Log file type:
This option determines what kind of file-based logging is preferred :
0) none altogether disables logging to file.
1) no limit the size of the file is not limited. This is the default if a limit is not specified in the "Log file limit" option.
2) restart the log will be deleted/recreated when the file size specified in the "Log file limit" option is reached.
3) fifo the oldest lines in the file will be discarded when the size of the file exceeds the limit in the "Log file limit" option.
4) rotate a new file will be created when the rotation interval specified in the "Log file limit" option is exceeded.
Default Setting: 0
Current Setting: 0
New Setting --> 0
テキストファイルがずらずら書き出されるだけのログなので、それほど巨大なログになるわけでもない。1 を選んでおけばいい。
distributed.net client configuration: Logging Options
--------------------------------------------------------------------------
1) Log file type ==> no limit
2) File to log to ==>
3) Log by mail spool size (bytes) ==> 0 (mail disabled)
0) Return to main menu
Choice -->
戻ると、項目が増えている。2 で、ログファイルのファイル名を決める。
distributed.net client configuration: Logging Options
--------------------------------------------------------------------------
File to log to:
The log file name is required for all log types except "rotate", for which it is optional.
The effective file name used for the "rotate" log file type is constructed from a unique identifier for the period (time limit) concatenated to whatever you specify here.
If the rotate interval was specified as a number of days, then the name of the log file used will be [file_or_dir_to_log_to]YYMMDD.log, where YYMMDD is the date of the first day of that 'interval'. If the interval were weekly, the name of the log file used will be [file_or_dir_to_log_to]yearweek.log
Default Setting:
Current Setting:
New Setting -->
まあ、dnetc.logとかdnetclog.txtとか、そんなファイル名付けておけばよろしい。
設定したら、また 0 でメインメニューに戻ろう。
それで、最後にメインメニューで 0) Save settings and quitを選べば設定完了。
dnetc.iniというファイルができて、設定が保存されて終了する。
実行
あとは、dnetc.exeを実行するだけ。
もしウィンドウがいきなり閉じてしまったりとか、何かエラー表示みたいなのが出ていたら、設定ミスがある。（OGR-NGもRC5-72も両方:0で無効化してたりとか）
GPGPU版クライアントだと、OpenCLやStreamが使えない状態だったりするといきなり閉じる。
ドライバーを更新するとか、Direct Xを入れてみるとか、そういうことで動き出したりすることもある。一方、動いていたのにドライバーを更新したら動かなくなったりもする。
成功していればウィンドウは閉じず、ログの最下行で進捗状況を逐次表示している状態になる。
終了
止める時は、ウィンドウを閉じればよし。途中経過はファイルに書き出されるので、また起動すると続きから再開される。
ただ、Windowsがフリーズしたとか、dnetcを強制終了したとか、そういう場合は途中経過が飛ぶので注意。Windowsを終了とか再起動するときも、一応手動でクライアントを先に閉じておくほうがいい。
実行中のその他の使い方
設定画面呼び出し
メニューから Client → Configureで、設定画面が呼び出せる。
設定漏れや、他に何か面白そうな設定がないかチェックしたいときはここから。
ベンチマーク
メニューから Client → Benchmark → All projects - all coresを選ぶ。
RC5-72・OGR-NGとも、dnetcは複数の計算手法を持っていて、coreと呼んでいる。MMXを使うとか、SSE2を使うとか、AVX2を使うとかいろいろ。
それらのすべてのcoreを実行してみて、どれくらいの処理速度かをはじき出してくれる。
新しいPCを入手したら、ベンチマークを取ってニヤニヤするのがd.net参加者のたしなみ。私が収集したベンチマークは、このページにまとめている。
注意: Restart
メニューの Client → Restartという項目は、「現在処理中の問題を最初からやりなおす」というコマンドなので、実行するとやりかけた処理がパーになる。
スループットのグラフ表示
メニューのView → Core Throughputを選ぶと、処理速度をリアルタイムにグラフ表示するモードに入る。
もとの画面に戻りたい時は、View → Console。
statsの見方
さて、毎日statsをチェックしてにやにやするのが、d.netの数少ない楽しみである。
自分のstatsをチェックするには、まず、d.netに一度結果を送信する必要がある。
dnetcを2～3日動かせば、まあ1回くらいは送信が行っていると思う。
あるいは、1時間くらいやってみたら、クライアント内に解析済みデータが溜まるので、メニューからClient → Flush Workで手動送信することもできる。
で、送信したら次の午前10時を待つ。日本時間午前10時更新。
statsサーバーにアクセスして、自分の参加しているプロジェクトを選ぶ。
で、画面上部の黒バック部分に、Participants Statsというのがあり、Searchボタンのついた入力窓がある。
ここに、dnetcに登録したメールアドレスを入力する。
ヒットすれば、自分のstatsページに飛ぶ。ブックマークしよう。
総参加者45000人のうち、アクティブユーザーは1500人そこそこ。最初のうちは気持ちよくガンガンOverall Rankが上がっていくことだろう。気持ちいいのは最初だけだ。
パスワード問い合わせと情報編集
自分のstatsページの下の方に「Please email me my password」というボタンがある。
これで、ログインパスワードが届く。
このパスワードを使って、自分のstatsページ上方にある「Edit your Information」リンクから、プロフィール編集ページにいける。
初期状態では、ランキングに表示されるユーザー名が、味気ないParticipant Numberになっているはずなので、それを変更しよう。
List Modeの欄を、Let me using my real name.にする。
Real nameっていわれると引くものがあるけど、下の方にReal nameの入力欄があるので、ここに好きに入力すべし。無論実名でなくていい。多分日本語は使えないと思うので、英数字で。
また、Motto欄に自己アピールを書いておいてもよい。statsを見せびらかす時に役立つ。英数字でな。
それから、下の方のCountry CodeはJapanにしておくといいかも。あまり目立たないけど、国別集計もやってるので。日本人67名か……
一通り編集したら、下の方のUpdate my informationボタンを忘れずクリック。最近のウェブサービスみたいに逐次保存されたりしないぞ。
チーム
参加者が複数集まって、チームを結成する機能もある。
のだが、日本に67人しかいない参加者を私は他に知らんので、私はソロでやっている。
多分、今でも稼働している日本人チームも、数えるほどしかないと思う。20年近く前から続く歴史あるチームもあるのだけど……
まあ、もしこのクソ長い記事をここまで読んだ奇特な人の中で、さらにd.netに参加してみようと今頃思った時流を読めない人がいて、その上でチームに参加してみたいと思うような奇人があるのであれば、私がチームを開いてやらんでもないので、コメント欄にでも連絡するように。
参加し始めたら
ここまで長い長い話の末、ついにd.netに参加することに成功したら、あとは特にすることはない。ただ続けよう。PC壊さない程度に。
放置系っていうレベルじゃねえぞというスローペースで、数年に一度、「OGRが発見できましたー」というアナウンスがくる。
まあ、今のペースだとあと3000日かかるっぽいから、相当先は長いが。その3000日を縮めるのはキミだ！
「RC5-72を解読しましたー」は、これはもっと先まで来そうにない。ただまあ、総当りのどこであたりを引くかはわからないので、明日ぽろっと見つかる可能性もありはするけど。
参加中によくあるトラブルは、Windowsを再起動したらそのままクライアントを立ち上げ忘れること。
まあスタートアップに入れちゃってもいいんだけど、それは、連日ずっと使用中にCPUがフル稼働しても問題ないとわかってからで。
発熱問題についても、今みたいな冬場なら十分冷却できても、夏になると厳しくなったりすることもある。
そういう場合は、夏場はやめて冬場だけやるようにしてもよし。私もノートは夏場はやらない。単純に手元が暑苦しい。
まあ、こんな記事をここまで読むような忍耐力がある人には向いてると思うので、さあ、インストールして走らせよう。
