月別アーカイブ: 2009年2月

Windows7 beta で UQ WiMAX

以前申し込んだ UQ WiMAX、サービス開始当日 26日に端末が届きました。
モニターではなく購入です。

USB タイプの UD01SS を VAIO type P + Windows7 で使ってみます。

WiMAX USB TYPE UD01SS

uqwimax
↑何となく取れそうに見えた先端の蓋部分はやっぱり外すことができた。アンテナ端子?

●Windows7 Beta へのインストール (UD01SS)

ドライバはそのままで OK。ユーティリティの方は OS のバージョンではじかれました。
互換モードで Windows Vista を指定するとインストールできます。

・ドライバ

UD01SS を差し込むだけで認識し、組み込まれているドライバのインストーラが
起動します。最初は USB の CD-ROM ドライブとして認識されるようです。
あとは手順に従うだけ。Windows7 beta でも特に問題はありません。

・ユーティリティ

ユーティリティソフトは付属の CD-ROM に入っています。
Web からも落とせるようです。
CD-ROM の Setup.exe をそのまま実行するとエラーがでるので、先にプロパティから
「互換性→互換モード→Windows Vista」を選んでおきます。

●接続

WiMAX GO のアイコンをクリックするだけ。
ユーティリティを起動しておけば電波状況を表示し、圏内なら接続します。
特に設定もなくアダプタの抜き差しなども判定してくれるので手軽です。
Windows7 beta でも問題なく使えています。

接続や切断の管理も不要で、中断する場合も PC のモニタを閉じてスリープする
だけで大丈夫。再接続も自動で行われます。
スリープ解除後の再接続は、端末の接続チェックと初期化が入るので数秒待たされます。

●速度

VAIO type P + Windows7 beta + Chrome
という特殊な環境なので参考程度に。

・下り
笹塚駅 2Mbps 前後
麹町 4Mbps ~ 9Mbps (測定サイトによって異なる)

測定サイトによって結構ばらつきがあります。
駅のホームで試した場合も、場所によって結構違うし電車の通過によって
影響を受けることもありました。

つながらない場合は完全に圏外になります。つながらない場所は結構あります。
最初に試したサイトが低い数値しか出さなかったのであまり参考にならないかも
しれませんが、安定して圏内を維持する場合は 1Mbps 以上出てるようです。
ブラウザを使ってる分には普段無線 LAN でつないでるのと変わらず速いです。

関連エントリ
UQ WiMAX 申し込み

VAIO type P でモニタ出力

ミニノートを持ち歩いていて、普段ネット端末やメモ機として使っています。
この場合外部ディスプレイ出力を使うことがまずないのですが、でもごくまれに
必要になることがあります。

小型なノートPC で特殊なコネクタを採用している場合は少々やっかいです。
専用アダプタや専用ケーブル経由で接続しなければならず、
かさばるし、滅多に使わないのに専用品を購入しなければならないし、
必要になったときにすぐ手に入らないかもしれません。

また実際に必要になって購入を考えると結構高いものです。
MobileGear2 の時はモニタ用ケーブルだけで 4000円、利用回数一回きり。
LOOX U50 店頭モデルでは本体同梱、使ったのは 2~3回。
VAIO type P の場合別売りで VGP-DA10 4980円 (LANアダプタ兼用)。

そこで専用品ではなく USB 接続のモニタアダプタを使うことにしました。
これだと機種を変えても使い回せるし、普段はデスクトップ PC につないだりと
他の用途でも使えます。

IO DATA USB-RGB
IO DATA USB-RGB/D

最近 USB で接続できる液晶モニタも話題になっていますが同じ原理のようです。

ぼくらは「USB-RGB」を誤解していたかもしれない (1/4)

USB バスパワーで動作するので外部ディスプレイ出力アダプタとほぼ同じ感覚で使え
そうです。

実際に試したところ、現在の Windows7 beta 1 では正しく動作しませんでした。
一応ソフトウエアのインストールが可能で、絵は出るものの解像度やモード
切り替えなどが出来ません。

VAIO type P にクリーンインストールした Vista の方では正常に動作しました。
ただし VAIO type P の場合あらかじめ Aero を切っておいた方がよいです。
接続時にエラーになりました。
タスクトレイアイコンからのモード切り替えも可能で 640×480 も使えています。

小型プロジェクター ADTEC AD-MP15A との接続も確認。
800×600 でもきちんと表示できました。

純正アダプタによる直接出力と比べると描画速度が多少遅いはずですが思ったより
気になりません。打ち合わせなどで文書や資料を表示するには十分です。

関連エントリ
ADTEC AD-MP15A 小型プロジェクター

ミッキーの測定

マウスの感度を示す単位はミッキーというらしい。
じゃあどうやってミッキーを測るんだろう、ということで簡単に試してみました。

wikipedia マウス

