旅行からだいぶ時間が空いてしまいました・・・

倉敷の美観地区に行ってきました。
倉敷は美観地区以外は普通の都市だったりします。

美観地区は観光用に整備されているだけあって、とても洒落た街となっています。
野郎の一人旅にはちょっと厳しい街でしたw

瀬戸大橋を足元から見学してきました。

見上げるとこんな感じです。
大きすぎてイマイチ大きさがよく分からないです。

橋脚部分を見てみると、デカイの一言しか出ない。

よくもまあ、こんなものを作ったなとしか感想が出てきません。

—-
5月28日 写真差し替え

栗林公園…クリバヤシ公園だと思ってましたが、実はリツリン公園だそうです。
地名って難しいですね。・゜・(ノД`)・゜・。

この～木なんの木、知らない木～ って日立のCMに出てきそうな木ですね。

日本庭園の公園なんですがとにかくデカイ。


対岸からみるとこんな感じです。

高松の観光は、なにも計画してなかったのでgdgdでした(´Д` )
うどんが美味かったのと、単線・ディーゼルカー・1両編成・ワンマンな列車に始めて乗ったので良しとします。

鉄分多めな属性は無かったはずなんだけどな…

—-
5月28日 写真差し替え

記事の順番が前後してしまいましたが、寝台特急のサンライズ瀬戸の紹介です。
22時に東京を出発して翌朝の7時30分に高松に着く寝台特急です。


今回確保した切符はB寝台の1人用個室の「シングル」です。

設備は新し目で綺麗なんですが、狭いですw

シングルの部屋はこの図のように通路を挟んで両側に配置されてるため、事実上ベッドの幅しかない状態です。

サンライズは電車なので、機関車式の北斗星とかに比べて振動や衝撃が少なく乗り心地は良いです。以前に北斗星に乗った時は一睡もできませんでしたが、今回は寝ることができました。

他にも電力に余裕があるためか、B寝台でもコンセントが設置されておりスマフォが安心して使えるのがありがたいです。
続きを読む →

休暇が取れたのでサンライズ瀬戸で高松にきました。
実はうどんを食べたら岡山に移動するつもりだったのですが、気が変わったので高松観光です。

まずは、高松駅のすぐそばにある玉藻公園(高松城跡)です

高松城の石垣跡です。

積んである石はこれ位の大きさです。

比較のためにiPhoneを置いてあります。

昔から疑問なんですが、どうやってこんな岩を積み上げるんでしょうね？

—-
5月28日 写真を差し替えました。

DummynetのQoS設定が判らないので試験環境を用意して実際に動作を確認してみました。

試験環境では、QoSの効果を体感しやすくするためにpipeで128kbpsの帯域制限をかけています。
この状態で巨大ファイルを転送しながらsshで操作が可能か確認を行いました。

MASK無し

ipfw pipe 1 config bw 128k
ipfw sched 1 config type WF2Q+
ipfw queue 1 config sched 1
ipfw queue 1 ip from any to any

sshでキー入力を行ってもエコーが秒単位で返ってこない。
QoSは全く機能していない。

FLOW_MASK

ipfw pipe 1 config bw 128k
ipfw sched 1 config type WF2Q+
ipfw queue 1 config sched 1 mask all
ipfw queue 1 ip from any to any

キー入力の応答は即時に返ってくるが、たまに応答の遅れを感じる。

SCHED_MASK

ipfw pipe 1 config bw 128k
ipfw sched 1 config type WF2Q+ mask all
ipfw queue 1 config sched 1
ipfw queue 1 ip from any to any

キー入力の応答は即時に返ってくる。
応答の遅れなどは感じられない。

簡単なテストですが、QoSを動作させるには queueまたはschedでmask設定が必要だと判りました。
そして、schedでmask設定を行った方がより滑らかにQoSが動作しているように感じられました。

<20時57分 追記>
と言う訳で、DummynetでQoS設定を行う場合はschedのSCHED_MASKでトラフィックフローの振り分けを行うのが正解っぽいです。
スケジューリングアルゴリズムをFIFOにしたところ、SCHED_MASKを設定すると想定外の動作となりました。
FIFOならバーストトラフィックに帯域占有されるはずなのですが、WF2Q+と同様にsshのレスポンスが即時に帰ってきてしまいます。
FIFOとは思えない動作なので、想定通りの動作であったFLOW_MASKの設定が正しいようです。

この辺りは余裕が有る時に追試したいと思います。

FreeBSDのサーバーでQoSを使いたいのでDummynetを調べているのですが、
キュー、フロー、スケジューラの関係がイマイチ良く判らんのです。

やりたいことは単純で
・バーストトラフィックによる帯域占有を防ぐ
・サービスごとの重みづけは考えない
・全てのフローが公平に帯域を利用できる
これだけです。

この場合のDummynetの設定って、下記の4パターンのどれが正解なんでしょうか??

ipfw sched 1 config type WF2Q+
ipfw queue 1 config sched 1
ipfw queue 1 ip from any to any 

ipfw sched 1 config type WF2Q+
ipfw queue 1 config sched 1 mask any
ipfw queue 1 ip from any to any 

ipfw sched 1 config type WF2Q+ mask any
ipfw queue 1 config sched 1 
ipfw queue 1 ip from any to any 

ipfw sched 1 config type WF2Q+ mask any
ipfw queue 1 config sched 1 mask any
ipfw queue 1 ip from any to any 

とりあえず、パターン2の設定を採用してるけど想定通りの動作をしているか疑問(つД`)

さくらインターネットのVPSサービスがリニューアルされ新プランへの優待移行が
アナウンスされていましたので、休みを利用して新プランに乗り換えを行ってみました。
新VPSのリリース直後は在庫切れが発生するなど大盛況でしたが、1ヶ月も経つと
だいぶ落ち着いてきたようで、順番待ちなどもなく普通に契約できるようです。

移行作業はrsyncで全ファイルコピーしてサクッと完了なので、説明などは省略。
リモート作業だとやるのが怖いこの手の作業も、コンソール画面がつかえる
VPSなら気軽に作業できて楽すぎます。

新VPSではメモリやHDDの増加以外にvirtioが使えるようになっているようですが、
FreeBSDでは無効化してあるのでこの辺を参考にして有効化してみました。

で、virtioでDiskIOがどのくらい速くなるかというと・・・
設定前

# time -p dd if=/dev/zero of=/home/hoge bs=1M count=8192
8192+0 records in
8192+0 records out
8589934592 bytes transferred in 197.433158 secs (43508065 bytes/sec)
real 197.50
user 0.04
sys 42.14

設定後

# time -p dd if=/dev/zero of=/home/hoge bs=1M count=8192
8192+0 records in
8192+0 records out
8589934592 bytes transferred in 52.097458 secs (164882030 bytes/sec)
real 52.13
user 0.00
sys 35.38

HDDへの書き込みが4倍近く高速化しています。
DISK I/Oが忙しいサーバーではないですが、速さはチカラなのでvirtio有効で
運用していきたいと思います。