2018/02/19

UR242を買った

ずっとM-AudioのFirewire1814を使い続けていたのですが、IEEE1394のカードが変な動きしかしないのでUSB-Audioに変えてみました。
そして、せっかくだからとRMAAをやったら10年使い続けているFireWire1814の方が性能が良い(SN比:約2倍、thd,クロストーク:10倍)ということが分かって「・・・」となった今日この頃です。唯一周波数だけは192kHzに対応していますが、96kHzでも十分です。
そして、1814を再インストールしてみたら以前の挙動(スリープ・休止に入れない)がなんか治ってるような気が・・・
実は1814ではなく、一緒に変えたNIC(オンボード)が微妙なWOLな挙動になっていたということなのか。

あと、元々OSミキサーを介さずに(DirectSoundのミキサーが糞で、F.S.の出力すると波高値に達したサンプルだけ3dB位??落とされるらしい )いろいろやりたいということで、
・OS等のDirectSound系はS/W1,2ch出力
・foobarからASIOでS/W3,4chに出力
をH/Wミキサーを介してH/W1,2chから出力していたのですが、UR242ではそういった使い方はできないみたいです。

ということで、UR242はノートPC(ほぼ艦これ専用マシン これも10年選手)からの出力用になってしまいました。
そういう使い方をするならバスパワー駆動するUR22の方が良いのですがね。

2018/02/18

使い分け

気持ちを伝えたいのか、考えを伝えたいのかれるような気がします。
というか別に感情を伝えたいことがないので、僕にはSNS系の双方向さは必要ないな、と思った今日この頃。

あと、LINEとメールの違いは仕組み上、LINEはデータを「見に行く」のに対し、メールは手元のデータを見る、というところで違います。
imap等では(ローカルにも保存できますが)サーバ上にデータを置いてあるためその観点では微妙なところですが、「こちら側」のサーバにおいてあるものと、間借りしているだけの掲示板では情報の確実度が違います。
要は信用していない、というだけですが。

とか言いながらスマホを買ったら使うんでしょうね。

2018/02/03

[外: MD5Str ]って表示されるのって鬱陶しくないですか?

というわけで、iGlitchさんのCaption2Ass_C5を参考にPCRのソースをコメントアウトしてmod。
じゃぁC5を使えよ、という話もありますが、まぁビルドできたんでいいや。
makiさんのPCRのビルドはそのまま開いてビルドするだけなので簡単ですし。

いや、本当は設定で切り替えられるようにした方が良いんでしょうが・・・

2018/01/30

4k対応で変わるらしい

NHK BS1などBS放送の解像度が横1,440ドットに。新4K/8K放送に向け帯域削減
ある日突然ロゴ判定ができなくなりました。
何事・・??と調べた結果、いつの間にかBS放送の解像度が変更されていたとのこと。
・・・まじか

2018/01/27

10GbEを確認する際にWindows上でのiperf3は気にしない方が良い?

先日買った10Gbセット(NIC+HUB)が届いたので早速インストール。
早速ベンチを・・・とったらiperf3で4Gb位しか出ない。
???
ということで、確認中

