Aukey CB-H15のテストとRealtek RTL8152/8153 Bawsed USB Ethernet Adaptorsバグ

この手のアイテムといえば

Aukeyからご提供いただいたUSB3.0ハブ兼GbEアダプタのCB-H15のテストと、Live with Linuxのネタのセットになる。

この手のデバイスは、あまり有名ではない。だが、重要性はましており、アイテムとしては増えている。
最近のラップトップはEthernetポートがついていないものが増えている。消費電力が大きく、高さもあるポートを嫌うのはわからないではないが、wLANが好きでない人は結構いるのではないか。

減ってしまったUSBポートを補い、Ethernetポートを復活させる、欠かせないアイテムが、このUSBハブ兼Ethernetアダプタだ。

また、PCルーターを使用する人にとっても欠かせないアイテムでもある。
消費電力が少なく騒音の小さいラップトップを使用する場合はUSBタイプでなければ難しいし、小型のサーバーを使う場合でもPCIeでの接続は結構難しい場合がある。
安定して確実に使えるのが、USBイーサネットアダプタである。USBハブを兼用している必要はないのだが、兼用しているものならば汎用性が高い。

実際に、USB2.0接続の100baseなアダプタを既に2つ持っている。
インターネットの速度的に、ルーティング先がインターネットにつながるのであれば100baseでも問題ないのだが、LANのルーターとしては不十分である。
USB3.0でGbEが使えるようになったのだから、それが利用可能であれば使いたいものだ。
ちなみに、その100baseなアダプタを2つも持っているのは、セルフパワーでも動作するという点を買ってのこと。

まだUSB3.0を使えるのが、バックアップ系になっているFM2+Killerしかないため、今のところはUSB3.0 GbEアダプタを導入してはいないが、この先導入する予定だったし、結構Amazonで探したりもしていた。

日本だとメジャーどころが多いが、中国だと結構あるらしい。
コストと品質を考えれば、やはり中国や台湾の当たりデバイスをひきたい…と考えるのは、まぁ好き者の性なのか。
TODOに入っている状態で見た限りでは、そんな感じだ。

そこにご提供いただけたため、渡りに船状態。
しっかりとテストしていく。

Linux上でのRealtek RTL8152/8153 Bawsed USB Ethernet Adaptorsのバグ

当然ながらLinux環境でのテストになる。
Manjaro Linux(4.1.15-1-MANJARO)で使用すると、一発認識される…のだが、「ケーブルが接続されていません」となる。

試していくと、リンクが100Mbpsならばケーブル接続を認めるのだが、1000MbpsだとNot Readyになってしまう。

上手くいかなくて調べたところ、バグらしい。

こういう問題なら、多分Ubuntuでも同様だと思う。
ここでUbuntu forumでなくArch forumが出てくるところに両者の差が…

ともかく、TLPのUSB BLACKLISTとして0bda:8152を登録する。
手順としては/etc/default/tlp

USB_BLACKLIST="0bda:8152"

のように記述する。

品質テスト

筐体

サイズは大きいが、軽い。
10.1や12.1のラップトップと組み合わせて放り込むには大きい。15.1のラップトップならバッグに入る。

プラスチックで安っぽいボディではあるが、それほど気にならない。

注目すべき点として、USBポートは横向きのタイプで、かつオフセットされている。
そして、オフセットされたポート側は角が角、反対側は丸められている。
恐らくは、壁につけて設置することを想定しているのだろう。このために、USBデバイスを挿してもひっぱられてハブが倒れてしまいにくい。

個別にLEDランプがあるのも嬉しい。携行よりは常設向きか。15.1くらいのラップトップを家で常用している人にベストか。

速度

iperf3で計測。

$ iperf3 -c mint.local
Connecting to host mint.local, port 5201
[  4] local 2001:c90:8481:3759:f21e:34ff:fe1f:a542 port 55861 connected to 2001:c90:8481:3759:3ed9:2bff:fe50:efed port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  97.1 MBytes   815 Mbits/sec    0    273 KBytes       
[  4]   1.00-2.00   sec  95.7 MBytes   803 Mbits/sec    0    287 KBytes       
[  4]   2.00-3.00   sec  96.3 MBytes   808 Mbits/sec    0    305 KBytes       
[  4]   3.00-4.00   sec  96.5 MBytes   810 Mbits/sec    0    326 KBytes       
[  4]   4.00-5.00   sec  96.4 MBytes   808 Mbits/sec    0    343 KBytes       
[  4]   5.00-6.00   sec  96.5 MBytes   809 Mbits/sec    0    382 KBytes       
[  4]   6.00-7.00   sec  95.9 MBytes   805 Mbits/sec    0    404 KBytes       
[  4]   7.00-8.00   sec  95.9 MBytes   804 Mbits/sec    0    425 KBytes       
[  4]   8.00-9.00   sec  96.1 MBytes   806 Mbits/sec    0    448 KBytes       
[  4]   9.00-10.00  sec  97.5 MBytes   818 Mbits/sec    0    558 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   964 MBytes   809 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   961 MBytes   806 Mbits/sec                  receiver

iperf Done.

809Mbps/806Mbps。
800Mbpsを越えているので及第点だろう。

うちならば、

  • WAN/インターネット->OK
  • サイト間インターネット->OK
  • サイト内ネットワーク(AoE)->NG

