PuLP / NetBSD

NetBSD で PuLP(いきあたりばったり編)

(1) 必要なものを pkgsrc などを使って入れておく。

pkgsrc/lang/python27
pkgsrc/devel/py-pip
pkgsrc/math/coinmp (CBCなど)
他に(使うなら)pkgsrc/math/glpk など。

Python は 3 の方が良いのかもしれないけれど、他の用途で 2.7 使ってるので。

(2) PuLP は pkgsrc にないので pip で入れる。

# pip2.7 install pulp

とか sudo でやるとか、そんな感じで。

(3) /usr/pkg/lib/python2.7/site-packages/pulp/pulp.cfg.linuxを直接編集する。

PulpCbcPath を、pkgsrc の(coinmpの)cbc に書き換える。

#PulpCbcPath = %(here)s/solverdir/cbc/%(os)s/%(arch)s/cbc
PulpCbcPath = /usr/pkg/bin/cbc

(これをやらないと、デフォルトで site-packages/pulp/solverdir/cbc/linux/64/cbc とかを exec しようとして動かない。)

もうちょいマシな方法があれば教えてください。
Linux 用意するというのはナシで。

さくらVPS v4と旧プランの比較

dmesg の比較(diff -u の結果の一部)で – が以前から使っている旧プラン(大阪)、+ が現行v4(東京)。
ただし、NetBSD 7.0_BETA/amd64。

プランはいずれもCPU仮想2コア, メモリ1GB, HDD100GB。

qemu が違う(バージョンが上がってる)っぽい。

-Red Hat KVM (RHEL 6.3.0 PC)
+QEMU Standard PC (i440FX + PIIX, 1996) (pc-i440fx-trusty)

物理ハードが新しいっぽい。
(qemuのオプションで変えられるから本当かどうかは謎)

-cpu0 at mainbus0 apid 0: Westmere E56xx/L56xx/X56xx (Nehalem-C), id 0x206c1
-cpu1 at mainbus0 apid 1: Westmere E56xx/L56xx/X56xx (Nehalem-C), id 0x206c1
+cpu0 at mainbus0 apid 0: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, id 0x206d7
+cpu1 at mainbus0 apid 1: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, id 0x206d7

このへんも qemu のバージョンの違いか。

+hpet0 at acpi0: high precision event timer (mem 0xfed00000-0xfed00400)
+timecounter: Timecounter "hpet0" frequency 100000000 Hz quality 2000
 ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S0_] (20131218/hwxface-646)
 ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20131218/hwxface-646)
 ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20131218/hwxface-646)
-ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S3_] (20131218/hwxface-646)
-ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S4_] (20131218/hwxface-646)
 piixpm0 at pci0 dev 1 function 3: vendor 0x8086 product 0x7113 (rev. 0x03)
 timecounter: Timecounter "piixpm0" frequency 3579545 Hz quality 1000
 piixpm0: 24-bit timer
-piixpm0: LNKS: _SRS failed: AE_NOT_FOUND
-interrupting at ioapic0 pin 9
+piixpm0: interrupting at ioapic0 pin 9

virtio のデバイス認識順序が違う。
(略)

qemu のバージョン…

-uhidev0: QEMU 0.12.1 QEMU USB Tablet, rev 1.00/0.00, addr 2, iclass 3/0
+uhidev0: QEMU QEMU USB Tablet, rev 2.00/0.00, addr 2, iclass 3/0
 atapibus0 at atabus1: 2 targets
-cd0 at atapibus0 drive 0: <QEMU DVD-ROM, QM00003, 0.12.1> cdrom removable
+cd0 at atapibus0 drive 0: <QEMU DVD-ROM, QM00003, 2.0.0> cdrom removable
 cd0: 32-bit data port
-cd0(piixide0:1:0): using PIO mode 3
+cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
+cd0(piixide0:1:0): using PIO mode 4, DMA mode 2 (using DMA)

大きな違いはなく、どちらも安定しているようです。

VPSなので利用状況によって変動はあると思いますが、整数演算などは新しいv4の方が少し速く、ファイルI/O他は同程度のようです。

わざわざ乗り換えるほどではないですが、新規なら v4 で良いと思います。増設の場合は、同じリージョンでないと(仮想)スイッチが使えないので、どうするか迷うところ。

NetBSD/amd64 on さくらVPS

一番安いプランの試用を始めました。

何の変更もなく6.1 (RC) のISOで起動。今のところ負荷をかけても安定しているようですので、そのまま契約しそうな流れです。

ACPIやSMPは切らなくても問題ないようです。

CPU は Intel(R) Xeon(R) CPU E5645 と認識されますので、x86_errataも関係ありません。

NetBSD/amd64 on CloudCore VPS (3) 終了編