試したこと:
・iperf3.1.3を32/64bit両方でやってみる
→大した変化なし
・TCPOptimizer4でoptimizeしてみる
→大した効果なし
・driverでjumboframeや割り込み加減率を変えてみる
→大した効果なし
・iperfのオプションを-M,-l,-wとかいろいろ弄ってみる
→大した効果なし
・電源設定をハイパフォーマンスにしてみる
→大した効果なし
・iperfで-P4とかしてみる
→全部で7Gbpsぐらいまでは増えるが・・・
・iperf -c localhostでそもそもの帯域を確認してみる
→Win2008R2鯖で10Gbps、Win10で5Gbps程度!?意味が分からん
・Windows10のクリーンインストール
→結果変わらず
・同じマシンにUbuntsu(物理)をインストールしていろいろ確認
-ubuntsu(物理)からdebian(Win鯖のHyper-V上)へのiperf:これ位出ればいいよね(リトライが気になるけど)
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-30.00 sec 28.9 GBytes 8.28 Gbits/sec 1884 sender
[ 4] 0.00-30.00 sec 28.9 GBytes 8.28 Gbits/sec receiver
CPU Utilization: local/sender 17.2% (0.4%u/16.8%s), remote/receiver 9.1% (0.7%u/8.4%s)
-debian(Win鯖のHyper-V上)からubuntsu(物理)へのiperf:なんか遅くね?
[ 4] 0.00-30.00 sec 13.1 GBytes 3.75 Gbits/sec 36 sender
[ 4] 0.00-30.00 sec 13.1 GBytes 3.75 Gbits/sec receiver
CPU Utilization: local/receiver 14.8% (0.8%u/14.0%s), remote/sender 1.5% (0.1%u/1.4%s)
-ubuntsu(物理)からWin鯖(ホスト)へのiperf:まぁ許容範囲
[ 4] 0.00-30.00 sec 25.5 GBytes 7.30 Gbits/sec 0 sender
[ 4] 0.00-30.00 sec 25.5 GBytes 7.30 Gbits/sec receiver
CPU Utilization: local/sender 17.1% (0.9%u/16.2%s), remote/receiver 2.3% (0.4%u/1.8%s)
-Win鯖(ホスト)からubuntsu(物理)へのiperf:これくらい出ればよいのに
[ 4] 0.00-30.00 sec 29.1 GBytes 8.32 Gbits/sec sender
[ 4] 0.00-30.00 sec 29.1 GBytes 8.32 Gbits/sec receiver
CPU Utilization: local/receiver 28.9% (1.3%u/27.5%s), remote/sender 33.7% (8.0%u/25.7%s)
-Win10(物理)からWin鯖(ホスト)へのiperf:いや、おかしいって
[ 4] 0.00-30.00 sec 12.9 GBytes 3.69 Gbits/sec sender
[ 4] 0.00-30.00 sec 12.9 GBytes 3.69 Gbits/sec receiver
CPU Utilization: local/sender 33.6% (2.8%u/30.8%s), remote/receiver 7.0% (1.7%u/5.3%s)
-Win鯖(ホスト)からWin10(物理):だからおかしいって
[ 4] 0.00-30.00 sec 16.1 GBytes 4.61 Gbits/sec sender
[ 4] 0.00-30.00 sec 16.1 GBytes 4.61 Gbits/sec receiver
CPU Utilization: local/receiver 81.0% (25.3%u/55.7%s), remote/sender 23.5% (5.9%u/17.6%s)
→Windows同士のiperfが有意に遅い
→Windowsからの送信時、CPUを異様に占有している

・Win同士でファイルコピーしてみる
→500~600MB/s程度(ローカルでの読み書きMAX)は出るから実質問題はない

結論:Windows上のiperf3は信用してはいけない、もしくは何か(バイナリか環境か)おかしいのでは?
実使用上問題ないし、H/Wに問題があるわけでもなさそうなので、気にしない(見なかったこと)ことにしよう!

それにしても、最近のOSインストールはとても楽になりましたね。
「試しに」クリーンインストールするのが1Hrも待たずに済みます。

2018/01/20

10GbEtherの時代

冬休みの間に10GEtherっていいよね、とか、でもHUBにちょうどいいのがないな、とか思っていたのです。
2016~7年に普及期に入ったといわれているとはいえ、5portsHUBが50kはちと高いのでは?。
で、Netgearの新製品情報を見たら10,5,2.5,1G×2ports、1G×8portsのちょうど良いのが1/10に出ていました。
外部電源というのがちょっと気になりますが、ファンレスですしまぁ、仕方がないでしょう。
NETGEAR『GS110MX』と『GS110EMX』を発売開始
元々の想定用途はサーバとメインマシン間だけ10G(もしくは5G以上)でつなげないかな、というところなので、まさにピッタリのスペック。
というわけでポチってしまった今日この頃。

ついでにNICも買わねばならんので、X550かX540かどちらにしよう、と悩んでみましたが、結局
・X550はマルチギガに対応してる
・X550はPCIe3.0×4で、X540は2.1×8
・X550は13WでX540は18W?(どこで見たか記憶が定かではない・・・)
位しか違いがありません。
x4かx8かはもともと3.0x8のポートを使っていますし、10GHubを使うのでマルチギガかどうかも関係ありません。
というわけでX540でいいや。そっちの方が安いし。

IntelNICは偽物が良く流通している、と言われています。(今もそうなのかどうか知りませんが)
で、Amazonでいかにも怪しい?(一応IntelのX1とかの想定価格が$350~、チップ単体で$120とか$140位なので、別に20kでもそんな変ではないという話も)のがたくさんあったのですが、その中で10Gtekという出品者がいました。

