2011年7月19日 (火)

ULTRA WiFi SoftBank 007Zを使ってみた

ULTRA WiFi SoftBank 007Zを使ってみた。

まずは、スピードを測定。

=== Radish Network Speed Testing Ver.3.2.2 - Test Report ===
使用回線:SBM UlltraSpeed Main
プロバイダ:SBM
測定地:千葉県印西市
------------------------------------------------------------
測定条件 
 精度:高 データタイプ:標準
下り回線
 速度:20.41Mbps (2.552MByte/sec) 測定品質:93.3
上り回線
 速度:1.143Mbps (142.9kByte/sec) 測定品質:75.2
測定者ホスト:**************.*.tss.access-internet.ne.jp
測定サーバー:東京-WebARENA
測定時刻:2011/7/18(Mon) 17:16
------------------------------------------------------------
測定サイト http://netspeed.studio-radish.com/
============================================================

うーん、田舎なのにあんまし速くない?

2011年7月 6日 (水)

ココログもIPv6対応なんだってさ。

ココログでIPv6対応致しました。
http://info.cocolog-nifty.com/info/2011/07/ipv6-bff1.html
だって。

もうv4もアドレスなくなってきたからねぇ。

でも、TBの拒否とかも、IPv6のアドレスで書けるのかしら?

家のv6の環境も、実稼働できるように整え直さないといけないな。
構成変更すんの、めんどくさー。

2010年8月15日 (日)

長年の癖

パソコンのキーボードを使い始めて、もう何十年だろうか。
どうも、かな漢字変換をする際に、変な癖が、ついてしまっているようだ。

勝手に、切りの良い箇所で、意識をしないで、enterキーを押してしまうのです。
長文を一気に、入力できない体になっていたのですね。

日本語変換の精度を確かめてみようと、長文を入力しようとしたのですが、
体が、勝手に、スペースとエンターを叩いてしまうのです。

昔は、漢字かな変換の精度があまり良くなくて、単漢字や単文節変換を
していたのですが、最近は連文節変換が主流のようです。

どうしても、昔の癖が抜けていないようで、
熟語単位や、単文節の単位で、変換を始めてしまうようなのです。

最近は、精度が良いので、無理に分節を切らなくても良いはずなのですが、
どうも、苦手です。

句読点を打つと、確定したくなる衝動が抑えられません。
ポンコツだね。

そんなことを思う、暑い夏の夕暮れ。

2010年7月 9日 (金)

twitterのクライアントをいろいろ試す

twitterをやってみたのだが、どうも、twitterの公式のページだけではなくて、
いろいろクライアントがあるようなので、試してみる。

TwitterクライアントのまとめWikiを作っている方が、いたので、有り難く参考にさせてもらう。

WindowsやMacでも使うので、WEBクライアントか、AIRのクライアントがいいなと
いうことで、そのあたりを試してみた。

で、いまのところのお気に入りは、
WEBクライアントが、ついっぷる、で
AIRクライアントが、とある触手の超百合砲、でした。

iPhone用は、TweetMeです。

いろんなのがでてるんだねー。
Ajaxでも、ここまでできるんだねー。ふーん。

2010年6月10日 (木)

グローバル固定 IPv6 アドレス割当型トンネル接続実験サービスを試す

今度、PacketixVPNを使って、ソフトイーサと筑波大学とで、
IPv6の実験サービスを、始めたようだ。
http://www.softether.co.jp/jp/news/100607v6.aspx

WindowsXPで試した。仮想VPNのインターフェイスにIPv6をバインドされて、
接続すれば、IPv6のアドレスが、割り当てられる。

でも、なんかグローバルアドレスが、2つ割り当てられるみたいなんですよね。
なんでだろ?
http://v6ip.tsukuba.wide.ad.jp/help/client.aspx
上記の公式サイトの接続例でも、2つ割り当てられているようだから、そういうものかもしれないけど。


いままで、Feel6を利用していたので、この2つのv6間のルーティングが
どうなっているか、調べてみた。

v6ip.tsukuba.wide.ad.jpで割り当てられた端末から、
feel6宛てのtracerouteをやってみた。

結果は、以下のとおり。(一部伏せてあります)

Tracing route to 2001:3e0:xxx:x:x3x:xxxx:xxxx:xxxx
from 2001:200:1c8:xx:xxxx:xxxx:xxxx:xxxx over a maximum of 30 hops:

