| 月 | 旧称 | 中期（グレゴリオ暦） | 由来 | |
| １ | 睦月 mutsuki | 雨水 | 2月19日頃 | 年始で家族睦んで睦月、初めの月で元つ月が訛ったもの、春を前にして萌月など |
| ２ | 如月 kisaragi | 春分 | 3月21日頃 | 如月は当て字、中国の二月をそのまま当てたもので日本語の“きさらぎ”とは関係無し。衣替えの季節で衣更着、発芽の季節で草木張月など |
| ３ | 弥生 yayoi | 穀雨 | 4月20日頃 | 木草弥や（いよいよ）生ひ月で弥生 |
| ４ | 卯月 utsuki | 小満 | 5月21日頃 | 卯の花の咲く月で卯月、田植えの季節で植月など |
| ５ | 皐月 satsuki | 夏至 | 6月22日頃 | 苗を植える季節で早苗月。新暦（グレゴリオ暦）での梅雨はこっち。古書では五月と書いてさつき |
| ６ | 水無月 minaduki | 大暑 | 7月23日頃 | 梅雨が明けて（水が無くなって）水無月、もしくは田に水を張る季節で水月（無は当て字）など |
| ７ | 文月 fumitsuki | 処暑 | 8月24日頃 | 七夕で文字を書くから文月と言われるが七夕は中国より奈良時代に伝わったものなので、稲穂が含（ふ）む月で文月との説も |
| ８ | 葉月 haduki | 秋分 | 9月23日頃 | 紅葉の季節で葉月、稲穂が張る季節で穂張り月など |
| ９ | 長月 nagatsuki | 霜降 | 10月24日頃 | 童謡にもあるように秋の夜長の夜長月で長月 |
| １０ | 神無月 kannnaduki | 小雪 | 11月23日頃 | 新嘗の季節で醸成（かみなり）月、神嘗月、台風の季節の後で雷無月など |
| １１ | 霜月 shimotsuki | 冬至 | 12月22日頃 | 霜が降りる季節で霜月 |
| １２ | 師走 siwasu | 大寒 | 1月20日頃 | 師（僧）が仏事で走り回るから師走。年果てる、し果つ、など |
| 月 | 名前/Name | 由来/Source |
| １ | January | 時の神ヤヌスの月 Month of Janus as God of Time |
| ２ | February | 浄罪の月 Month of Cleaning Sin |
| ３ | March | 戦神マルスの月 Month of Martius as War God |
| ４ | April | 愛と美と豊穣の女神ヴィーナスの月 Month of Vinus as Goddess of Love, buety and fertility |
| ５ | May | 豊穣を司る地母神マイアの月 Month of Maius as Land Goddess for fertility |
| ６ | June | 結婚の女神ジュノーの月 Month of Junius as Goddress of Marrage |
| ７ | July | ジュリアス・カエサルの月 Month of Gaius Julius Caesar |
| ８ | August | 初代ローマ皇帝アウグストゥスの月 Month of Augustus as the first Roman emperor |
| ９ | September | 第7の月 7th month |
| １０ | October | 第8の月 9th month |
| １１ | November | 第9の月 9th month |
| １２ | December | 第10の月 10th month |
スカルプトとGPU性能の兼ね合いをどうするか考えながら放置していたのを“超”久々に再開。| Blender Net Renderの現状の問題と対策 |
| →いつものひどい英語判/Terrible English version as always |
| →コード修正箇所 |
BlenderのNetRender add-onはユーザー設定画面で見て判る通り、ベータ版となっているが、現時点では以下の問題があると思われる (1)大きなファイル、もしくは大量の外部ファイルを含むデータのレンダリングではクライアントがエラーを起こしやすい (2)フレーム当たりのレンダリングが長時間かかる場合はエラーになる (3)Force upload all filesを指定してもリンクデータの参照に失敗する (3)の対策は、将来対応されることを期待しつつ、全てのスレイブサーバーにクライアントと同じパスで各データを参照出来るように設定しておくことで対処するとして、(1)(2)は実はタイムアウトの判定の方法に問題がある。 (2)に関しては、実際には通信用モジュールがタイムアウトを起こしているのではなく、応答間隔が長かった場合、つまり前回の通信から今回の通信までの間隔が一定以上であればエラーを発生させている、もしくは該当スレイブをジョブの対象リストから除外すると言う作業を行っている。 つまり、通信が出来ないためにタイムアウトを起こしている訳ではなく、処理の遅いサーバーをメンバーから外すと言う処理を行っている。 但し、このタイムアウトにする閾値が固定で与えられているため、例えば、閾値が30分であれば、1フレームの処理に最速のサーバーで1時間掛かる場合には100％失敗となる。 現時点、この閾値は5分になっている。 CGWORLD誌でトランスフォーマーのレンダリング時間が（最長？）1フレーム70時間と紹介されていたようだが、勿論、お話にならない。 そして、この対策だが、マスターのソースコードのタイムアウト時間を与えている箇所を修正する。 実際のソースコード上でもコメントで、UIで変更出来るようにしなければならないと言う旨が書かれている。 但し、この対策法、問題が無い訳ではない。 ジョブをキャンセルした場合も、次のジョブを受け入れるまでこの時間待つようになる。 つまり、レンダリング、1フレーム当たり1時間のジョブを実行出来るようにすると、ジョブをキャンセルした場合に次のジョブを受け入れるまでに1時間掛かる。 生存通知の有無によるタイムアウトと、処理が遅いことによるタイムアウトを区別していないために起こる仕様上の問題だが、ここを変更して対応時間を伸ばすと、ジョブをキャンセルして新しいジョブを投入する場合には手動でスレイブを再起動する必要がある。 クライアントのタイムアウトも固定で5秒タイムアウトするようになっている。 現状パイソンはマルチコアに対応していないし、コード自体も並行処理で生存通知を行うようになっていないので、データサイズが大きかったり回線が遅くて転送時間が長くなると、タイムアウトする。 クライアントがタイムアウトすると、 (1)データの転送が正常に終了したか判らない の2点が問題となるが、LAN内やFTTH環境下ではほぼ起こらない上、(2)はウェブUIかクライアントのボタンからダウンロード出来るので、問題としてはさほど大きく無い。(2)マスターからレンダリング済データをダウンロード出来ない |
| The problem of Blender NetRender and the countermeasure against it |
| →Python Code |
Blender NetRender is Beta version as you can know from user preference, then I think that it has these problem following here. (1)The error often happen on client when sending the large sized file or the data having many linked files. (2)It can't render the data that its render need many time for 1 frame rendering. (3)It failure to refer linked files even if ordering the option "Force upload all files". About (3), we expect to be resolved in future, and then we make slave servers to be able to refer data directories with same path as client's. About (1)(2), it has the problem in the way to decide timeout. In (2)'s problem, it is not that the communication module is not in timeout, but it occur when current response arrive after spending many time from last response, so it is not that there is not response. So if the time spans were long, the master would cut off those slaves as low performance machine. However, this thresholds are fixed in current code. For example, if you rendered such data as to spend 1 hour also with the most performance machine and if the threshold were 30 minutes, that job should lose certainly. In current code, it was set to 5 minutes. Before there was the article about Transformer TV animation in CGWORLD( a magazine in Japan ), it said that its rendering needed 7 hours / frame (it is the longest time of them?), so such is nothing but joke in current Blender NetRender. The way against that problem, you must change python code ( the comment to need to make it adjustable by UI is written in the code, but yet ). But this countermeasure has also problem. If you enlarge the length until timeout, also the wait time for next job is enlarged. So if you set 1 hour for timeout, the NetRender could process the task that needed 1 hour, but if you cancelled that job, the slaves would not receive next job for 1 hour. It is because of bug in the specification, the timeout against impossible to communicate and the timeout against low speed machine are not distinguished. But that is why we must restart slaves with handle when when we cancel job ( or wait for that time ). In client, there is the problem that the timeout length is given as fixed parameter, and it is 5 seconds. That is why it finish with error if it need many time for sending by its data size or the network through put, becaise current python don't support multi-core and this program can't send survival signal while sending. If client goes to timeout,the problems are these. (1)We can't know whether the sending have finished or not. The problem of (1) rarely happen in LAN or FTTH, and (2) is not so serious because we can download the result from master with web UI or client's get button.(2)Client can't download the rendered results from master automatically. |
| Directory | ./2.66/scripts/add-ons/netrender | |||
| File | master.py | utils.py | ||
| Befoer | 984 line | self.slave_timeout = 5 # 5 mins: need a parameter for that | 162 line | def clientConnection(netsettings, report = None, scan = True, timeout = 5): |
| After | self.slave_timeout = 60 # 5 mins: need a parameter for that | def clientConnection(netsettings, report = None, scan = True, timeout = 120): | ||