中国のちゃんとした会社らしく、Intel NICではなく、Intelチップ搭載品、と唄って実際にパッケージにも10Gtekと書いている様子。
かねてから偽物ではなく、自分たちのブランドで商売してほしいと思っていたのでこれはこれは、ということで購入。

そしていろいろ調べていたら驚愕の事実が・・・
なんと!メインマシンまではCat6Aでつないでいるものの、サーバまでがCat5Eだった!
いや、3m位だから何とかなるかもしれませんが、せっかくなのでCat6か6Aかのを買わねば。(本当は6Aまで要らないんですけどね)
・・・ってよくよく確認したら1/4本だけCAT6のケーブルが入ってた。
ってか、CAT6の開封されていない袋があった。
どうも昔、変えようとしたものの必要性がないので面倒になってCAT5Eのままにしたっぽい。

2018/01/12

githubが死んだ

もういない!

いや、何があったのか知りませんが・・・
昨日からエラーが増え始め、いつの間にやら死んでたらしいです。
すぐ戻りましたが。

僕はあまり困りませんが、困る人も多いのかもしれません。

https://status.github.com/messages/2018-01-11

2018/01/02

265を試そう

もうそろそろx265を試してみてもいいかもしれない、と思い始めたので試してみました。

ほぼx264互換だろ、とか思ってたらいろんなところにはまったのでメモ。
・--demuxerオプションがなくなって、--y4mに変わってたってか入力がYUVかY4Mしかない
→オプションを変えるだけ

・mp4出力に対応していない
→mp4という拡張子を付けても出来上がるのは.h265なので、mp4boxで取り込む

・--tcfileinに対応しない(raw出力だし)
→仕方がないのでtc2mp4とかを使ってmp4boxでのインポート時にタイムコードを付加(予定)

・使ってたmp4boxが(古いから)hevc/h265に対応していない
→新しいのを使う

・新しい(0.70)mp4boxに放り込んだら大量に「Error parsing slice header: byte_align not found at end of header !」と言われる
→https://github.com/gpac/gpac/issues/801によるとrev3以降ではで治ったらしい。ってかgpacのdlページにある070rev0は安定最新版ではないのか・・・仕方がないので0.72DEV最新版(rev357)にする

・mp4boxを0.72DEVにしたら、最近(ここ5年ぐらい?)のmp4boxは既存ファイルを上書きしないようになってる(から昔のを使い続けていたのですが)のが、いつの間にか治っていたと喜ぶ
mp4boxからunicodeで吐かれてたファイル名がちゃんと表示されるようになったのを鑑みると、ようやくunicode絡みのfilehandlingが治ったのでは?という想像(変更履歴とか確認してません)
と、思ったところ、I/O errorは出なくなったけど、代わりに-outオプションを受け付けなくなっている・・・?もしくはsjisで入力するのがいけないのかもしれませんが。
あとcmdの標準出力の変数を弄っているのかなんかで、mp4boxを使った後のコンソールで日本語がおかしくなる。
具体的には
echo "%SOURCE%.h265" >>"%LOGFILE%"
%mp4box% -add "%SOURCE%.h265" "%SOURCE%.mp4"
echo "%SOURCE%.h265" >>"%LOGFILE%"
というコマンドを実行すると、mp4boxの後のechoでは%SOURCE%から吐き出される2byte文字が化ける(おそらくutf8を吐いてる)
chcpをしても932と帰ってくるのに、chcp 932と打ちなおすと治る
→捜したところ、videohelpに0.70.rev27があったので、それを使えばいいんじゃね?結局unicode絡みのは治ってないけど。

2017/12/29

クリアカード

日本引きこもり協会がまた作ってくれるようです。

丹下さんや岩男さんなどのキャストは大体そのままで、とても懐かしい感じが・・・
制作もマッドハウスで、監督・脚本は昔のままですが、キャラデザはさすがに違うようです。
高橋さんや藤田さんよりも原作側に寄せてきていますね。
今の技術で作ってくれるのはありがたいことです。

一番の懸念は日朝のため時刻テロップが入るような気がすること・・・金曜に再放送するのでそちらが保存用でしょうか。

楽しみにしています。

というわけで適当になっていたBSP用の設定を煮詰めなければならないということが判明。
ふむふむ・・・いや、全部手動設定でも良いのですが。