といったところで、AoEや業務ルーターなど高いスループットや信頼性がが要求されるシーンでは使えないが、インターネットでボトルネックになることはまず考えられないし、AoEやdistccなどの高スループットが要求される用途で使われない異サイト間を接続するルーターへの接続なら(家庭用途では)問題ないだろう。

USBアダプターであることを考えれば(まして、USBハブと兼用)不満のない性能だ。

ちなみに、オンボードのQualcomm Atheros Killer E20x Gigabit Ethernet Controller

$ iperf3 -c mint.local
Connecting to host mint.local, port 5201
[  4] local 2001:c90:8481:3759:be5f:f4ff:fefb:bb5 port 52309 connected to 2001:c90:8481:3759:3ed9:2bff:fe50:efed port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   110 MBytes   919 Mbits/sec    0   97.6 KBytes       
[  4]   1.00-2.00   sec   110 MBytes   920 Mbits/sec    4    180 KBytes       
[  4]   2.00-3.00   sec   110 MBytes   919 Mbits/sec    0    190 KBytes       
[  4]   3.00-4.00   sec   110 MBytes   919 Mbits/sec    0    206 KBytes       
[  4]   4.00-5.00   sec   110 MBytes   919 Mbits/sec    0    208 KBytes       
[  4]   5.00-6.00   sec   110 MBytes   920 Mbits/sec    0    212 KBytes       
[  4]   6.00-7.00   sec   110 MBytes   919 Mbits/sec    0    212 KBytes       
[  4]   7.00-8.00   sec   110 MBytes   919 Mbits/sec    0    212 KBytes       
[  4]   8.00-9.00   sec   110 MBytes   920 Mbits/sec    0    220 KBytes       
[  4]   9.00-10.00  sec   110 MBytes   920 Mbits/sec    0    240 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.07 GBytes   919 Mbits/sec    4             sender
[  4]   0.00-10.00  sec  1.07 GBytes   919 Mbits/sec                  receiver

iperf Done.

さすがに速い。Killerイーサネットは遅いと言われているが、かなり速い。
PCIeのほうが安定して速い、ということなんだろう。

このような信頼性や速度を求めるのであれば、そもそもUSBでやらないだろう。

製品評価

最初に述べたように、この手のアイテムはラップトップユーザーなら必携だ。

持ち歩きにはそれほど向いていない。大きいためだ。だが、大きな(余裕のある)バッグを常用する人であれば、軽量であるため携行は苦にならないだろう。
要は軽量であるためでなく小さいためにモバイルラップトップを使う人なら携行には向かず、そうでなければ携行用にもなる。
少なくとも、スーツケースを使うような出張においては携行するのに苦もないだろう。

USB3.0の3口ハブとの組み合わせで、ラップトップなど端子が限られている中では現状ベストなアイテムだと思う。
USB3.0ハブとして使用する場合はそちらに帯域が取られることになり、LANはフルスピードが出ない。その意味で、純粋なEthernetアダプターというよりは、インターフェイス拡張という考え方が適当だろう。
その意味で、USB3.0 1ポートとUSB3.0の3口ハブとGbEという拡張は「マスト」なのだ。

私はThinkpad e440をEthernetポートありきで選んでいるし、Pavilion x2-10を自宅で使うことは滅多にないので、基本的にラップトップでこのようなインターフェイス拡張を行うことがない(泊まりがけの作業などにおいてはe440を持ち出す)のだが、もしそうではない、Ethernetポートのないラップトップを使っていたとしたら、ましてデスクトップなしにメイン機として使っていたとしたなら、なくてはならなかっただろう。
言ってみれば、ThinkPadのドックステーションのようなものだと言っていい。もちろん、携行はずっと容易だ。

アイテムとしての価値はそうとして、ものはどうか。

まず、LANチップは評価は色々あれど、信頼性の高い、一般的なチップであることはLinuxerとしては非常に嬉しい。
私が使っている100baseのハブは、ドライバがちょっとbuggyで、CentOS6だと使えないなどの問題があった。
結局、ドライバに関係するバグ(udevに関するバグだが)によってこれはこれでワークアラウンドが必要になったが、情報が多く解決は比較的簡単だった。
これは結構重要なのだ。

もちろん、USB3.0ハブとしての機能は申し分ない。
USB3.0を増やさなければならないケースはあまり多くはないと思うが、ラップトップの端子数が2以下であるならば、キーボードやマウスを接続すると同時にフラッシュドライブを使用するようなケースは珍しくはないだろう。

片面の角が角、もう片面は丸となっていることについては、なかなか心憎い発想だとは思うが、実際に活用する場面は限られそうだ。だが、実際に壁につけて使用する場合は収まりもよいはずだ。

そして、USBポートがオフセットされているのは、実際にそのためにハブがこけないようになっている。これは、大きな魅力であり、選択時に比べるポイントの少ないこのようなアイテムにおいて選択する理由に十分なりうるだろう。

デザインも良い。

総合的に見れば、特にコンパクトさを重視しないのであればとても良い製品だ。
linuxer目線でいえば、あまりこうしたアイテムで使われているチップが判別していて、動作報告があるものというのがないため、この情報だけでも十分使う価値はある。
正直、800Mbpsは厳しいだろうと思っていたのでかなり嬉しかった。

WILLCOMの通信速度を半分にするとか言われたので、Y!Mobileにしたら料金3倍だというのか

経緯

Y!Mobileから、現行のWILLCOM D+の速度を半分にするよ、という、とっても理不尽な通達がなされた。