1 39 ms 23 ms 24 ms 2001:200:1c8:xx::1
2 16 ms 16 ms 17 ms 2001:200:0:7c08::1
3 23 ms 22 ms 23 ms 2001:200:0:7c01::2
4 22 ms 22 ms 22 ms ve44.foundry6.otemachi.wide.ad.jp [2001:200:0:10::141]
5 24 ms 24 ms 24 ms alala1.otemachi.wide.ad.jp [2001:200:0:1802:212:e2ff:fec0:3f09]
6 22 ms 24 ms 25 ms 2001:200:0:fe00::1275:0
7 23 ms 23 ms 25 ms 2001:278:0:2020::8
8 128 ms 144 ms 128 ms 2001:278:0:2020::15
9 141 ms 142 ms 142 ms xe-0.paix.plalca01.us.bb.gin.ntt.net [2001:504:d::6]
10 222 ms 133 ms 127 ms ae-1.r20.snjsca04.us.bb.gin.ntt.net [2001:418:0:2000::1a2]
11 249 ms 138 ms 142 ms as-1.r20.osakjp01.jp.bb.gin.ntt.net [2001:218:0:2000::7e]
12 127 ms 133 ms 133 ms ae-4.a20.tokyjp01.jp.ra.gin.ntt.net [2001:218:0:6000::186]
13 146 ms 146 ms 127 ms xe-1-1.a14.tokyjp01.jp.ra.gin.ntt.net [2001:218:2000:2000::32]
14 144 ms 127 ms 281 ms ge-0-0-0.a06.tokyjp01.jp.ra.gin.ntt.net [2001:218:2000:2000::8e]
15 128 ms 138 ms 145 ms ge-0-0-0.a06.tokyjp01.jp.ra.gin.ntt.net [2001:218:2000:2000::8e]
16 132 ms 127 ms 146 ms 2001:218:2000:5000::6
17 129 ms 146 ms 133 ms 2001:3e0:0:30:203:e4ff:fed6:d01b
18 143 ms 134 ms 148 ms 2001:3e0:0:30:203:e4ff:fed6:d01b
19 154 ms 153 ms 159 ms 2001:3e0:xxx:x:xax:xxxx:xxxx:xxxx
20 141 ms 161 ms 150 ms 2001:3e0:xxx:x:x3x:xxxx:xxxx:xxxx

Trace complete.

なんじゃこりゃ。太平洋を行って来いをしているじゃないかぇ?
どっかのルータのルーティングがおかしいんじゃね?

というわけで反対向きも試してみた。(feel6 -> packetix-v6)

traceroute6 to 2001:200:1c8:xx::1 (2001:200:1c8:xx::1) from 2001:3e0:xxx::xxx:xxxx:xxxx:xxxx, 64 hops max, 12 byte packets
1 2001:3e0:xxx::xxx:xxxx:xxxx:xxxx 1.180 ms 0.937 ms 1.671 ms
2 2001:3e0::30:203:e4ff:fed6:d01b 15.596 ms 14.570 ms 14.643 ms
3 feel6-gate.feel6.jp 15.138 ms 16.638 ms 20.445 ms
4 2001:3e0::c:204:4eff:fea0:7854 16.016 ms 19.340 ms 16.381 ms
5 fa-2-1.r01.tokyjp01.jp.b6.gin.ntt.net 17.428 ms 19.924 ms 20.435 ms
6 ge-8-12.a15.tokyjp01.jp.ra.gin.ntt.net 17.886 ms 20.390 ms 16.498 ms
7 ge-8-2.a15.tokyjp01.jp.ra.gin.ntt.net 125.735 ms 127.485 ms 128.182 ms
8 2001:200:0:7c01::1 132.835 ms 131.748 ms 131.197 ms
9 2001:200:1c8:83::1 132.151 ms 132.595 ms 132.611 ms

あれぇ? こっちは、ホップ数は、まともな感じがするけど、
でも、hop6と7の間が、なんかおかしい感じがするぞ。

なんでこんなに急激に遅くなるんだ。これも、太平洋を越えた感じの応答時間だな。。
見た目は、国内で処理されてそうなんだけど。。

NTT-comの経路が変なのかなぁ?

誰か、直してくんないかなぁ。。

なんか、昔インターネットが発展途上のころを思い出すわ。
IPv4でも、むかーしは、こんなことよくあったなーと思って。

アメーバ ピグが使ってるTCPポートを調べる

Ameba Piggをファイアウォールを通して、開いたら、通信がタイムアウトする。

あれぇ?もしかして、80、443以外使っているのかなぁ??
と使っているポートを確認してみた。

どうも、ファイヤウォールのログを見ると、TCP 843とTCP 1935で通信しようとしているようだ。
こいつらをFWのルールで通してやれば、ちゃんと通信ができた。
もしかしたら、843はなくてもいいかも。あと、UDPは使うの?とかは、知らない。。(笑)

宛先は、59.106.4.xとか59.106.5.xとかのIPアドレスを使っているようだ。