ちなみに、PVは知世編が好きです。

2017/12/03

ちゅーぶレス


某英国の通販サイトで安売りしていたPrimeのRR-50を買ってみました。
チューブレスのタイヤを嵌めたことがない(完成車付属のSLR-1はチューブレスなのですが、パンクしたことがないのでお店で買ったまま)ので、試したいというのと、鈴鹿でやっぱりCC40Eはすごいな、と思ったので50mmだとどうなるんだろう、というよくわからない妄想に取りつかれたためです。(単純にリムハイトだけではないのはわかってますが(w)
本当はRP-50が良かったのですが、目立たない黒色は28kも値段に差があった(白なら15k)ので、スポークがcx-rayになるだけ?にそこまでかけられんな、と。
(一応ハブも変わるのですが、ストレートプルにするために違うだけで、ベアリング部は多分変わらないんではないかという妄想)
スポークの違いで剛性が、とかもあるんでしょうが、僕的には巡行時を楽にする、というホイールでガシガシ踏んだ時のフィーリングをどうのというのもナンセンスです。

とりあえず重量を測定・・・720g+900g=1620gで、カタログ値の1560gに比べると各+30g位。リムテープの分?

2017/11/30

今回は温くいきます

E3 戦力ゲージ1発目で照月Dropして、輸送ゲージ4回目で春日丸が来たので、をぉ、これは幸先良いな、とか思ったらその後さっぱり。
一方で何故か瑞鳳が5隻も・・・
E3輸送ゲージ丙堀
加賀、愛宕、利根、春日丸、蒼龍、高波、長波、松輪、金剛、萩風、
長波、高雄、嵐、霧島、萩風、瑞鳳、瑞鳳、高波、蒼龍、国後、
矢矧、能代、最上、扶桑、日向、瑞鳳、長波、嵐、愛宕、榛名、
山城、扶桑、飛鷹、金剛、金剛、扶桑、伊400
まぁ、50回もかからず来てくれたので良かったです。
今回は欲しいものがないのでこのままE3も丙でクリアしてしまいましょう。

E4は乙ですかね。

2017/11/24

3時間過ぎてからがつらい

4Hrの平均出力は今までとあまり変わらず、146Wでした。

前の記録によると180W程出せば9min前半が出ていたのですが、今回は同じ出力で10min前半。

4時間平均出力は変わらないのに、今回は風が強かったためか、10minを切ることなく、寒くて水分補給をしていなかったのがいけないのか3時間を経過してから出力が全くでなくなるという。あと腰とお尻が痛い。
まぁ、風速7m/sとかだったので仕方がないでしょう。

そしてやっぱり寒かったようで指ぬきグローブでは後半手が動かずに変速に苦労するという・・・
いや、電動でよかったです。

2017/11/11

いろいろ新しくしたら速くなってきた

MPEG2DecPlusとUnsharpHQを新しくして、dfttestのdither_Cをもうちょっとチューニングしたら
MPEG2DecPlus_MPEG2Source(vsource,idct=4)
TDout =ScriptName+"_TDmetrics2.txt"
TFMout =ScriptName+"_TFMout2.txt"
TFM(mode=1,order=-1,PP=1,slow=2,input=TFMout,batch=true)
TDecimate(mode=1,tfmIn=TFMout,input=TDout,batch=true)
FluxSmoothT(temporal_threshold=3)
Spline144Resize(resizex,resizey)
block=32
dfttest(ftype=0,f0beta=1,sigma=4,sbsize=block,sosize=block/2,smode=1,swin=0,tbsize=1,tmode=0,twin=7,dither=1,opt=0)
unsharpHQ_v05_x86_unsharpHQ(SHARPSTR=2.4,THRESHOLD=40,SMOOTH=0) #unsharpHQ(STR=1.0)
というスクリプト(リサイズは1440x1080→1280x720)で28fps程度出るようになりました。(i7-4790@4.5GHz)
最適化対象はAVXで、AVX2用(FMA3を使う)にするともうちょっと(0.5%位?)早くなります。

何にせよ、ようやく実エンコード環境(x264と同時に走らせて)で24fpsを超えることができました(24.5fps)。
事前にTIVTCのhintsを求めてるため、本当のリアルタイムエンコードはできませんが(というかもっと時間がかかりますが)、

・・・あれ?
svml_dispmd.dllが見つかりませんとか言われる・・

確認していったら新しくしたNNEDI3_v0_9_4_47のnnedi3.dllがリンクしてるっぽい。
ってかintelってintelコンパイラか・・・
というわけでNNEDI3のノーマル版を入れたら治りました。
(ちゃんとreadmeに書いてあった・・・
Get Intel Parallel Studio 2017 redistribuables to use Intel versions.
https://software.intel.com/en-us/articles/intelr-composer-redistributable-libraries-by-version)

ついでにFluxSmoothを速くできるんじゃね?と思って探したらSSE化している人がいた!
・・・と思ったけど、x64専用になってる・・・
xmmも8以降がまんべんなく使われていて単純に32bit化するのは面倒そう・・・
いや、そもそも全部64bit化すればいいのか?とか悩みちゅう。


作ったdfttestはバグがありそうですし例によってバイナリ配布とかは面倒なので適当にdfttest.cのdiffから作ってください・・・↓

2017/11/04

・・・34Tって心惹かれませんか

【R8000】 カセットスプロケットの歯数構成ニーズの移り変わり 【11-34T】

先日、大弛峠へ行ってきました。
国内では数少ないいわゆる「超級」に匹敵する上りで、30km延々と上りが続き、獲得標高が1800mという。

10月ほとんど外に出ていないせいか、最後の7km、500mを上るのが大変で、39min平均で168bpm、162W 66rpmという・・・
それまでに足を使ってるというのもありますが、6月には86min平均で189W 177bpm 82rpmだったのに、出せる出力が15%以上下がってます。


これではいけない、と考えたのかわかりませんが、RD変えるのっていよね、とか思い始めました。
そして8050には34Tがあるんです。

そもそもずっと50-34のコンパクトクランクだったのが去年自転車を変えてから、52-36と5%大きくなってるんですよ。
リア最大歯数はRD-8050のSSで25-30T、GSは28-34Tまで。
GSにする場合25Tに対応していないと公式は言うわけですが、変速が多少おかしくてもいいのであれば別にGSでいいんじゃね?とか思っている今日この頃。
う~む・・・

ついでに、11-34ってなんか微妙じゃないですか?
そもそも52-14Tでも100rpmで回せば49kmphなので、ヒルクライム仕様なら14-34Tとかにしてほしいもの。

僕は28-35km、85rpm位?で巡行することが多いと考えると17-21Tがクローズレシオになっていると良いんです。
そう考えると14-28T一択・・・ん?インナー使えばよくね?

まぁ、「変態スプロケット」でググるといろいろ出てくるわけで、そんな先達を参考にしながら何か作ってしまうかもしれません・・・
CS-R8000の構成は以下
11-12-13-14-15-16|17-19|21-23-25T
12-13-14-15-16-17|18-19|21-23-25T
11-12-13-14-15-17|19-21|23-25-28T
14-15-16-17-18-19|20-21|23-25-28T
11-12-13-14-15-17|19-21|24-27-30T
11-12-13-14-16-18|20-22|25-28-32T
11-13-15-17-19|21-23-25|27-30-34T
刻印とかディーラーマニュアルとか見ると、歯数だけではなく、本当はより細かい違いがあるのですが、そこまで変則性能を気にしなければ何とかなるでしょう。

富士スバルラインなら36-28のギア比1.3倍で80rpm程度でしたし普段乗る分には28Tあれば十分なんですが・・・いや、もう1~2段軽いのがあると確かにより良い気も
という意味であればヒルクライムレースの時はどうせ使わない小さいギアはむしろ錘にならないように小さいままで11-34Tで良いか。

・・・つまり、普段は14-28、レースの時は11-34Tでよいという結論に。
ってなるとレースのためだけにGSにするのもな、と思ってしまいますね。

2017/10/31

・・・個人的に買ってしまおうか

モータ制御評価キット

36k・・・
悩ましいところです。
プログラム作って書き込むにはE1エミュレータも必要らしいので+20k
・・・まぁ、別に会社でやればいいか。
引退して暇になったら買ってみましょう。

2017/10/29

mp4a 40と67の違い

ローカルで作成したmp4ファイルをFirefoxにドロップしたときに、音が再生できるものと再生できないものがあります。
何が違うのやら、と思っていたら、なんとなく
mp4a.67(MPEG2-AAC)とmp4a.40(MPEG4-AAC)の違いではないかと・・・

どうも環境によってはMPEG2-AACを入れたコンテナを再生してくれないっぽいです。
androidのchromeは問題なかったのですが、どうやらfirefoxだけではなく、iphoneもダメな模様。

MPEG2-AACにいくつか機能追加したのがMPEG4-AACらしいのですが、なんで再生してくれないのか・・。
基本的なアルゴリズム自体に違いはなく、追加技術を使用しなければヘッダの一部分が1ビット異なるだけ

・・・むしろ、ヘッダだけ書き換えてみればよいのか?

というわけでaac→m4a変換時にmp4boxで:mpeg4とオプションを付けてみたらfirefoxでも音声が再生されるようになりました。
めでたしめでたし。

Hyper-Vとdebianとntp

・・・確かに、大昔に設定したっきり確認していなかったのも悪かったですが

最近のdebianカーネルにはhyper-v用のLISが入っているのですが、そこにtimesyncなるものが入っています。
というか、多分wheezyとかetchのころからいろいろ入り始めたのですが、既に設定済みで問題なく動いていたntpとかあまり確認していませんでした。

で。
hyper-vにはゲストとホストの時刻を同期してくれる機能があります。
なので、ゲスト側でntpで時刻を合わせようとしてもホスト側から強制的に上書きされる、という現象が・・・

なんかntpq -pをするとオフセット(600ms程)があるな~と思っていたらこいつか!
というわけでゲストでntpを設定するならhyper-vのVM設定で時刻の同期を外した方が良いと思われます。

元々はntp poolでちゃんと同期できてないなぁとか思って調べていたらpoolは関係ない罠

→hyper-vの設定で外してもダメっぽく、すぐに同期が外れます。
結局VMでの時間管理という本質的な問題になってくるのかもしれませんね
→数日放っておいたら同期するようになってきました。
・・・よくわからん

2017/10/26

犯人はこの中にいる!

Oct 25 12:55:17 debian kernel: [49542.112087] INFO: task apache2:18885 blocked for more than 120 seconds.
Oct 25 12:55:17 debian kernel: [49542.112100] Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
Oct 25 12:55:17 debian kernel: [49542.112108] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 25 12:55:17 debian kernel: [49542.112118] apache2 D 0 18885 1517 0x20020000
Oct 25 12:55:17 debian kernel: [49542.112121] ffff96fbf7bdfc00 0000000000000000 ffff96fbfbba00c0 ffff96fbfc618240
Oct 25 12:55:17 debian kernel: [49542.112122] ffffffff9120e500 ffffb7cf85597888 ffffffff90c038e3 ffff96fbfbb66c00
Oct 25 12:55:17 debian kernel: [49542.112123] 00ffffff906a9865 ffff96fbfc618240 ffff96fbf80d3140 ffff96fbfbba00c0
Oct 25 12:55:17 debian kernel: [49542.112125] Call Trace:
Oct 25 12:55:17 debian kernel: [49542.112128] [] ? __schedule+0x233/0x6d0
Oct 25 12:55:17 debian kernel: [49542.112130] [] ? schedule+0x32/0x80
Oct 25 12:55:17 debian kernel: [49542.112131] [] ? schedule_preempt_disabled+0xa/0x10
Oct 25 12:55:17 debian kernel: [49542.112132] [] ? __mutex_lock_slowpath+0xb4/0x130
Oct 25 12:55:17 debian kernel: [49542.112134] [] ? mutex_lock+0x1b/0x30
Oct 25 12:55:17 debian kernel: [49542.112146] [] ? cifs_reconnect_tcon+0x8f/0x320 [cifs]
Oct 25 12:55:17 debian kernel: [49542.112152] [] ? smb_init+0x27/0x80 [cifs]
Oct 25 12:55:17 debian kernel: [49542.112158] [] ? CIFSSMBQPathInfo+0x66/0x310 [cifs]
Oct 25 12:55:17 debian kernel: [49542.112166] [] ? cifs_query_path_info+0x6c/0x180 [cifs]
Oct 25 12:55:17 debian kernel: [49542.112167] [] ? schedule_hrtimeout_range_clock+0xc5/0x1a0
Oct 25 12:55:17 debian kernel: [49542.112168] [] ? list_del+0x9/0x30
Oct 25 12:55:17 debian kernel: [49542.112169] [] ? remove_wait_queue+0x20/0x30
Oct 25 12:55:17 debian kernel: [49542.112170] [] ? poll_freewait+0x45/0xa0
Oct 25 12:55:17 debian kernel: [49542.112177] [] ? cifs_get_inode_info+0x402/0x920 [cifs]
Oct 25 12:55:17 debian kernel: [49542.112184] [] ? build_path_from_dentry+0xeb/0x3f0 [cifs]
Oct 25 12:55:17 debian kernel: [49542.112190] [] ? build_path_from_dentry+0x15e/0x3f0 [cifs]
Oct 25 12:55:17 debian kernel: [49542.112197] [] ? cifs_revalidate_dentry_attr+0x1d3/0x250 [cifs]
Oct 25 12:55:17 debian kernel: [49542.112203] [] ? cifs_revalidate_dentry+0xf/0x20 [cifs]
Oct 25 12:55:17 debian kernel: [49542.112209] [] ? cifs_d_revalidate+0x1e/0xa0 [cifs]
Oct 25 12:55:17 debian kernel: [49542.112211] [] ? lookup_fast+0x2bd/0x2e0
Oct 25 12:55:17 debian kernel: [49542.112212] [] ? walk_component+0x44/0x320
Oct 25 12:55:17 debian kernel: [49542.112213] [] ? path_lookupat+0x67/0x120
Oct 25 12:55:17 debian kernel: [49542.112214] [] ? filename_lookup+0xb1/0x180
Oct 25 12:55:17 debian kernel: [49542.112215] [] ? inet_recvmsg+0x7d/0xb0
Oct 25 12:55:17 debian kernel: [49542.112216] [] ? __check_object_size+0xfa/0x1d8
Oct 25 12:55:17 debian kernel: [49542.112218] [] ? strncpy_from_user+0x48/0x160
Oct 25 12:55:17 debian kernel: [49542.112219] [] ? vfs_fstatat+0x59/0xb0
Oct 25 12:55:17 debian kernel: [49542.112220] [] ? sys32_stat64+0x25/0x60
Oct 25 12:55:17 debian kernel: [49542.112221] [] ? do_gettimeofday+0x25/0x90
Oct 25 12:55:17 debian kernel: [49542.112223] [] ? compat_SyS_gettimeofday+0x39/0x90
Oct 25 12:55:17 debian kernel: [49542.112224] [] ? do_fast_syscall_32+0x8d/0x170
Oct 25 12:55:17 debian kernel: [49542.112225] [] ? entry_SYSENTER_compat+0x4c/0x5b

というわけで、apacheがいかんのかと思っていたら、cifsじゃね?ということで。

いや、最近よく鯖が固まるんです。
認証かけているところだけだったのでssl絡みかapache周りだとずっと思っていたのですが・・・
鯖はHyper-V上で動いていて、バックアップを取るために一日一回サスペンドに入るのですが、そこから復帰したときにcifsが固まるせいでそこへアクセスしようとするapacheが固まる、という事だった様子。

ということでgoogle先生に聞いたらやっぱり同じ症状の人がいました。
SMB/CIFS mount hang and kernel hung task
Bug#861104: linux-image-4.9.0-2-amd64: Kernel deadlock with CIFS mounts
が、どうしたらよいという解決策は微妙で、1つ目のリンクのようにアクセスし続ける、というのも手なのかも。

ひとまず、autofsで
/mnt/samba /etc/auto.master.d/windows.cnf -t=0 -g
としているのを-t=600に変えて都度マウントするようにしてみましょう。

→なんとなく治った気がします。
-t=0の実装が良くないのか、windows側の問題かはわかりませんが、正常にレジュームできないんでしょうね。

2017/10/22

なんか更新された

Windows 10のメジャーアップデート「Fall Creators Update」で何が変わったのか?

というわけで、いつも通り(3D オブジェクトが増えましたが)
Windows Registry Editor Version 5.00

;OneDrive
[-HKEY_CLASSES_ROOT\CLSID\{018D5C66-4533-4307-9B53-224DE2ED1FE6}]

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{088e3905-0323-4b02-9826-5d99428e115f}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{24ad3ad4-a569-4530-98e1-ab02f9417aa8}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{3dfdf296-dbec-4fb4-81d1-6a3438bcf4de}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{d3162b92-9365-467a-956b-92703aca08af}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{f86fa3ab-70d2-4fc7-9c99-fcbf05467f3a}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{B4BFCC3A-DB2C-424C-B029-7FE99A87C641}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{0DB7E03F-FC29-4DC6-9020-FF41B59E513A}]

[-HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{088e3905-0323-4b02-9826-5d99428e115f}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{24ad3ad4-a569-4530-98e1-ab02f9417aa8}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{3dfdf296-dbec-4fb4-81d1-6a3438bcf4de}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{d3162b92-9365-467a-956b-92703aca08af}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{f86fa3ab-70d2-4fc7-9c99-fcbf05467f3a}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{B4BFCC3A-DB2C-424C-B029-7FE99A87C641}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{0DB7E03F-FC29-4DC6-9020-FF41B59E513A}]

[-HKEY_CLASSES_ROOT\Folder\shellex\ContextMenuHandlers\PintoStartScreen]
[-HKEY_CLASSES_ROOT\Folder\shellex\ContextMenuHandlers\{a2a9545d-a0c2-42b4-9708-a0b2badd77c8}]
[-HKEY_CLASSES_ROOT\Folder\shell\pintohome]
[-HKEY_CLASSES_ROOT\Folder\shell\pintohome\command]

僕に関係しそうな機能としてはタスクマネージャでGPUの負荷率が見えるようになりました、というぐらいですかね。

2017/10/15

NASでVM

最近のNASはPC用のCPUを積んでいることもあり、中で仮想マシンが動きます。
QNAPも同様で、VMwareで動いてたvmxをインポートしたらあっさり動きました。

どうせコンソールしか使わないので性能は特に問題ないのですが、鯖を動かしているとアクセスがあるためHDDがスタンバイに入ってくれないことに気が付きました。
・・・まぁ、そうだよね・・・

そういえばNASdではなく、2008R2のHyper-V上で動いているdebianさんが良く文句を言います。
曰く、
hv_utils: Integration service 'Backup (volume snapshot)' not supported on this host version.
hv_vmbus: probe failed for device ... (-19)
とか
INFO: task apache2:14028 blocked for more than 120 seconds.
debian kernel: [86275.040066] Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
とか。

ふむ・・・

あと、システム起動時にntpが9時間ずれている、という文句を言っているようです。
いろいろ調べた結果、windowsがlocaltimeをHWCLOCKとして渡す「仕様」なのに対し、linux側がUTCを受け取っていると思い込んでいるのがいかんのではないかという結論に。
hwclock.shには
# Use the UTC/LOCAL setting in /etc/adjtime rather than the UTC setting in /etc/default/rcS.
と書いてあったので、/etc/adjtimeのUTCをLOCALに変更してみたところ、hwclock --showの結果が正しくなりました。

もしスナップショットを取るときにいったんスタンバイに入り、その後hwclockを使って誤って9時間進んだ時間で復帰した結果おかしくなっているのだとすると、時間を正しく取得できるだけで治るはず。
・・・まぁ、 not supported on this host versionとか言ってるからスナップショットを取るのをやめればよいのかもしれませんが・・・

→変わりませんでしたorz。
どうもおかしくなるタイミング的にはホスト(2008R2)側がバックアップを作成するタイミングのようなのでhyperv_daemonとか入れてみたのですが、もともと入ってるのと何が変わるのやら、という結論に達してひとまずremove。

/server-statusをしばらく眺めていたら、なんとなく終了しないスレッドが多数あるような気がしてきました。
MPM:workerで動いていて、
StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 64
ThreadsPerChild 25
MaxRequestWorkers 150
MaxConnectionsPerChild 0
(というかデフォルトのはず)
なのですが、何がいかんのか・・・
おかしくなっているときにはスレッドがMaxSpareThreads近くに達していて終わっていないのがたくさんあるという・・・
apacheをrestartさせていくつかアクセスをしてみたものの、スレッドが終了せずにMinSpareThreads以上になる現象には出会えず。

チューニングとかいろいろあるんでしょうが、別にMPM変えてもよかったので、2.4ではデフォルトになっているというeventに変えてみました。

これでまた様子を見てみましょう・・・。

参考:
Apache HTTP Server: MPMパラメータ チートシート
Hyper-V 仮想マシンのバックアップは VSS 非対応でも止まらないんだ

→変わりませんでした
続きは後日