【無線LAN】OpenWrt【強化ﾌｧｰﾑ】13 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>484
>480-481 の環境での検証結果をまとめました。
◎WZR-900DHP
純正 ver1.14 … 送信：935Mbps / 受信：936Mbps
LEDE 17.0.1.1…送信：239Mbps / 受信：240Mbps
◎Windows10 Pro 1607
直結…送信：945Mbps / 受信：946Mbps
PPPoE…送信：929Mbps / 受信：929Mbps
◎BHR-4RV
純正v2.45…送信：71.5Mbps / 受信：71.5Mbps
LEDE17.01.1…送信：23Mbps /受信：23Mbps ※ iperf3 -P1 での測定
◎WZR-HP-G301NH
純正v1.81…送信：122Mbps / 受信：122Mbps
LEDE17.01.1…送信：194Mbps /受信：194Mbps
◎WZR-HP-AG300H
純正v1.75…送信：199Mbps/ 受信：199Mbps ※ P20 での測定
WZR-600DHP v1.99…送信：166Mbps/受信：166Mbps ※P36 20秒間での測定
LEDE17.01.1…送信269Mbps/受信269Mbps 以下寸評
◎BHR-4RV
CPU性能を考えると純正ファームはかなりの高スループット
LEDEでは複数TCPセッションで６０秒間のiperf3 に耐えられずエラー終了
tcp 1セッションまで減らしてようやく終了。
◎WZR-HP-G301NH
LEDE の方が高スループットだが
30秒を超える辺りでiperf3 がエラー終了することも多々あり
◎WZR-HP-AG300H
純正v1.75や600DHP v1.99のファームでは TCP36セッション*60秒間のiperf3 に耐えられない
LEDEでは36セッションのiperf3を常に完走できるようになって安定性・スループット共に向上している。 ちなみに以上は 有線接続時のPPPoE+NATルーティングスループットでの評価となります
計算性能という意味ではOpenWrt サイトに OpenSSLのベンチマークがありまして、
https://wiki.openwrt.org/doc/howto/benchmark.openssl
WZR-900DHPと同じ BCM4708A0 を使っているASUS RT-AC68U は
AR7161のWZR-HP-AG300H に対してだいたい２倍程度の速度を叩き出してます >485 追加
◎BHR-4GRV
純正v1.77…送信：253Mbps / 受信：253Mbps
純正v1.99…送信：263Mbps / 受信：263Mbps
OpenWrt 14.07※…送信：73.9Mbps / 受信：73.9Mbps
LEDE 17.01.1※…送信：191Mbps / 受信：191Mbps
※ WZR-HP-G450H 用firmware
→ BHR-4GRVは純正のほうがスループットが高い。iperf3 も安定。
OpenWrt 14.07 から LEDE 17.01.1 で2.5倍のスループットに。
おそらく、QSDK Project での Athros ドライバの成果がフィードバックされたためではないかと思います。 >>488
乙でした
300系がLEDEで覚醒してるのは意外
4GRVでwrt使ってるけどギガビットイーサの仕様が全く生きてなかったのね…
時間があるときにLEDEの環境作ってみよう >486 さらに追加
◎BHR-4GRV2
純正v1.03…送信：920Mbps / 受信：920Mbps
純正v1.08…送信：932Mbps / 受信：933Mbps
OpenWrt 14.07※…送信：146Mbps / 受信：146Mbps ※AP135-20用ファーム
LEDE 17.01.1…送信：355Mbps / 受信：355Mbps
→純正firmがカタログスペック(839Mbps)よりスループット出ていて、PCでのPPPoE並です。
BHR-4GRV同様OpenWrt14.07からLEDEになってだいたい２.5倍に。
CPUクロックの向上(400MHz→720MHz)に比例したスループットになっています。
純正firmはクロック比以上の値になっているので、
何らかのアクセラレータ機能が有効になっているのかもしれません。
今までUSBなくなった廉価版のダメな子と思ってたよBHR-4GRV2。打ち捨てておいて悪かったw 何となくまとめ
Linux側でPPPoEサーバがユーザモードとkernelモードとで２倍以上の差がでることから
スループットはドライバの作りに大きく依存することがわかる。
Qualcom買収以前のAtheros SoC の機種は純正よりもLEDEの方がスループットが高い。
純正ファームウェアが古いkernelを使っている一方で、
QSDKで開発されたswitchドライバのフィードバックのおかげかもしれない。
https://wiki.codeaurora.org/xwiki/bin/QSDK/
新旧ともBroadcom SoC 機は純正の方がアクセラレータ機能が効いてLEDEの数倍のスループットが出る。
このあたりはエンタープライズ系NWプロセッサを手がけるBroadcomの本領発揮というところだが、
NDAで縛るなどOSSコミュニティに冷淡なので、今後LEDEで活用されることは期待できそうにない。
当面、LEDEでは Qualcom Atheros SoC の製品の方が推奨と思われる。
>418 の言うように 11ac 時代では TP-Link Archer C7 が鉄板というのも頷ける。
今後Ramips/MediaTek SoC系の評価もできたらしてみたい。
(WHR-1166DHPとWHR-300HP2はあるのですが、いずれもLAN側100BASE-TXなので・・・) >WHR-300HP2
WAN側も100Mなわけだが 長く販売されてきたロングセラーでも
日本に法人立てて国内販売が始まったのは去年のこと
猫も杓子も、のBuffaloの機種はハドオフ行けば連れ帰ってほしそうに見つめてくるが
わざわざTP-LINKを選ぶようなヘンタイは少ないから、新品で手に入るうちに買っとかないと
手に入らなくなるよ 無線機器の商売でメインが11acになった影響で、たしかに11nの弾数が一気に増えた印象。
先日訪問したら、G301NHが2つ、真ん中のはG450Hでアンテナ欠品、全部324円だった。
http://i.imgur.com/cAQcPZe.jpg
新しいファームを焼く実験機や、同じ設定を施した予備を増やす目的で本当に助かる。
ただ、上記の11nモデルは手元に増えすぎたので、底値だけど3台ともスルーした。
このあと、純正AC付きAG300Hを324円で発掘、こいつは別格だから結局買ってしまった。
http://i.imgur.com/o8XKxTj.jpg LEDEのSSH CLIから純正firmwareへの戻し方。(WZR-HP-AG300H、BHR-4GRV2対応)
純正firmware状態であらかじめbufpyでtelnetして /dev/mtdblock/6 を dd でバックアップ取っておく。
LEDEのSSH consoleでログイン
scp で /tmp に mtdblock6.dd をコピー
mtd write /tmp/mtdblock6.dd "firmware" で 書き戻し
/tmp はramdiskなのでメモリ128MBのAG300Hや、flashイメージが16MBと小さい4GRV2は
/tmpに置いても大丈夫。
G301NHや4GRVなどは/tmpがあふれてしまう。
USBメモリを有効にしたり、分割して書き込みなどの手段が必要 >494
\324でAG300Hとは安いねぇ
かつてのWHR-G54S 状態になってる気がしますね >>494
ドフスレかと思った
>G301NH
１つ324円ならすべて購入するわ
十和田市のドフじゃ(ギガ対応の11nは)１つ 1620円だからな 十和田ってどこかと思ったら青森、八甲田山じゃないのさ!! >>486
ag300hに入ってるar7161は、クロックアップできるってopenwrtフォーラムで
見たことがあります。確かソースのどこかの値をいじってビルドするらしい。
800MHzぐらいまでアップできたと思うので、そうなるとまた結果が変わってくる
かも。
>>491
ledeのtrunkでmt7621にジャンボフレームがサポート（2Kまで）されましたので
https://git.lede-project.org/?p=source.git;a=commit;h=eee09bfe01e8cc2db1501f82dde7b9b6bb424faf
wsr-1166dhp(2)あたりはちょっと期待できるかもです。 androidのカスタムファームでよくあるようにClockupがソフト的にできると良いですよね
個体差なども出てくると思います。 OCといえば、dd-wrtで、WBRやWHR-G54Sでoverclockという項目があって、
なにげなく1段階だけ速くしたらリセットが掛かり、起動直後からOCが適用されているのか、
30/30/30もできず、二度と戻せなくなったトラウマがある。 Router Model: Buffalo WHR-G54S
Firmware Version: DD-WRT v24-sp2 (02/17/11) std - build 16214
CPU Model: Broadcom BCM5352 chip rev 0
CPU Clock: 200 MHz
cron
00 05 * * * root wget -O /tmp/smbshare http://www.crunchyroll.com/rss >>502
おーありがとう。
うちの無線ルータwndr3700v1。パッチ作ってビルドしてみたお。
root@lede:~# dmesg|grep MHz
[ 0.000000] Clocks: CPU:800.000MHz, DDR:400.000MHz, AHB:200.000MHz, Ref:40.000MHz
[ 0.000007] sched_clock: 32 bits at 400MHz, resolution 2ns, wraps every 5368709118n s
root@lede:~#
800MHzになってるわ。これをガンガン試す用途がみつからない… >506
乙
作ったLEDE用パッチを是非公開してほしいです >>507
内容は上のリンクのやつのままだけど、カーネルのバージョンも当時とは
違ってるし、ソースが変わってるかもと思って一応今のソースで作ったpatchです。
なので途中でHunk!とかは出ないから安心して。
どうぞ
diff --git a/arch/mips/include/asm/mach-ath79/kernel-entry-init.h b/arch/mips/include/asm/mach-ath79/kernel-entry-init.h
index d8d046b..c8a5056 100644
--- a/arch/mips/include/asm/mach-ath79/kernel-entry-init.h
+++ b/arch/mips/include/asm/mach-ath79/kernel-entry-init.h
@@ -23,6 +23,8 @@
and t0, t1
ori t0, CONF_CM_CACHABLE_NONCOHERENT
mtc0 t0, CP0_CONFIG
+ li t2, 0xc0140198
+ sw t2, 0x18050000
nop
.endm
これを適当な名前、例えば
999-overclock800mhz.patch
で保存して、それを
/lede/buildroot/path/target/linux/ar71xx/patches-4.4
下に置いて、あとはmake
760MHzとの違いは、0xc0140198を0xc0140190にするだけみたい。800MHzで不安定
だったら、760にすればいいかも。 あかん、行頭の+とかスペースとかタブが削除されとる。
こちらでどうかな
https://pastebin.com/yjKpdwL8
こっちも.endmの次の空行が削られてるけど、なんとかなるでしょ。 >>509
爆ぜるのか？
うちのは爆ぜてないよ。まあcpuを使い切るほどに使用したり、真夏の暑さでは
試してないのでなんとも言えないが。
ということで、自己責任でお願いします。 ありがとう。
どこにパッチを置けば良いかも教えてくれてとてもサンキューです
AG300Hでやってみようと思います BroadcomやQualcommAtherosのような米帝の企業が設計しているものはいざしらず
中華の企業が設計してるもんなんて定格がそもそも本当に定格なのか
それすら信用していいものか分からんぞ
帰ってきたら家が無くなってたなんて笑えないから
悪いことは言わんOCは止めとけ
むしろ下げる方向のDCなら止めないが >>513
511だが、ある意味おもしろい。DCのやりかた教えて。 まぁまぁ。
常時空調のない一般家庭の劣悪な環境下で
連続稼働させるルーターでのクロックアップの危険性を説いたものと理解します。
クロックアップについては実験目的ですよね
LEDEのkernelパッチの当て方を教えていただいたことに価値があるかと思います OCはベースのクロックをPLLを通して上げるパラメータを変えるのだと思いますが
だとしたら倍率を下げる方へパラメータを変更すれば下げられる
PLLの設定の仕方は当然ながらSoCごとに違うので
それぞれの仕様を見て設定値を算出する必要がある >>518
511だが、なるほど、ar7161の仕様がわかれば、原理的にはDCも可能であるという
ことですね。
勉強になります。 >>517
そういってもらえると嬉しいです。
もし需要があれば、gitを使った極私的簡単パッチの作り方も書きますが、いる？ 早くしたいならルータとアクセスポイント別の筐体にすればいいじゃん 364円で買えるならクロックアップハックで楽しむのも有りでしょう
カーネルパッチを当てるのなら、
固まっても、u-bootでTFTPからの復旧はできそうですしね
クロックアップしたルーターで通常運用はしないかな
PLCCを書き換えるということはマスタークロックが上がってしまうので、
無線含めるとどこに影響出るかわからないし DD-WRTなら管理画面からポチでOCなのに面倒なんだな >>524
ポチをしてOCできたとしても、それが楽しいかどうかとはまた別なんだなあ。
パッチあててそうなったというのがおもしろいのであって。
>>505さんのHNATの情報なんて、ワクテカしないか？ >>526
WXR-1900DHPを1.4GHz駆動させてると先にインターネット回線の方が足りなくなるんで特には そこは出来合いを活用するDD-WRTと
自分で組み上げるOpenWrt/LEDEの文化の違いではないかなぁ >>527
BCM4709A0って、DD-WRTで1.4GHzまでOCできるの？
ソースのどこかをいじれば、LEDEのbuildrootでも再現できるのかな？ >>523
了解。
ざっくりとした流れとして、
１．# cd カーネルorパッケージの/ソースの/ルートディレクトリ
２．# git init
３．# git add 変更/したい/ファイル
４．# (editor) 変更/したい/ファイル
５．# git diff > xxx-hogehoge.patch
６．# cp xxx-hogehoge.patch /パッチを/あてたい/カーネルorパッケージ/patches
です。 例えば、パッチを作りたいパッケージと今組み込みたいターゲットが、
ターゲット：ar71xx
パッケージ：fugafuga
fugafugaへのパス：package/feeds/packages
だとして、
０．まずはfugafugaを組み込んだ状態で、一度ビルドする
# make
１．ar71xxに関わるソースは、build_dir/target-mips_24kc_musl/ 下にあるので
# cd build_dir/target-mips_24kc_musl/fugafuga
２．一時的なgitリポジトリを作成
# git init
３．変更したいファイル(ここではsrc/main.cとする)をgitに教える
# git add src/main.c
４．ファイルを編集して保存する。ここではviにしてるけど、お好きなエディタでどうぞ
# vi add src/main.c
５．git diffすると、コンソールにdiffが出力されるので、これをパッチファイルとして保存
# git diff > xxx-hogehoge.patch
６．作成したパッチを、fugafugaのpatchesディレクトリにコピー
# cp xxx-hogehoge.patch /path/to/buildroot/package/feeds/packages/fugafuga/patches
７．再度ビルド
# make ４．の"add"は間違いです。"add"はいりません。
６．でコピー先のpatchesディレクトリがまだなければ、自分でmkdirしてください。
パッチファイルのxxxは、３桁の数字を適当に（例えば999）割り振ってください。既にパッチがあるときには、
それとかぶらないのを割り振ればいいでしょう。
カーネル用のパッチは、target/linux/xxxxxxxx/patches下に置いて下さい。
パッケージのパッチは、一度作成すればターゲットにかかわらず反映されますので、別の
ターゲット用にいちいち作ることはありません。
ごりごり開発する人からするとしょぼく見えるでしょうが、簡単なパッチを作るにはこれで結構間に合います。
こうしたらもっといいのにというのがあれば、ご指摘ください。 ありがとうございます〜
非プログラマなのでgitの使い方までは調べられても、
LEDEにおける正しいやり方がわからなかったので助かります パッチファイルの番号はいまディレクトリにあるやつの最後の番号より大きい数字にしとくのが無難
先頭の数字3つ分が大きい値にしてあればいい
ワイルドカードでかき集めてパッチするから辞書順で適用していくので
最後にしておけば、すでにパッチ済みの現状を邪魔せずに追加するかたちになりまする この辺りの情報をまとめたいね
活用wikiでも良いけどどうせなら本家に
日本語版独自コンテンツを作ったら怒られるのかな？ wzr-1166dhpなんだけど、dd-wrtの方では、5GHz、2.4GHzともに正常出力で、安定稼働するようなことがforumに書いてあるんだけど、ledeやopenwrtはどうなんだろう。
いま、ハドオフでジャンクを物色中。 ここは無線AP/ルータ 10種類以上持ってるような人ばっかりなのですか!? >>537
whr-1166dhpの方じゃないの？ >>539
mediatecは、wsr-1166を１つもっているし、いけそうな感じがわかるんだけど、
broadcomは、wzt-900の例もあるから、いろいろ心配。 >>538
持ってる数は少ないよ。
openwrt/ledeをインストールして使ってきたのは無数にある。
というか、機種を選ぶときに、インストールできるか、もしくはサポートされる
可能性が高いかが基準になってる。 >>541
>>542
いや、SoCとしてはwzr-1750dhpとほぼ一緒だと思う。なので可能性としては
そちらのが使えるかもしれない。
brickしてもいいなら、値段次第じゃない？ ledeとopenwrtの再マージのプロポーザルが、ほぼまとまったみたい。
http://lists.infradead.org/pipermail/lede-dev/2017-May/007771.html
続くスレッドで、主要な開発者がほぼ異議なしと言ってるので、これで進むと
思われます。 >>540
さすがにそれだけの数があると置き場所、コンセント確保、
無線のチャネルを衝突しないように割り振ったりファームウェア更新したりの管理も大変でしょうね Aruba とか Cisco aironet WLC みたいな
Wiress lan controller のOSSソリューションって何かありますかねぇ >>547
管理が大変なのは確かだけど、全部を同時に動かすわけじゃ無いでしょ。
うちも似たような数があるけど、込み入った仕事をやらせたときの前触れ無くリブートする頻度や、
無線の規格が同一でも、クライアントとしてぶら下げる端末同士の相性が結構ある。
さほど距離が離れていないのにリンクが途切れるとかね。
それを切り分けてバランスのよいAPを探すために、とっかえひっかえ、検証してる。 OpenWrt FWへ入れ替えて納めてサポートしてのSIerさん?
搭載して動かせるようになるのは大抵は現行品でなくなった頃だから
それでまとまった数を確保して納入する、とかの商売が成り立つのか
想像がつきませんが 550だけど個人で遊んでるだけだよ。
というか、これを仕事で納入なんて想像だにしたこと無いよ。
市販品を改造して仕事の道具として導入して、そのあとどんな結末になるかなんて、
誰でも想像付くと思うけど。 おそらくカスタマイズ用無線LAN装置でOpenWrtに対応してものは
世の中にはあるのだろうとは予想するけど、
そんな機器を納入できるSIerはクローズドでいろいろノウハウあるだろうから、
こういうスレに出入りはしないでしょうねぇ。。。 >>549
arubaとciscoのことを知らないので比較できるのかわからないけど、openwrt/lede
をインストールしたAPを集中管理できそうなのでいえば、openwispかなあ。
http://openwisp.org/
packageにもある
https://github.com/openwrt/packages/blob/master/admin/openwisp-config/Makefile
それと、これもいけそう
https://cucumberwifi.io/
でも、どちらも自分で使ってみたことがないので、実際のところはわかりません。 >>554
ありがとうございます。
複数のAPを統合管理するソリューションなのでこんな感じです。
GUIの感じは https://cucumberwifi.io/ が見やすくていいですね
完全OSSみたいなので、OpenWISPの方が良いかな？
無線LANルータをたくさん持っている方、これで遊んでみません？ >>485,488,490 の PPPoE+NATスループット試験では
WZR-900DHPがWZR-HP-AG300Hに敗れる結果に終わりましたが、
それだけの評価ではWZR-900DHPがいらない子になってしまうので、
今度はLEDEにStrongSwanをインストールして、
PPPoE+NAT+IPSec (IKEv2 RSA) でのスループットを測ってみました。
結果、WZR-900DHP は WZR-HP-AG300Hの約2倍のスループットを叩き出しました。 今度は以下のような環境でテストしました。
[Win10x64]------[ LEDE Router ]-----[(ESXi6.0u3)-----(CentOS6.9 VM)----(Win7x64 VM)]
| ←----------PPPoE MTU 1454--------→ |
StrongSwan| ←----------IPSec IKEv2 RSA---------------------→ | 標準VPN Client
client|←-----------------------iperf3 -P 36 -d ---------------------→| server
CentOS6.9 x64 , rp-pppoe 3.10 (kernel mode)
LEDE 17.01.1 , StrongSwan 5.5.1
Windows7 Pro x64 , OS標準VPN Client, iperf3 3.1.3 win64
Windows10 Pro x64 , iperf3 3.1.3 win64
Win7 側で iperf3 -s
Win10側で iperf3 -c <iperf3 ip> -P 36 -t 65 -O 5 -d
※iperf3のIPはWin7側LAN IPと VPN IPとで切り替えて 通常PPPoEの場合と、IPSecの場合とで測定。 測定結果まとめ
◎BHR-4GRV + LEDE17.01.1
PPPoEのみ：送信：155Mbps / 受信：155Mbps
IKEv2 RSA：送信：14.5Mbps / 受信：14.3Mbps
◎WZR-HP-AG300H + LEDE17.01.1
PPPoEのみ：送信：310Mbps / 受信：310Mbps
IKEv2 RSA：送信：21.5Mbps / 受信：21.4Mbps
◎WZR-900DHP + LEDE17.01.1
PPPoEのみ：送信：274Mbps / 受信：275Mbps
IKEv2 RSA：送信：41.6Mbps / 受信：42.2Mbps
StrongSwanのインストール＆設定用 ansible playbook を作成し、
3台とも同一の設定手順でStrongSwan の VPN環境を構築しました。
（証明書は同じものを使いまわしです） 考察
BHR-4GRV (AR7242 400MHz) と WZR-HP-AH300H (AR7161 680MHz)では
ほぼクロックに比例した差になっている。
WZR-900DHP(BCM47081A0 800MHz) と WZR-HP-AG300H では
>487 の OpenSSL ベンチマーク結果に等しいスループット値が出ている。
やはりCPUを使わせたらWZR-900DHPの方が有利です。
メモリも多いので有線専用機として使えそうです。 PPTPみたいな簡素なVPNならともかく
IPSecになってしまうとね
VPNアクセラレータ搭載機種でOpenWrt/LEDEに対応してる機種はなにかありましたっけ？ >>558
この感じならBCM4709 1GHz dualcoreでやれば
IPSec 100Mbps の大台になんとか乗るかな？ >>561
一般的ではないと思うけど、pcengineというスイスのメーカーが作ってたalix
というボードは、x86のamd geodeというやつで、openwrt/ledeをインストール
して使ってます。
buildrootでこれを選択すると、カーネルモジュールとしてデフォルトで
kmod-crypto-hw-geodeというのが組み込まれるようになってます。
なのでたぶんこれはアクセラレータを持ってるんだと思いますが、IPSec用途で
使ったことがないので恩恵があるのかないのかよくわからんです… VIA C7 + opensslでpadlockは試したことあるがあれは確かに利いた legacyなbcm4704系はOpenWrt kamikaze の頃には対応してたようですね ハードウェアアクセラレータは
解析されてOSSで使える頃には時代遅れになってる希ガス >>555
おもしろそう。興味あるわ。たくさん持ってないけど。
サーバを用意しないといかんのかな？ >>552
ddwrtはプロ版があるけど、あれは事業者むけなのかな？
廃業した0internetやfc2は使ってなかったけか？ >>568
あれはプロ一般人、日本的に言うと「玄人志向」な位置づけだと思う。
FC2のルータは謎だね。
ベースはWHR-G300Nで、初期SSIDや技適を隠して、元ラベルの場所へ、
でかいFC2シールを上から貼り付けて配布してる。
そもそも、この時点で法的にまずいんじゃないかと思った。
buffaloと契約した上で一括購入して配布したのか、あるいは市場在庫をかき集めて
1つ1つ改造を施したか、謎だらけ。ちなみに、たまーにドフに転がってるのを見る。 >>567
サーバは必要でしょうねぇ
Wiress Lan Controllerの学習のために
私も折を見て試したいと思ってます
>>568
DD-WRTのbuffalo版のProfessional Firmwareのこと？
>>568
fc2 ってそんなことしてたんだ
技適シールを隠すのは違法だよね
さすがにbuffalo経由で特注ファームを書き込んだ状態で納品されたんだと思うけど NETGEAR R7800に凸した人はおらんのか LEDEで対応ファームイメージが配布されているというのに
TP-LINK Archer C7を使っているが
プロセッサコアがMIPSからARMに移行されているが全体的にC7の上位的なスペックで
MIMO周りで設計ミスらしい一つ前のR7500と同様にeSATA付き
しがらみだらけのBroadcomの呪縛がない SoCがQualcom Atheros のIPQシリーズでしたっけ？ 全体の流れはMIPSからARMか…
もっとも、AtherosのMIPS はBE でしたよね 主だったチップメーカで今もmips使ってるのは、mediatekぐらいですよね。
mediatekも上位モデルのmt7623とかになるとarmだし。 遂にMIPSも滅びてしまうのか？
CiscoとかのNW機器も最近のは殆どx86だからなぁ armに対するmipsのアドバンテージって何かある？ >>427 の言ってた glibc の毒舌Drepper先生の気持ちがわかったw
90年台半ばからglibc を開発してた先生からすれば
携帯端末上がりのarm って取るに足らないアーキテクチャだったんだろうねぇ
でも、かくいうx86も
大元は電卓の4004をルーツに持つ 16bit mode の8086/DOS時代は
その設計にアレヤコレヤ言われ続けたわけで
（先生はまともになったi386 protect mode 以降でやってたからそんなに気にならなかかったのかも）
歴史は繰り返すとはよく言ったものですなぁ >>579
かつて上と見られていたMC6800のモトローラが、今は携帯・スマホで有名とは何の因果か
（というほどでもないか） 16bit時代は電卓上がりの i8086 と ワークステーションダウングレードのMC68000 との戦いで
アセンブラプログラマからの支持が厚かったMC680x0 も
結局コストパフォーマンスでi386に敗退した。
i386はコンシューマ市場を席巻し、PC分野では完全支配に至った。
さらにx86_64に進化してかつてmipsやPOWERが幅を利かせた
WS、サーバー市場の大半まで支配するに至った。
そうこうしているうちにPDAからスタートしたarm が徐々に性能を高め、
コストと電力パフォーマンスとでx86に勝利。
コンシューマ携帯端末のほとんどすべてを支配するに至った。
零落したMIPSはNWプロセッサや無線LAN SoC として生き残っていたが、
そこにも arm の影が迫っていた。。。←今ここ ■ このスレッドは過去ログ倉庫に格納されています