ピグは、フラッシュを使っている。なのでフラッシュでよく使うポートで通信してるようだ。
どうも、TCP843は、Flash socket policy serverとの間で、使うようだ。
マスターソケットポリシーファイルというものを取りにいくだけのようだが。

TCP1935は、Flash Real Time Messaging Protocol (RTMP) というもののようだ。
UDPも使うことがあるらしい。

ふーん、知らんかった。フラッシュとか、使ったことないからなぁ。
時代に取り残されていってるわ。。

1935は、Ustreamとかでも使うみたいだね。フラッシュ使ってるからかな?

なんか、こんなの調べるのは、以前は何とも思わなかったのに、
最近、面倒くさーって思うようになっちゃったなぁ。。

年取ったってことなんかなぁ。。悲しい。

P.S.
海外版のAmeba Picoのほうも、ポートは同じかな。
サーバのIPは、違うかもしれないけど。
気が向いたら、調べてみっかな。

2010年2月27日 (土)

Baidu Typeで、全角の半角の切替方法

先日からBaiduTypeを入れているのだが、
全角と半角の切り替えをどうやってすればいいのかわからずに
マウスで「あ」と「A」を切り替えていたのだが、
今日、SHIFTキーを押せば、切り替わるということを知った。

あー、これで、大分、ストレスなく入力ができるようになるな。

なんか、別窓で、変換の候補が表示されるのは、何か変な感じ。
でも、入力した場所と、変換窓が離れているので、視線を頻繁に動かすことになり、
ちょっと疲れる。

でも、Windowsの固定キーの設定をdisableにしておかないと、
シフトキーを乱打すると、固定キーの機能が有効になってしまうなり。

あと、CAPSLOCKされていると、半角入力になってしまうようだ。
仕様?

気付かずに、CAPSがONになっていて、なんで、入力できんのだ?と思った。

でも、私が入力する程度の文章であれば、変換は、ほどんど、ストレスなく行われる。

あと、これが、あったらいいなというのが、
私は、とてもキーボードの打ち間違いが多くて、入力をしなおすことが多いのだが、
よくある、タイプミスを推測して、「たぶんこれでしょ?変換」みたいなことをしてくれると、
とっても、ストレスが減って、いいかも。

タイプミスは、人それぞれで違うので、難しいかもしれないけど、挑戦してみてほしいな。
グーグルでも、検索キーワードで、似たようなことができているので、
たぶんできるんじゃないかと思うんですよねー。


2009年6月27日 (土)

WiMAXを使って、実家のテレビを見るの巻き。

実家には、ネットワーク接続型TVチューナーユニットがおいてあって、
もともと、インターネット経由で参照できるようにしてあった。

それをWiMaxに変更しただけ。

移動せずに、みれば、家のブロードバンドあまりかわらない。

世の中進んだもんだ。。

2009年4月29日 (水)

WiMAX試してみました。第2弾

前回は、移動しながらのテストだったので、いい結果がでなかったので、
今度は、じっくり腰を落ち着けて、テストをしてみました。

場所は、西新宿1丁目交差点付近ビルの中

ビルの中ではあるが、思ったより、アンテナの数が立っている。
アンテナ3本

早朝なので、トラフィックが混んではいないと思う状態。

移動していないし、電波の状態も良いらしく、接続も切れないし、安定している。

速度もまずまず。家にいるときと同じように、ストレスを感じず、使える。

そうかぁ。移動しなきゃいいんだねー。

あとは、早朝なので、APが混んでいなかったのもよかったのか・・


以下、スピードテストの結果

------ BNRスピードテスト (ダウンロード速度) ------
測定サイト: http://www.musen-lan.com/speed/ Ver3.5001
測定日時: 2009/04/29 04:58:46
回線/ISP/地域:
--------------------------------------------------
1.NTTPC(WebARENA)1: 672.933kbps(0.672Mbps) 84.08kB/sec
2.NTTPC(WebARENA)2: 632.083kbps(0.632Mbps) 78.98kB/sec
推定転送速度: 672.933kbps(0.672Mbps) 84.08kB/sec

------ BNRスピードテスト (ダウンロード速度) ------
測定サイト: http://www.musen-lan.com/speed/ Ver3.5001
測定日時: 2009/04/29 04:59:57
回線/ISP/地域:
--------------------------------------------------
1.NTTPC(WebARENA)1: 663.709kbps(0.663Mbps) 82.93kB/sec
2.NTTPC(WebARENA)2: 639.598kbps(0.639Mbps) 79.92kB/sec
推定転送速度: 663.709kbps(0.663Mbps) 82.93kB/sec