事実関係は以下の通り。

  • 2013年3月15日に再起動を伴うサーバのメンテナンス。一週間前に予告。内容は「仮想環境の再起動に時間がかかってしまう不具合」の解消とのこと。
  • メンテナンス後に再起動に失敗。以前使用したISOイメージも起動せず。
  • 起動しない症状と同じものを発見。 https://bugs.launchpad.net/qemu/+bug/897771
  • 問い合わせたところ、このバグを含むバージョンの qemu-kvm であるとの回答。qemu-kvm-1.1.1 以降では修正されている (http://tima-sls.imag.fr/viewgit/general/?a=commitdiff&p=QEmu&h=cdde6ffc27517bdf069734fbc5693ce2b14edc75) が、導入したホストOSの基本パッケージを使用するため、対応の検討はしないとのこと。

まあ、こちらは動作保証外のことをやってるし、個別にバグ修正を行わないというのもわからなくはないんであきらめるわけですが、「試用して動くことを確認して契約したら違う環境になってしまった」というのは結構困った話なのではないかな。

普通に提供されている環境で使う分には、サポートの返事も早いので悪くはないかと思います。念のため。

これが1年契約の初日とかであればもう少し頑張る可能性もあったのですが、もう3/4は使ったので更新なしで終了かなといったところ。次を探さないと。

build.sh ベンチ

NetBSD 6.0 リリース記念企画(嘘)

build.sh tools は済の状態から build.sh -j ${NCPU} -u -x distribution したときの build.sh started ~ ended までの時間計測大会。
(実際には -T, -O, -X -U あたりも指定してますが略)

Thecus N0503
CPU: Intel Atom N270 1.60GHz (NCPU=2)
Memory: 1GB
Disk: SSD1個でRAIDなし (80GB)
OS: NetBSD 6.0 i386
Time: 11:31:59

Thecus N2800
CPU: Intel Atom D2700 2.13GHz (NCPU=4)
Memory: 2GB
Disk: HDD2個でRAID1 (2TB)
OS: NetBSD 6.0 amd64
Time: 03:05:07
(-j 1 だと 07:13:29)

CloudCore VPS
CPU: AMD Phenom 9550 と表示されるけど KVM 上なので意味なし (NCPU=1)
Memory: 2GB
Disk: virtio上のld (100GB)
OS: NetBSD 6.0 amd64 (+x86_errata無効パッチ)
Time: 03:35:42

Thecus N0503

旧機種のN0503も入手しました。「3.5インチのディスクが3台」または「2.5インチのディスクが5台」も内蔵できます。

これも、CPUがAtomとのことなので普通のPCかと思いきや、VGA出力がない。

PCIスロット(Expressではない)が1つあるので、そこにビデオカードを挿して(あとはUSBキーボード等を繋いで)やると、普通のPCになるようです。手元になぜか未開封(1996年モノ)のMatrox Mystique (PCI) があったので、開封して挿してみたところ動きました。

N0503のマニュアル類に、PCIスロットについての説明がほとんどないですが、背面のフタ(ネジ4本)を外し、その中の外周のネジ8本を外し、前面フタを開けた中の黒いネジ4本(2.5インチ用のケージは外さないと見えない)を外せば、中身が背面から引き抜けます。

N2800と比べた場合、前述の通りディスクが多く積めて良い面もあるものの、旧機種なのでCPUが旧型だったりメモリや内蔵フラッシュが小さいです。CPUはAtom N270なので、64bit非対応。メモリ1GBでフラッシュは128MB。測ってないですが、省電力仕様ではあるかもしれません。

OSを入れ替えたりする用途にはオススメしませんが、一応やればできるということで。

“Thecus N0503” の続きを読む

Thecus N2800

Thecus N2800を購入しますた。

CPUはIntel Atom D2700でメモリ2GB。HDDは付いてませんが2台まで内蔵可能。LAN端子も2つあるので、家庭用のファイルサーバ兼ルータみたいな使い方がメインでしょうか。

最初から1GBのストレージにLinuxベースのNASのソフトウェアが入っていて、電源とネットワークだけ繋いだ後、他のPCからウェブブラウザで設定するようになっています。

が、それ以外はまったく普通のPCなので、ディスプレイ(アナログ)やらUSBキーボード・マウスやらUSB光学ディスクドライブやらを繋いで他のOSを動かすことも可能です。起動時にF2だったかを押せばよくあるBIOSの設定画面になります。

せっかくのNASのソフトウェアがもったいないですし、PCとしての性能は微妙ですので、Windows動かすとかそういう用途にはお勧めはしませんが。

というわけで(?)、お約束のNetBSDのdmesgなど。

“Thecus N2800” の続きを読む

NetBSD/amd64 on CloudCore VPS (2)

【追記 2013-03-19】以下は書いた当時の情報であり、2013年3月現在、ここに書いたような方法(x86_errata()の無効化)を用いてもCloudCore VPSでNetBSDは動作しません。

前のエントリを書いた後すぐに、ISOイメージからのbootができるようになりました。
(ただしbetaと書かれています。)

イメージアップロードに関する情報は、VPSのコントロールパネルのOSインストールの項にあります。秘密鍵ファイルのダウンロードもそこにあります。build.shで普通にiso-imageを作成し、NetBSDのsftpで以下のようにアップロードして起動できました。

$ sftp -i 秘密鍵ファイル名 -P 接続先ポート 接続先ユーザ@接続先ホスト
sftp> put ISOファイル名 /iso

併せてインストール時にvirtioのオン・オフが選べるようになり、NetBSDをvirtioオンでインストールした場合、ディスクやネットワークがvirtio経由のld, vioifになります。

アクセスの速さは…あまり変わりませんでした。

“NetBSD/amd64 on CloudCore VPS (2)” の続きを読む

NetBSD/amd64 on CloudCore VPS

【追記 2013-03-19】以下は書いた当時の情報であり、2013年3月現在、ここに書いたような方法(x86_errata()の無効化)を用いてもCloudCore VPSでNetBSDは動作しません。

KDDI Web Communications の CloudCore VPS、最安とまではいかないがそこそこ安いのと(トップにある945円/月は1年契約のときの値段ですが)、「提供予定」に普段使っているNetBSDが入っていたので様子を見ていたところ、

CentOS 5.8/CentOS 6.2/Fedora 16/Scientific Linux 6.2/Ubuntu 12.04 提供開始のお知らせ

なお、かねてよりOSインストール機能の一環にて提供予定としておりました、
「NetBSD」につきましてご報告させていただきます。

お客様からのご要望も高く、ご期待に添えるべく技術検証を重ねてまいりましたが、
サービスとして提供できるレベルに至らず、提供を見合わせることとなりました。
ご期待を寄せていただいていたお客様方へは深くお詫び申し上げます。
誠に申し訳ございませんでした。

とまあ、残念なお知らせが載っていたので、雲野コアさんに愛を伝えるべくどういう問題かを把握すべく試用してみました。

Back Street Net(神戸さんのサイト)のさくらVPSの例(とてもわかりやすくて助かります)を参考に if_wm.c にパッチをあてて、イメージを作成。
(VNCコンソールなのでinstallbootのオプション,console=com0,speed=115200は削りました。)

イメージの書き込みは、他のサポートされているOSのインストーラを途中で止めて、ネットワークの設定をしてイメージを転送してddでディスクに書き込むだけなので、特にトリッキーなテクニックを使う必要もなく比較的簡単です。私はFreeBSDのインストーラを使いました。(今後ISOイメージからの起動ができるようになるそうなので、もっと簡単になりそうです。)

すると、…起動に失敗します。

理由は、多分以下のスレッドのものと同じですが、
Current-Users archive: Boot fail as kvm guest
要は、sys/arch/x86/x86/errata.cのx86_errata()でCPUがAMDと判定されるとMSRへのアクセスがありますが、KVM上では通らないという事のようです。今のところ、AMDのCPU以外では何もしないようになっているので、さくらVPS(IntelのCPUに見える)等では問題ないということでしょう。

「KVM上の場合は何もしない」というコードをどう書くのが正しいかわからないので、x86_errata()が何もしないようにソースを直接書き換えて、再度コンパイルしてイメージを作り、さらにACPIとSMPをdisable(起動メニューの4番)したところ起動しました

一応、インストールした後負荷をかけてみたりしましたが、動いているようです。ただ、「サービスとして提供できるレベルに至らず」という文面が気になるところです。

契約して使うかどうかは迷っています。

何処をどう直すのがスジかという話ですが、KVMとかハイパバイザの類の上でどうせCPU依存の特殊なことはできないのであれば、それらがCPUの種類を隠蔽してくれるのがいい気がしますが、どうでしょうか。

“NetBSD/amd64 on CloudCore VPS” の続きを読む

binutilsが正しく作れないことがある件

NetBSDでmingw-w64を作っていて、クロスのgccもbinutilsも出来上がったのに、それでコンパイルしたバイナリをWindowsに持っていって実行しようとすると“not a valid WIN32 application”(日本語版だと「有効なWIN32アプリケーションではありません」)などと言われる。

結論から書くと、binutilsのldのldscriptsが正しく作れていなかった。

configureでSHELLとして何故か/bin/shではなく/bin/kshが選ばれるが、このシェルだとgenscripts.sh(から呼ばれているscripttempl/pep.scなど)がエラーになる。

エラーなので止まってくれれば良いのだが、実際にはそのまま進んで、make installすると途中で打ち切られた(実質中身のない)ldscriptsがインストールされてしまう。

出来上がったgcc+binutilsを使ってコンパイルしたときに、一見すると正しいPE32(+) executableに見えるモノが出来てしまうので、なかなか原因がわからなかった。しかし、以前にも、違うパターンとはいえ同じ部分でハマったことがあったのだった。http://est.ceres.ne.jp/2008/07/02/post_241/…すぐに気がつくべきだった。

回避方法としては、binutilsのconfigureを実行する際、CONFIG_SHELL=/bin/sh …/configure …とでもすれば良い。多分。