全く納得はいかないが、とりあえず今は存在しないプランでの契約になっているため、もろもろ考えて相談はしておくことにした。

現状

3回線で2700円くらい。猛烈に安い。

WX11K

内容 料金
新ウィルコム定額プランS 1,381
基本使用料割引 -1,381
留守番電話サービス月額料 100
スーパーだれとでも定額月額料 1,500
W-VALUE割引 -934
ユニバーサルサービス料 2

小計 668

WX04SH PHS

内容 料金
ウィルコムプランD+基本使用料 934
基本使用料割引 -934
あんしん保証サービス プラス月額料 500
留守番電話サービス月額料 100
だれとでも定額月額料 934
W-VALUE割引 -1,034
ユニバーサルサービス料 2
ユニバーサルサービス料割引 -2

小計 500

WX04SH Softbank

内容 料金
WEB接続料 300
スマートフォン基本パック(W)月額料 500
パケット定額割引特典 -3,317
パケット定額 5,200
W-VALUE割引 -1,138

小計 1545

スマホを変えると…

単一回線になり、だいたい2980円から。
2回線目以降は-500円。

つまり、スマホを変えた場合は、1545円から2480円となり、935円増で、PHS回線を喪失。

ただし、ケータイプランを使えば(端末料金はかかるが)無料でもう1台もつことはできる。その場合は、パケットが定額でないのが厄介な話だが。

両方変えると…

全部組み替えることになる。
WX04SHをY!Mobileのプランにしてしまえば、WX11Kを主回線として維持する必要はないらしい。

結局、主回線は割引率の小さいスマホとなり、

  1. スマホプランS
  2. ケータイプラン
  3. ケータイプラン

とすると、月額基本料金は2980円。

ただし、この場合スーパーだれとでも定額を失うことになるため、それを踏まえると一番安いのは、スマホプランSにスーパーだれとでも定額をいれての3980円。

ちなみに、ケータイがパケットは上限定額の2500円。恐ろしい。

主回線は変えられない

主回線を変えると2台目無料を失う

D+の問題

2年経つと、D+の割引がなくなる。自動的に高くなる。そのくせに速度は遅くなる。

Dプランがもうないのでどうしようもない。
本来はそのタイミングでDプランに変えろよという話だった気がするが。

なんという理不尽感。

転出はできる

3回線とも転出は可能とのこと。
PHSを転出して070で転入できるのかは疑問だが。
080は転出してしまうという方法もある。

ケータイプラン高くないか?

パケットが定額のスマホプランSが2980円。

ケータイプランはスーパーだれとでも定額を必須として2818円。

通話部分での差は出るが、なんかおかしくないか??

ケータイプランSSは定額化できず、4500円まで上がる。5480円。シャープのシェルスマホがケータイプランが選べないのがまた辛い。

シェルスマホはバックグラウンド通信しうるのでだいぶ怖い。

今と同じ構成でY!Mobile

  1. スマホプラン
  2. ケータイプラン+スーパーだれとでも定額
  3. スマホプラン

で同じになる。

2980+1000+2580の6560円。

2台目のスマホは転出するか、ふぃーちゃーふにするかしたほうが良さそう。

Nexus7初期化とAndroid5

もらいもののNexus7 2012だが、設定はぐちゃぐちゃ、バッテリーの消耗も激しく使い物にならなかった。
そこで初期化した。

初期化手順は、シャットダウンし、電源ボタンとボリュームダウンボタンを長押しして起動し、Recovery modeを指定し、電源ボタンとボリュームアップボタン同時押しでメニューを出し、factory reset。

これでかなり快適な動作になったし、バッテリーももつようになった。Nexus7 2012ってこういう端末だったんだなぁ、といった感じだ。

そして、順次システムアップデートが降ってくるので適用していく。最終的には5.1.1で落ち着いた。

Nexus7にAndorid5(lolipop)は重すぎるという話があるのだが(そのために初期化したという人も多いようだ)、ざっと印象としては

  • UIはよくなったし、部分的に高速化した
  • ホームスクリーンがAndroidコンポーネントでないため、あんまり変わったという感じはない
  • 著しく重い時が結構ある。重くなると使い物にならないくらいにもっさりする
  • 一度、起床後に触ったらフリーズしたことがある

自前PostfixサーバーとGMail

自前のメールサーバーからGMailにメールを送ると

<*.com>: host
gmail-smtp-in.l.google.com[2404:6800:4008:c02::1b] said: 550-5.7.1
[2001:2e8:649:0:2:1:0:11 12] Our system has detected that this
550-5.7.1 message is likely unsolicited mail. To reduce the amount of spam
sent 550-5.7.1 to Gmail, this message has been blocked. Please visit 550
5.7.1 https://support.google.com/mail/answer/188131 for more information.
kt7si2092671igb.13 – gsmtp (in reply to end of DATA command)

のように言われてしまう。

迷惑メールとしてブロックされてしまうのだ。されない場合もあるが、その原因がよくわからなかった。

色々と調べた結果、どうもDNSレコード内にSPFの記述が欠如していると配送されない、ということのようだ。

SPFは、メール配送においてそのドメインから贈られたメールとして受け取るべきサーバーのアドレスを示すものだ。そのアドレス以外からは当該ドメインのメールを受け取らない、というポリシーにすることによって、なりすましを防ぐ、らしい。

SMTPがちゃんとリレーしてくれない昨今、ローカルSMTPが使えなくなる原因ともなり、ひたすらやりにくい気がするが、まぁなりすましメールを防ごうというわけだ。