------ BNRスピードテスト (ダウンロード速度) ------
測定サイト: http://www.musen-lan.com/speed/ Ver3.5001
測定日時: 2009/04/29 05:00:34
回線/ISP/地域:
--------------------------------------------------
1.NTTPC(WebARENA)1: 681.938kbps(0.681Mbps) 85.21kB/sec
2.NTTPC(WebARENA)2: 708.377kbps(0.708Mbps) 88.51kB/sec
推定転送速度: 708.377kbps(0.708Mbps) 88.51kB/sec

それでは、アップロードのほうも。。


------------ Broadband Networking Report ------------
<アップロード速度>
データ転送速度: 752.23kbps (94.02kB/sec)
転送データ容量: 800kB
転送時間: 8.508秒
-----------------------------------------------------
測定日時: 2009年04月29日(水) 05時01分
測定サイト: http://www.musen-lan.com/speed/
利用ブラウザ: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30618; Lunascape 5.0.4.0)
-----------------------------------------------------


------------ Broadband Networking Report ------------
<アップロード速度>
データ転送速度: 753.03kbps (94.12kB/sec)
転送データ容量: 800kB
転送時間: 8.499秒
-----------------------------------------------------
測定日時: 2009年04月29日(水) 05時02分
測定サイト: http://www.musen-lan.com/speed/
利用ブラウザ: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30618; Lunascape 5.0.4.0)
-----------------------------------------------------


------------ Broadband Networking Report ------------
<アップロード速度>
データ転送速度: 724.81kbps (90.60kB/sec)
転送データ容量: 971.33kB
転送時間: 10.721秒
-----------------------------------------------------
測定日時: 2009年04月29日(水) 05時03分
測定サイト: http://www.musen-lan.com/speed/
利用ブラウザ: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30618; Lunascape 5.0.4.0)
-----------------------------------------------------


2009年4月13日 (月)

WiMAXを使ってみました。その1

WiMAXのモニターに当選しましたので、使用レポートをひとつ。

正直な感想
うーん、まだ、やっぱり試験サービスやねぇ。。

一番最初に、使った場所は、東京都庁の近く。
最初、Yahooのページを開いたときは、「お、ちょっと早い!」と思いました。

が、場所を選ぶらしく、ちょっとでも移動すると、とたんに速度が出なくなり、
接続が切れてしまう。

バスで新宿近辺を移動したのですが、不安定すぎる。
つながったと思ったら、すぐ切れる。

山手線に乗って、新宿から日暮里駅まで試してみましたが、
これも芳しくないです。つながったり切れたりを繰り返す。

あと、京成の日暮里から高砂駅までも、似たような状態でした。

乗り換えの待ち時間があった高砂駅で調査。
エリア内のはずなんだけど、ホームの端から端まで歩いてみたが、ほとんどがつながらない。
下りの上野寄りのベンチの特定の場所なら、ちょっとだけつながる。
うーん、残念。。

スピードは、あまりに遅かったので、再度、測定しなおしてみます。
(移動しながらなので、つながったり切れたりして、ちゃんと計れてない気がする)

個人的には、面的な広がりよりも、基本的に鉄道の路線沿線を先に、
整備すべきだと思うわけです。

だって、家に帰ったら、ADSLや光ファイバなどのもっと高速な通信手段が
使えるんだし、面的な広がりなら、携帯電話のほうが使えるわけです。

せっかくの無線を生かすのなら、移動体です。
車(道路)よりは、大量に人が使う、鉄道でしょう。

なので、首都圏のJR、私鉄の路線のカバー率を先にあげることが、
ユーザー増につながると思うわけです。

あと、海外から帰ってきたときに、すぐにメールとかみたいんですよねー。
電車の移動中とかに。でも、あんまり成田近辺とかつながらないですよねー。携帯とか。

なので、思いついたのが、新スカイライナーにWiMAX Wi‐Fiゲートウェイセットを車両ごとに乗せて、
車内向けにサービスしたら、すごくいい感じだと思うんですけど。どうですかねー。
これは、とっても個人的な希望なんですけどねー。

あと、WiMAXの海外ユーザとかもつかえるように、成田空港と乗り入れ鉄道も、
全エリアカバーをしておいたら面白いんじゃないかなー。
ITの国、日本の玄関は、やっぱハイテクじゃないと。

って、最後は、感想じゃなくなったけど、とりあえず、ファーストインプレッションってことで。

あと、
@nifty WiMAX試験サービスで、
2回目の募集が始まってます。

募集期間 2009年4月10日(金)9:00 ~ 4月19日(日) 23:59

だってー。Don't miss it.

より以前の記事一覧

advertisements

  • 1.amazon.co.jp
  • 1.SIPで050番号使える
  • 1.楽天 売れ筋TOP3
  • 2.Google AdSense
  • 3.あなたのしろたんを!

最近のトラックバック

2014年1月
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

access counter