マウスの入力値の取得には DirectInput を使用します。
DirectInput の Buffer モードを使って移動量の変化を取り出します。そのままだと
DInput の取得値にも速度に応じて加速がついてしまうので設定が必要です。

・コントロールパネルのマウスから
  ポインタオプションのタブ→速度のグループで
  「ポインタの精度を高める」のチェックを外す

これで加速補正が無くなります。
「ポインタの速度」は DirectInput の値に影響しません。

マウス付属のドライバやユーティリティは使わず、Windows 標準のドライバのみ
使用しています。

こんな感じでマウスにガイドを付けます。
出来るだけ水平、または垂直に移動できるように。

d2dmouse

カウンタをリセットしてだいたい 1インチ分だけ移動して得られた値を調べます。
精度が高いため手で試してもかなり誤差が入り厳密な値はとれません。
以下数値はかなりいい加減です。

だいたい 800~1000 くらいの範囲の値を返します。
おそらくこれがマウスセンサーのカウント値です。
1インチ移動する間に何回センサーの On/Off をカウントできるのか、どれだけ細かく
動きを読み取れるのか表す単位として cpi (count per inch ) があります。
メーカーによっては dpi (dot per inch) と表現されているものもありますがおそらく
同じものです。

テストしたマウス
(1) BlueTrack
Microsoft Explorer Mini Mouse
1000dpi/8000fps

結果
・800~1025 (8~10.2ミッキー)

(2) Laser
SIGMA APO SLATWRF
800,1600cpi/6600fps

結果
・800cpi モードで 800~900 (8~9ミッキー)
・1600cpi モードで 950~1450 (9.5~14.5ミッキー)

◎速く動かした方が値が小さい

センサーの読み取りエラーが発生しやすくなるためと思われます。速く動かした場合の
耐性を表す目安が、マウススペックに記載されている fps となるようです。

◎精度を切り替え可能な場合

低い cpi モードの方がほぼ期待通り、安定した数値になっています。

高い cpi モードの場合、全体的に数値は増えますがスペック通りの上限には達しま
せんでした。材質の相性や速度の影響を受けやすくなっているためと思われます。
精度は上がるがよりノイズを含んでいる状態といった感じでしょうか。

◎相性

机やマウスパッドの材質とセンサーの相性でかなり変わります。
反応が悪いと半分くらいの値になることも。

カタログスペック通りと想定するなら、800cpi(dpi) のマウスは 8ミッキーでカウント
値からマウスの移動量がわかります。もし正確ならば、マウスを使って長さを測る
こともできるでしょう。

でも実際は机やマウスパッドとの相性と速度の影響が大きく、頻繁に読み取りエラーが
発生していることがわかります。平均ミッキーはこれらの条件によって変わります。
特に速度は重要なパラメータで、cpi だけでなくマウスの性能として fps も併記
されているのはそのためでしょう。

きちんとツール化して調べれば、最もエラーの少ないマウスパッドの組み合わせを
探し出すなど活用できそうです。

参考にさせていただいたページ
その37.Windows標準のポインタ(カーソル)速度の変遷
Windows XP でマウス ポインタの加速を調節する方法

// DirectInput
DWORD	elems= 32;
DIDEVICEOBJECTDATA	data[32];
HRESULT	hr= iDevice->GetDeviceData( sizeof(DIDEVICEOBJECTDATA), data, &elems, 0 );
if( FAILED( hr ) ){
    return;
}
DWORD	ac= elems;
for( DWORD i= 0 ; i< ac ; i++ ){
    switch( data[i].dwOfs ){
    case DIMOFS_X:
	PositionX-= *(int*)(&data[i].dwData);
	break;
    case DIMOFS_Y:
	PositionY-= *(int*)(&data[i].dwData);
	break;
    }
}

Debian lenny 設定メモ (2) mercurial

Mercurial のサーバー設定まで

●Debian install

Debian — The Universal Operating System

5.0 Lenny が release されたので “stable” になりました。
今回は Network install より Small CDs の i386
debian-500-i386-netinst.iso を使用しています。

VirtualBox 2.1.4 を使っています。
手順は 前回 と全く同じです。

●Debian の設定

# apt-get update
# apt-get install ssh

以後 putty 経由

# apt-get install mercurial
# apt-get install hgsvn

subversion から

# svn ls https://SVNSERVER/svn/src2

# mkdir /var/lib/hg
# cd /var/lib/hg
# hgimportsvn https://SVNSERVER/svn/src2 src2
# cd src2
# hgpullsvn
# chown -R www-data.www-data src2

SSL 設定

# apt-get install ssl-cert
# make-ssl-cert generate-default-snakeoil –force-overwrite
# a2ensite default-ssl
# a2enmod ssl
# /etc/init.d/apache2 restart

Mercurial 設定

# mkdir /var/www/hg
# cd /var/www/hg
# cp /usr/share/doc/mercurial/examples/hgweb.cgi ./index.cgi
# chmod 700 index.cgi
# chown www-data.www-data index.cgi
# vi index.cgi