SPFはTXTレコードとして存在し、うちの場合

v=spf1 +ip4:27.120.84.145 +ip6:2001:2e8:649:0:2:1:0:11 ~all

となっている。これによって、@reasonset.netからのメールは、このアドレス以外のサーバーから配送された場合はなりすましメールとみなし、排除してよい、という情報を与えることとなる。
GmailはSPFを必須とするようだ。

SPFレコードを追加したが、それでもGMailに拒否される。
どうやら、AAAAレコードも必要なようだ。AAAAレコードを追加したところ、拒否されなくなった。
ただし、失敗を繰り返したアドレスに対してはいばらく送ることができなかった。

Paiza プログラミング彼女の解法と不満

Paizaで展開している、「プログラミング彼女」というサブコンテンツ。

めがね

Paiza B級。

ビットマップマッチングだが、値は

0 1 1 1
1 0 1 1
0 1 0 0
0 1 1 0

のような文字列で与えられる。マッチングパターンも同様だ。

結構馬鹿馬鹿しい。

その1

ip = []
tp = []

gets.chomp.to_i.times {|n| ip << gets.delete(" ") }
gets.chomp.to_i.times {|n| tp << gets.chomp.delete(" ") }
tp[0] = Regexp.new(tp[0])

ip.each_with_index do |ips, ipi|
  ips.scan(tp.first) do
    offset = $`.length
    if tp[1 .. -1].each.with_index.all? do |tpp, tpi|
                                          ip[ipi + (tpi + 1)][offset, tpp.length] == tpp
                                        end
      print "#{ipi} #{offset}"
      exit 0
    end
  end
end

これが通過しなかった。

手元でテストする限り、これで通過しないケースは発見できなかったのだが、case4で0.11secでこけてしまう。

これは納得できないところだ。

文字列の正規表現マッチングを行っているため、かなり魔術的に見えるだろう。
しかし、実はそうでもない。

「文字列」というが、Rubyの場合は文字列はバイト列も含む。
バイナリ検索にしてもバイトパターンのマッチングは普通なので、別にそのために文字列検索を行ってもなんら問題はない。

本来は多重配列を用いたマトリックスを求めていたのだろうけれども、Rubyの能力を考えれば配列よりも文字列のほうがはるかに扱いやすいし速いので、ちょっと魔術的でもこちらのほうが良いと考えた。

その2

matched = Array.new
base = Array.new
target = Array.new

gets.chomp.to_i.times { base << gets.chomp.delete(" ") }
gets.chomp.to_i.times { target << gets.chomp.delete(" ") }


target.each do |ts|
  matched << ( l = Hash.new )
  base.each_with_index do |x, i|
    o = -1
    while o = x.index(ts, (o + 1))
      l["#{i} #{o}"] = [i, o]
    end
  end
end

print(matched.first.keys.select do |k| 
  y, x = *matched.first[k]
  matched.length.times do |n|
    unless matched[n]["#{y + n} #{x}"]
      break nil
    end
  end
end.first)

ダメだと言われたので改修してみた。
各パターンにおいてマッチするメトリックをハッシュに格納し、マッチ側パターンの行数縦に連続するものをマッチとみなす。
速度的にも効率的にも悪くない。これで通過

水着

Paiza A級。

階乗の、末尾0を除いた末尾9桁を出力せよ、という問題。
本来はInteger Overflow対策が求められるのだろうが、RubyはBignumがあるため、そこは不要。

しかし、実効速度に伴うタイムアウトという壁が立ちふさがった。

その1

def fact(n)
    if n <= 1
        n
    else
        n * fact(n - 1)
    end
end

base_n = gets.chomp.to_i
ret_n = fact(base_n).to_s
ret_n =~ (/(.{0,8}[^0])0*$/)
print $1.sub(/^0*/, "")

理論上はOKで、実際テストではOKだったが、Case3でコケる。
おそらくはコールスタック枯渇。

その2

num = (1 .. gets.chomp.to_i).inject {|x, sum| x * sum }
print num.to_s.sub(/0*$/, "")[-9 .. -1]

コールスタックが枯渇しないように、Enumerable#injectを使ったループに変更した。
だが、Case4で15.00secで失敗する。おそらくはタイムアウト。

その3の1

print((1 .. gets.chomp.to_i).inject {|x, sum| (x * sum).to_s.sub(/0*$/, "").to_i % 1000000000 })

タイムアウトを避けるため、常に9桁に抑制することにした。

このコード、計算結果が1000000000だった場合に、商余が0になってしまうため失敗するが、事前に0を除いているために起こりえない。

だが、これはあっさり失敗してしまう。
手元では通過していたため、失敗理由がわからなかった。

その3の2(通過)

print((1 .. gets.chomp.to_i).inject {|x, sum| (x * sum).to_s.sub(/0*$/, "").to_i % 1000000000000 } % 1000000000)

計算桁を増やして最後に9桁に落とすようにした。
これで通過したが、計算桁はなんとなく増やしているだけなので、理論的には失敗しうる。

その3についての検証

r = (1 .. gets.to_i).inject([1, 1]) do |sum, x|
  puts "---" + x.to_s
  puts( a = (( x * sum[0] ).to_s.sub(/0*$/, "").to_i % 1000000000) )
  puts( b = (( x * sum[1] ).to_s.sub(/0*$/, "").to_i % 100000000000) )
  sum = [a, b]
end

puts "**ANSWER"
puts r[0]
puts r[1] % 1000000000

puts "*****"

p(137921024 * 50)
p(83137921024 * 50)
p((137921024 * 50).to_s.sub(/0*$/, "").to_i)
p((83137921024 * 50).to_s.sub(/0*$/, "").to_i)
p((137921024 * 50).to_s.sub(/0*$/, "").to_i % 1000000000)
p((83137921024 * 50).to_s.sub(/0*$/, "").to_i % 100000000000)

なんとなく想像はついたが、検証してみた。

!50の結果が変わってしまう。これは、!49の時点では

137921024
83137921024

と9桁/11桁で正しいが、!50になると

68960512
41568960512

と8桁/11桁になってしまう。0を除く前の時点で

6896051200
4156896051200

1桁増えているが、0が末尾に2つ増えており、0を除くことで2桁減る。結果として1桁減ってしまうことになる。

計算を続けていくと、この誤差は消滅するが(桁上がりすれば良い)、与えられた数によっては失敗することになる。
これを考慮すると正しくは

print((1 .. gets.chomp.to_i).inject {|x, sum| (x * sum).to_s.sub(/0*$/, "").to_i % (1000000000 * (10 ** ($&.length.zero? ? 1 : $&.length) ) ) } % 1000000000)

とすれば良いはず。

Paizaへの不満

条件が予測できない

条件は一応書かれてはいるが、それ以外の条件が多すぎる。

コールスタックの枯渇は予測できるからいいとしても、タイムアウトという条件は記載されていないし、めがねのその1が失敗する理由もわからない。

これで技術を評価されるというのはとても不満だし、だいたい大した機能もない開発環境で、妥当性検証の方法も単一のサンプル、それもどのような入力かを明確にしないままであり、入力の仕様も(業界では一般的な形式なのかもしれないが)非常にわかりにくい。

デバッグできない

失敗した場合でもなぜ失敗したのか分からない。そのためデバッグすることができない。

提出前に失敗した場合でも、全体出力を見ることができず、かつデバッグせずに提出することを前提としているためデバッグはかなり難しい。

私はこうしたことは不毛だと思っている。プログラムはちゃんと磨き上げて動くコードにするものだろう。そして間違いなく動くことが確認されて、はじめてリリースだ。

確認もデバッグもできないままということで、一度しか提出チャンスがないということにも強い違和感を覚える。

いつからこんなつまらない業界になったのか

これはPaizaに限った話ではないけれど、IT業界が、まず履歴書、そして業務履歴書なんてつまらない業界になってしまったのはいつからなんだろう。

少なくとも、私がお呼ばれした時には能力さえあればいいという空気があった。その時点でコンピュータを使うこなせる人間なんて変人が多かったし、型なしの掟破りという印象が強い。

だが、近年は、他業界よりもさらに「即戦力」ばかり求められ、経験がなければやらせないというところばかりで、「経験はどこでつめますか?」という状態。
結局そのために経歴の捏造が横行しているわけだ。

年齢も経歴も関係なしの実力次第の世界だと思うのに、そこまで経歴に固執するのは一体なぜなのだろう。

折角、コードを直接みることができるPaizaであるにも関わらず、そのフォーマットを要求するのはいかがなものか。さらに「趣味/1年未満」というくくりは一体なんなのか。
そして、定型的な業務におけるカテゴリしか用意していないのもなんなのか。実際はもっと多様で、能力とは直結していないはずなのだが。

PureBuilder2を使ったリニューアル(1)

PureBuilder1のサイトがPureBuilder2で動作するように調整すると共に、PureBuilder2の機能を検証する作業を開始した。
現在はサイトの更新が滞っているので、それが完了すれば効率的に更新できるようになる。

ただ、従来は設定ファイルにロジックを組み込む形だったため、変更点は大きく、そのまま持ってくるというわけにはいかない。
そもそも、PureBuilder1が十分なツールでなく、ツールをサイトごとに書いて完成というものだったのが問題なのだが。

まず、PureDocドキュメントはそのまま持ち込むことができる。
従来の.rebuild_rulesファイルや、ReasonSetにおけるglobal.rcファイルに変えて、.purenuilderrc.rbを用意することとなる。

おおよそそれでいいのだが、既にrcファイルで組み込んでテンプレートで利用していたような情報は.purebuilderrc.rbファイルに組み込まなくてはいけない。
また、これによって従来環境変数で処理していた物を、DOC.pbenvを使うように整合性をとらなくてはいけない。

このデバッグ作業に伴って、Purebuild Allに.rebuild_all_timeを無視して全てを対象とする-cを追加した。

そして、問題になったのがプロフィール部分だ。

これまで、プロフィールは単独のRubyスクリプトだった。rebuild_rulesから呼ばれることを爽亭しているため、設定は環境変数を通じて受け取ってはいるが、ドキュメントの生成、テンプレートへの埋め込み、そしてファイルの出力までプロフィール自体で行っていた。

しかし、これをそのままにできるわけではない。
設計上、これをPureDocであるとみなした処理したほうが早い。
だが、問題として、設定はあくまでもドキュメントを生成したあとに使えるようになっているため、ドキュメント内で使うことができない。PureDocを拡張してPureBuilder向けスクリプトにすることがかなり難しいのだ。

DOC内の@bodyStringまたはArrayという扱いだったが、実際にStringだと参照時に@body.joinを呼ぶためエラーになってしまう。この点については、PureDocのほうを修正することとなった。

こうした拡張がいまいちしづらいことを考えると、修正が必要かもしれない。
また、既存のPurebuildスクリプトを用いるのではなく、DSLによってビルドを指示できる仕組みも追加すべきだろう。

Linuxにおけるビデオフォーマットの取り扱い(H.264/H.265/VP9 WebM)

ビデオのファイルフォーマットについて

ビデオのファイルフォーマットは、

  • 動画部分
  • 音声部分
  • それをまとめる部分

の3パートからなる。
今回は

  • H.264+AACのMPEG-4 Part14(mp4)
  • H.265+AACのMPEG-4 Part14(mp4)
  • VP9+OpusのWebM

の3種類についての検討となる。

検討すべき点

画質とファイルサイズ

画質面では基本的に非圧縮が最良である、と考えて良い。
しかし、それではあまり巨大なデータになってしまうので、圧縮することになる。
非可逆圧縮を行えば画質は劣化する。これは、音声と同じ理屈である。可逆圧縮も存在するが、やはりサイズが大きく、現実的ではないとみなされている。

そもそもの話として、そんな巨大すぎるデータを扱うことは難しいため、動画素材が出力される時点でなんらかの圧縮がされているというのが普通だ。
それは、例えば録画ソフトだったり、ビデオカメラだったりだ。録画の場合、録画時に圧縮されるだけでなく、録画ソースがデジタル動画なら、その動画自体が既に圧縮されていて、2回目の圧縮をかけることになる。

いずれにせよ、非圧縮の映像ソースが手に入らないのであれば、映像ソースの状態が最良である。画質向上のための加工をすれば改善する可能性はあるが、それは普通ではない。

そこからさらにファイルサイズを小さくするために変換するか、あるいは取り扱いやすさのために変換するか、ということになる。
場合によっては、カメラから出力されるデータの圧縮形式を選べる、という場合もある。

つまりここで問題になるのは、ファイルサイズに対して画質の劣化がどれくらい抑えられるか、である。

速度

エンコード時に時間がかかるコーデックは、動画を変換してファイルとして出力する際に時間がかかる。

デコード時に時間がかかるコーデックは、再生が間に合わず飛んでしまうかもしれない。

ただ、実感としては、デコード時の所要時間の問題というよりは、ビットレートが高い動画は飛びやすい、という印象だ。
ただし、動画再生の重さには関係する。

ハードウェアアクセラレーション

デコードが重いコーデックであっても、ビデオカードがそのデコードを担うことができるのであれば、それは問題にならない。

これは、プロセッサ、ドライバ、そしてアクセラレーションの仕組みの全てがサポートしていなければ利用できない。

フォーマット

H.264

H.264(≈MPEG-4 AVC)は2003年に勧告された新しいフォーマットで、現在の主流といっていい。
MPEG-1から続く基本的な動画圧縮アルゴリズムを改良したもので、かなりの高圧縮でも目立った劣化が少ないことから主流となった。

高機能・高圧縮・高画質とメリットは大きいが、H.264を「使わない理由」といえば、エンコードに時間がかかりすぎるため、というのが一般的だ。

一般的なので、とりあえず迷ったらH.264で良いと思う。
LinuxではVDPAU/VA-APIにおいて、nVidiaグラフィックスにオープンソースまたはプロプライエタリのドライバ、さらにAMDグラフィックスにRadeonまたはCatalystドライバでH.264アクセラレーションがサポートされるというのは大きなメリットだろう。
どうもAMD APUでうまく動作してくれていないが。

nVidia Quadro 2000グラフィックスにLinux 4.3 + nvidia 1:352.53-1という構成のvdpauinfoはこのようになっている。

H264_BASELINE                  --- not supported ---
H264_MAIN                      41  8192  2048  2048
H264_HIGH                      41  8192  2048  2048
H264_CONSTRAINED_BASELINE      --- not supported ---
H264_EXTENDED                  --- not supported ---
H264_PROGRESSIVE_HIGH          --- not supported ---
H264_CONSTRAINED_HIGH          --- not supported ---
H264_HIGH_444_PREDICTIVE       --- not supported ---

Quadro 2000はFeature set Cなのでこうなっているのだろう。

非常に扱いやすい、お勧めできるフォーマットだ。
可搬性からいえば、MPEG-4のほうが上かもしれない。ちなみに、MPEG-4 Part2は、H.263がベースで、H.264と比べると劣っている。

H.265/HEVC

承認されたのが2013年という非常に新しいコーデックで、携帯向け映像配信から8kビデオまで幅広くターゲットにしている。
dアニメストアがH.265を採用していることで知られている。

同等の画質でH.264の半分の容量、という触れ込みだ。
非常に優れたフォーマットだが、新しすぎて結構厳しい。ハードウェア支援が追いついておらず、それでいて処理は非常に重い、というのが辛い部分でもある。
将来的には、H.265を置き換えていくのだろう。

H.265をサポートするFeature set FはGTX950/960のみで、TITANも含まない。QuadroシリーズはM6000まで含めて最大でもEまでだ。H.265が新しいフォーマットであることもあり、対応はまだまだ進んでいない、最新のカードでようやく対応がはじまったということなのだろう。

ちなみに、エンコード速度の差はあまりなかった。
というよりも、私の環境ではH.264の高品位エンコードが結構遅いので、H.265を若干軽い設定にしたこともあってか、2.1fpsでどちらも同じだった。

VP9 (WebM)

H.264はかなり複雑な特許関係になっているし、H.265はMPEG LAが特許を保有している。
こうしたことを嫌う人は、かなりいる。

Mozilla Firefoxは、以前mp4系ではなく、Ogg Theoraをサポートしていくことを表明したことがある。

Ogg Theoraについてはちょっと説明が必要だろう。Oggというのは、そもそもコンテナフォーマットで、任意の数の対応したコーデックを格納できる。一番有名なのは非可逆圧縮音声コーデックのVorbisで、OggコンテナフォーマットにVorbisを格納したものがOgg Vorbisだ。

そして、可逆圧縮音声コーデックのFLACを格納したものがOgg FLAC(FLACはOggに格納しないほうが普通)、動画コーデックのTheoraを格納したものがOgg Theoraだ(音声はSpeex, Vorbis, CELT, Opus, FLAC, OggPCMのどれか)。

このあたりは、Xiph.orgが開発したロイヤリティフリーコーデック/フォーマットで、OSSの一翼を担うと自負するMozillaなりのプライドだったのだろう。
しかし、そもそもOn2のVP3をベースにしたTheoraはあまり品質の良いものではなく、結局普及もしないままだ。オープンなのは良いことだが、Ogg Theoraをサポートしているプレイヤーも少なく、最初から影の薄い存在だ。

動機は似ているが、よりアグレッシヴに、技術的な主導権を握ろうとしたのがChromeの開発を行うGoogleだ。GoogleはChromeへの搭載とYouTubeでの採用の両面から働きかけている。

GoogleはコンテナフォーマットWebMを開発し、VPコーデックを開発してきたOn2を買収してその最新コーデックであるVP8を採用、音声フォーマットはVorbisをメインに採用してきた。
VP8に関しては特許問題があったが、最初から利用者に対する開放という方針は貫かれている。その後特許問題をライセンス契約締結によって解決し、自由に使えるようにした。

主導権を得るために、かなり献身的な振る舞いをしていると言ってもいい。品質面に問題があるTheoraに対して、VP8を採用するWebMは品質面でもH.264+AACのmp4に対抗できる存在だった。
現在においてもこの試み、つまりオープンソースによってデファクトスタンダードを塗替え、フォーマットを統一してリーダーボードを握るというのは依然として野心的だが、挑戦は続いているし、かつ悪くない話でもあり失敗もしていない。

そして、WebMの第二世代ともいうべきサポートが、VP9ビデオコーデックとOpusオーディオコーデックの採用だ。

VP9は、VP8に対して同一画質でビットレートを半分にする、ということなので、その目標はH.264に対するH.265と等しい。仕様がH.265と比べてもシンプルで、YUV444, 12bit色深度, アルファチャンネル, 深度チャンネル, 8kと機能はむしろ勝ってさえいる。
2011年にスタートしたプロジェクトで、後追いだったVP8とは違い、H.265に対して一歩前をいく状況で始まっている。

さらに、音声コーデックのOpusは、スピーチ向き音声フォーマットのSpeex、あるいは音楽向けコーデックのVorbisを越える存在として登場している。
IETFによって開発され、RFCで標準化され、リファレンス実装がBSDライセンスでリリースされている。Xiph.orgが手動するVorbisやFLACよりも、さらに文句なしにフリーだ。
音質がいいだけでなく、低レイテンシも実現している。ビットレートによって(場合によってはシームレスに)モードが切り替わり複数の仕様が混在するのは美しいとは言えないように思うが、実際に品質は素晴らしいのだから文句のつけようがない。
政治的紛争と無縁というわけではないのだが、Vorbisの次を叶えるコーデックではあるだろう。

つまり、完全に特許と制約に基づいたH.265+AACに対して、課題はあれども利用者としては自由に使うことが約束されているVP9+Opusでは、まずそこで魅力がかなり異なる。
しかも品質面でも優れている。

だが、決定的なディスアドバンテージもある。LinuxのVDPAUにおいてどころか、WindowsのPureVideoでさえ、VP9はもちろん、VP8もハードウェアアクセラレーションがサポートされていない。
VP8がサポートされていないということは、将来的にも大きな状況の変化がない限りはVP9も含め、WebMでのハードウェアアクセラレーションはサポートされないのだろう。
H.265のサポートはもう見えている。これは決定的だ。

比較

実際に比較してみた。

エンコーディングはだいたい同じくらいの時間がかかった。VP9+OpusのWebMが3.0fps出ていて1.5倍ちかく速かったが、それでもとても遅いのであまり意味はない。

サイズを見てみよう。

-rw------- 1 aki users 194571866 12月 10 10:59 moto-mad-01.h264.mp4
-rw------- 1 aki users 153719824 12月 10 17:14 moto-mad-01.h265-crf20.mp4
-rw------- 1 aki users  96287262 12月 10 09:13 moto-mad-01.h265.mp4
-rw-r--r-- 1 aki users 492912031  4月 16  2015 moto-mad-01.mov
-rw------- 1 aki users 215367319 12月 10 11:50 moto-mad-01.webm

H.264はCRF18、h265-crf20とWebMはCRF20、h265はCRF24だ。
ちなみに、元のMOVファイルはH.264+AC3である。

CRFが同一基準にならないようにしか見えないので、それぞれのコーデックで画質と容量の関係を探らなければ意味がなさそうだ。
実際、FFmpeg公式で、x265については

default CRF of 28. The CRF of 28 should visually correspond to libx264 video at CRF 23, but result in about half the file size.

と言っていたりする。色々やってみなければ分からないのだが、実際H.265の「劣化が少ない」は納得できる。H.264と比べてもそこは結構違う。H.264でCRFを上げていくとかなり乱れるので、ケータイ向けに用意したりするとはっきりと違ってくるのだ。

ちなみに、この生成物の感覚的な画質の比較でいうと

  • H.264は若干粗い。滑らかさが足りない
  • H.265は綺麗。CRF20かCRF24かの違いはほとんど分からない
  • WebM(VP9)はなめらかに見えるが、動きが激しいところではざらついて見える

結論

  • 今のところはH.264を使うのが可搬性を考えてもまとも
  • どうしてもファイルサイズを落としたい場合、H.265は結構いい
  • とりあえずVP9を使うメリットは、OSS派以外にはなさそう。エンドユーザーから見るとこだわりがない限り動機としてはかなり弱い
  • 将来的にはH.265に移っていくと考えて良いと思う
  • WebMがもっと普及して、ハードウェアアクセラレーションも対応してくれると嬉しい
  • そもそも、現在大抵の動画はH.264になってるし、普通の人がコーデックを選ぶ機会があまりないと思う
  • 昔のWMVやRM抱えてる人はWebMにしちゃうのもいいかもよ

hp Pavilion x2-10 アップデート・アップグレード関連の問題

Darfon Softcover Keyboard Utility

Mute Syncをアンインストールしてから、再度更新する。
失敗と表示されるが、Notificationは消える。

HP PC Hazrdware Diagnostics UEFI

http://h30437.www3.hp.com/pub/softpaq/sp72001-72500/sp72230.exe経由でのダウンロード/インストール。

Windows 10へのアップグレード

容量が足りないため、外部ストレージが必要。10GBを必要とするため、16GB以上のディスクとなる。

microSDカードでは再起動時に無視されてしまうため、USBメモリーを必要とする。
かなり失敗するが、諦めず再試行。
ちなみに、Widnows 10 Insider Previewと表示されるが、Previewではなく製品版にアップグレードされる。

しかし、ログオン時にHP Support Assistantがエラーを出力するようになる。

The feature you are trying to use is on a network resource that is unavilable

Click OK to try again, or enter an alternate path to a folder containing the installation package “HP Support Assistant.msi” in the box bellow.

手動で選択してもうまくいかないので、削除して再インストール。
再インストールはHPのFTPからの入手となった。

なお、Windowsは既定のアプリを解除しても問答無用でWindowsアプリを既定にしてくる。
その一部としてGoogle日本語入力からMS-IMEに変えてしまうが、これは「コントロールパネル>時計、言語、および地域>言語」でMS-IMEを削除することで既定にできる。
順序を変えて活かすのであれば、削除してから追加すれば良い。

ただ、Pavilion x2-10だと(with Bingだとか?)switcherが標準なので、Widnows+Spaceでのスイッチが可能。
ちなみに、Google日本語入力でかな打ちを選択していると、ソフトウェアキーボードでもかな打ちされるためいまいち実用性がなく(ソフトウェアキーボードにかな打ちに必要な文字がない)、MS-IMEに切り替えるしかないが、MS-IMEではソフトウェアキーボードではローマ字打ちになる。

Firefoxによるbtrfsの破壊トラブル

btrfsが頻繁に壊れるトラブルに見舞われた。
デスクトップがフリーズし、再起動するもディスクへのアクセスで非常に長い時間がかかる。
くりかえし再現したが、いずれもFirefoxの、特定のプロファイルでYouTubeを見ている最中だった。

btrfs scrubすると、ある特定のポイントに集中的にエラーが発見される。
結局、他のブラウザや、他のプロファイルでは発生しないが、
「問題のあるプロファイルを.mozillaごとリネームしても発生するし、問題のないプロファイルを同じファイル名にリネームしても発生する」という状態だった。

究明はできなかったが、とりあえず報告まで。

Yaourt(makepkg)の高速化

Manjaro Linuxでyaourtを用いたAURパッケージのビルドが非常に遅いので、設定を見なおしてみた。
設定ファイルは/etc/makepkg.confである。

CFLAGSとCXXFLAGS

実行速度のためのパラメータ。

-march=x86-64 -mtune=generic

となっているが、これは一般的なx86_64バイナリ(最適化されない)を生成する。
これを適切な値にすることで最適化されたバイナリを生成する。

通常は

-march=native

とするが、distccでは利用できない。

gcc -c -Q -march=native --help=target | grep march

とすることで最適な値を知ることができる。Xeon W3565ではnehalem, Godavari(A10 7870K)ではbdver3だった。

MAKEFLAGS

並列ビルドのための値が書かれているが、コメントアウトされている。

最適な値はコア数の倍とされているが、distccではコア数が限度のようだ。

BUILDENV

!がついているものは無効。ccacheを有効にするだけでもある程度違うか。

distcc

Arch Wikiの情報が正確で詳しい。

distccをセットアップした上で、makepkg.confの設定を変更する。
なお、DISTCC_HOSTSについて、Zeroconfを使う場合が色々書かれているが、単に.localで名前解決するだけの話であれば普通にホスト名を書ける。

しかし…

-j12でも結局ローカルとリモートの2コアしか使われていなかったようにみえて残念。