皇紀2676年2月2日に届いた。艦これタブレットの三代目となる。
dynabook tab s38/26mの様にパケ詰まり症状になる事もなく、電車内でもサクサク動いて非常に快適だ。
難点はスピーカーから出る音で、最初、艦これ起動したら、音がふらふらして「接触不良の初期不良か？」と思ったが、イヤホンでは不具合は無く、スピーカーのプロパティのIntel Sound EqualizerをOFFにしたら、直った。
まあ、昨年に
PCなどの電子機器の保証規約には、「分解」などハードウェアの故障につながる危険性の高い行為を禁止し、このような行為を行えば保証が適用されない場合がある旨の禁止規定があります。DELLのフォーラム
情報源: VLCをインストールするだけでスピーカーの保証は無効というDELLの対応に対して掲示板で議論が白熱 – GIGAZINE
と、VLCでGain上げて再生を続けていると小さな音でも歪むようになり、最後にはスピーカー破壊されるってネタがあったので、すごく内蔵スピーカーのガードに力を入れ過ぎるほど入れているのだろう。
おかげで、全ての効果を無効にしてもゲームの音の立ち上がりが小さいという現象が出るが、所詮はタブレットのスピーカーなので、その辺は余り気にしない事にする。
まあ、Windows 10 でAterm mr03lnで移動中もサクサク動くという事は、パケ詰まり現象を起こしていたdynabook tab s38/26mに問題があるという事だな。
そもそもパケ詰まりという現象は、パケット通信を行うAir-H”とかモバイル端末で問題になっていた。
通信パケットは128バイトだが、実際の通信ではそれに満たない通信も発生するので、移動体通信の制御としては、できるだけ通信費を喰わないように、128バイトに達するまでデータを貯めて、貯まったら送信するという事をやっている。
32バイト×2を2パケットで送信するより、バッファに貯めて暫く待って、次の送信データが来ないようなら送り出すという事をやれば、2パケット食うところを1パケットで済ませる事ができて、通信費の節約になるのだ。
で、次の送信データを待つというところがミソで、これが余りにも長いと、処理終了までの待ち時間が増え、操作性が非常に悪くなる。
そこで想像だが、移動体通信のこの制御を、タブレットでやっているような気がする。要は、送信データが貯まるまでWiFiのRFの電源落として電力をケチり、相手から受信データが来ようが一切無視するという制御。
TCP/IPは送信タイムアウトでデータを再送信するという手続きなので、タブレットが受信を一切無視して、送信バッファが貯まるまで待つという処理をしても、理論的には処理が遅くなるがデータが受け取れるはずという理屈。
実際問題として、モバイルバッテリを接続すると、こういうパケ詰まり現象がパタっと無くなるので、明らかに電池駆動時にWiFiに「操作不能になっても構わないから電池をケチれ！」と、不必要な省電力制御が行われている事は間違いない。
仮にこういう処理をやってるとしたら、「ふざけんな！」って感じだが、操作性を犠牲にしてでも電池持ちのカタログスペックを上げるという製造業特有の「手段の為には目的を忘れる」というバカさ加減に呆れるばかり。
まあ、DELLにしても、スピーカーはガードするけど、イヤホン出力は変な制御してなくて、自分とこのハードが壊れるのはダメだが、それ以外なら構わないという姿勢も責任回避のハードメーカーで微笑ましい 🙂
Venue8は1920×1200ドットという、わしのデスクトップ環境よりも解像度が高いが、8インチでズーム100%でみたらアイコン小さいは文字が小さいわで使い物になりまへん。その意味では1280×800でも大差無い。
艦これタブレットとしては結構いいものだが、dynabook tab s38/26mが余りにもクソ過ぎたという事だな。