application = hgweb(“/var/lib/hg/src2”, “src2”)

# vi /etc/apache2/sites-available/hg-src2

Alias /hg /var/www/hg

 DirectoryIndex index.cgi
 AddHandler cgi-script .cgi
 Options ExexCGI
 AuthType Basic
 AuthName "hg repository"
 AuthUserFile /etc/apache2/hg.passwd
 Require valid-user

# htpasswd -c /etc/apache2/hg.passwd USER
# a2ensite hg-src2
# /etc/init.d/apache2 restart

# vi /etc/mercurial/hgrc

[web]
allow_push = *

●確認

Windows Mercurial-1.0.2 にて

C:\hg> hg clone https://HGSERVER/hg

参考ページ
Setting up a Mercurial CGI Server
MercurialのCGIサーバをセットアップする
hgsvn

WindowsMobile のメモリ

WindowsMobile6.x がもう一世代継続されるようです。

米マイクロソフト、スペインで「Windows Mobile 6.5」発表

今でもプラグインが多いと SIP が読み込めなかったり切り替わらなかったり、
ブラウザのようなメモリを多く消費するアプリが不安定になったりしています。
WindowsMobile6.x のカーネルは WindowsCE5.2 で、WindowsMobile5.0 とそれほど
大きく変わっていません。
下記のページで詳しく解説されています。

Windows CE .NET の高度なメモリ管理

これを見ると CE4~5 のメモリ管理は下記の構造になっていることがわかります。

(1プロセス 32MB × 32プロセス) + 32MB の XIP DLL 空間 (ROM DLL)
  + ラージメモリ空間(992MB) + カーネル空間(2GB)

CE の限界は、上記の通り 1プロセスあたりのメモリ空間が 32MB に制限されていること。
最近の端末では 128MB~256MB の RAM を搭載していますが、1つのアプリケーションが
メモリ空間的に限界に達しているときは、いくら物理メモリを増やしても効果がない
ことがわかります。(desktop Windows でも 32bit OS だと 2GB まで、という制限に似ています)

32MB の XIP DLL 空間は、ROM にあらかじめ組み込まれている DLL を配置するための
領域だそうです。system の共有 DLL が XIP 空間に配置されている場合は 32MB の
プロセス領域を消費しません。

ROM に含まれていない (XIP でない) DLL は XIP 空間に配置できません。
こちらはプロセスのメモリを消費します。さらに DLL はプロセス間で共有されるために
ロードしたアドレスが固定されてしまうようです。
よって SIP プラグインなど、後から追加した dll が多数読み込まれている場合は、
各アプリケーションで使用可能なメモリ空間を食いつぶしてしまう可能性があります。

たとえば XIP でない DLL の合計が 16MB あって、かつ最もよく使われる dll が
一番下位のメモリにロードされてしまった場合。またはアプリケーションが複数の
dll をロードする構造の場合、最悪アプリケーションが使用可能なメモリ空間も
16MB になってしまうということです。

これらのこの問題に拍車をかけているのがもう 1つの制限、プロセス数の上限が
32個ということ。常駐するアプリケーションはプロセスを消費しないようサービス
として dll 化することが推奨されていているため、dll 空間を余計圧迫している
可能性があります。また単一のプロセス空間を取り合うため、dll を配置する
サービス用の空間自体も限界に達してしまう可能性もあります。

常駐する dll が多い場合、追加で dll 自体をロードできなくなる場合があること、
またブラウザなどの大きなアプリが不安定になる可能性があることがわかります。
メモリが大量にある場合、dll の共有はかえって逆効果なのかもしれません。

ただ実際に touchkeysip が読み込まれなくなる場合、どの段階で限界が来ており
どこのメモリ確保でエラーが出ているのかきちんと調べたわけではないので、
上の説明もいろいろと憶測が含まれています。あらかじめご了承ください。
単に touchkeysip が悪いだけの可能性もあります。

データ領域に限っていえば、ラージメモリ領域を使用することが出来るためまだ余裕は
ありそうです。上の MSDN のページに書いてある方法で大きなメモリブロックを
まとめて VirtualAlloc で予約すると、ラージメモリ領域に配置されるとのこと。

・常駐する dll を減らす。
・常駐する dll は一番先に読み込ませておく。
・アプリが消費するヒープメモリは自分でラージメモリから確保する。
・アプリを使い終わったらすぐ終了させる。特に独自の dll を使うもの。

等が有効かもしれません。

WindowsCE6.0 (WindowsMobile7) 以降は一般的な 32bit OS と同じ 2GB に拡張され、
プロセス数の制限もなくなるはずです。逆に普通の Windows に近づくので
CE である必要性が徐々に薄れていくような気もします。
先があることがわかっている中に出る 6.5 は Me を思い出してしまいます。

関連エントリ
emobile EM・ONE 使い切れないメインメモリ