[過去ﾛｸﾞ] JR東日本 山手線の新型電車 7編成目©2ch.net (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
506(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-1BXU) 2016/04/13(水)10:00 ID:/ec/MokwM(2/24) AAS
この資料、P26-27で、なんでか自己否定しとるなあ。
BroadR-Reachは、CAN等の代替として 車載ネットワークの決定版になりうるか? − 答えはNO
って書いとるやん。
けど、詳細に見ると、私がいちばん問題と言うとる、ブレーキ制御の規格である”1TPCE”については、イーサネットであるIEEE802.3委員会で策定されようとしとるっぽいなあ。
−−−−−−−−−−−−−−
外部ﾘﾝｸ:techon.nikkeibp.co.jp
省1
507(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-1BXU) 2016/04/13(水)10:00 ID:/ec/MokwM(3/24) AAS
>>506 つづき
802.3bwと同じく、UTPで15m以上、STPで40m以上の伝送を狙う。MACでのBERは、10の-10乗以下を目指す。
2015年10月時点でドラフト仕様の2.1版。今後の仕様を策定し、2016年9月に公開する予定だ。
−−−−−−−−−−−−−−
IPベースでも、”MACでのBERは、10の-10乗以下”の信頼性を得られたら、コレでも上手くいく気がする。
それだけの信頼性があれば、非同期であるTCP通信を行っても問題ないやろ。
めちゃくちゃ高速な上に、信頼性も保てるとしとるんやから。
省2
508(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-1BXU) 2016/04/13(水)10:09 ID:/ec/MokwM(4/24) AAS
この資料のP35を見ても、
”車載 Ethernet BroadR-Reach”として、従来型 Ethernetとは物理層からして全く異なるものを検討しとることがわかる。
従来型 Ethernet
100BASE-TX Ethernet 100Mbs、ツイストペアx2組(4線)、全二重通信
ギガビットEthernet 1Gbs、ツイストペアx4組(8線)、全二重通信
車載 Ethernet
BroadR-Reach 100Mbps、ツイストペアx1組(2線)、全二重通信
・・・な？
”Ethernet”という名前は同じでも、全く新しいイーサネットを提案しとるということや。
509: おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-1BXU) 2016/04/13(水)10:10 ID:/ec/MokwM(5/24) AAS
>>508 つづき
これはどういうことかというと、Windows のOSのバージョンが上がるのと同じくらいインパクトが大きい。
Windows のOSのバージョンが上がったら、これまでWindowsで利用できていたソフトウェアが使えるかどうか、イチから検証せなアカンやろ？
そういう意味では、イーサネットといいながら、イーサネットとはベツモノを作っているといっていい。
同じ名前を冠することで、あたかも同じものを提供しているかのような錯覚をユーザに起こさせて、まるで買い替えが義務かのように思わせるトリックやなあ。
510: おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-1BXU) 2016/04/13(水)10:16 ID:/ec/MokwM(6/24) AAS
たとえば、この資料のP47の書き込み、コレ問題やと言うとるんやぞ。
−−−−−−−−−−−−−
スイッチの動作
バッファリング
受信したフレームを一時的に溜め
込むことで、バンド幅の異なるポ
ート間の通信実現(100M/1G/…)
−−−−−−−−−−−−−
省4
511(3): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-1BXU) 2016/04/13(水)10:24 ID:/ec/MokwM(7/24) AAS
この資料の、P63の、”UDP / TCP概観
”でもあるとおり、
UDP
デメリット 低信頼性
例 VoIP、ビデオ会議
TCP
デメリット 複雑、低速
例 ファイル転送、ウェブ閲覧
省5
512(3): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-1BXU) 2016/04/13(水)10:33 ID:/ec/MokwM(8/24) AAS
この資料のP75なんかでも、書いてあるなあ。そのまま転載するか。
背景
しかし標準のEthernetでは・・・
１．いつフレームが相手に届くか不明(スイッチ由来の遅延等)
２．プログラム(ストリーム)の使えるバンド幅不定、パケット損失も有
省8
513(2): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-1BXU) 2016/04/13(水)10:35 ID:/ec/MokwM(9/24) AAS
>>512 つづき
１．いつフレームが相手に届くか不明(スイッチ由来の遅延等) → スイッチを１０段も接続していて、いつフレームが相手に届くか不明なので、運転士が制御できない。
２．プログラム(ストリーム)の使えるバンド幅不定、パケット損失も有 → パケット損失が大きいから、回生ブレーキがほとんど使えない。特に停止点で、本来全電気ブレーキでは必要ない、大きな空気ブレーキ圧が加わる。
３．各ノードを時間同期する仕組みの欠如 → そもそも既存のIEEE802.3規格は非同期通信やし。
それで、工作員、なんか反論ある？
省1
514: (ﾜｯﾁｮｲ 9c42-w8Te) 2016/04/13(水)11:07 ID:+dMejdfp0(1) AAS
>>491
＞その上で、この記載についてどう釈明するの？逃げずに回答しろよ。
おまえがこれを言うのか？
脱ナマポから逃げ回り、非キセルの証明を一度もしなかったおまえが？
515: (ｱｰｸｾｰ Sx29-w8Te) 2016/04/13(水)11:50 ID:EzPi8W4nx(2/2) AAS
おーにっちゃん。本当元気だね。
なんで五体満足でネットやって遊んでるの？
この時間働けばいいじゃん、
516: (ｶﾞﾗﾌﾟｰ KK0a-IbeK) 2016/04/13(水)11:59 ID:/VoQPYnVK(1/2) AAS
ナマポは権利でもあるしもういいや
鉄系板に書く以上キセルの有無だけは証明しろ
517: (ﾜｯﾁｮｲ 3281-j/+h) 2016/04/13(水)12:23 ID:Ui0s3Zeh0(1) AAS
>>513
もっと単純な質問をしたい。
アンタの言う「イーサネット」とやらは「INTEROSのどこで」使われてるんだ？
518(1): (ｱｳｱｳ Sac1-w8Te) 2016/04/13(水)12:31 ID:hHdMAs2qa(1/5) AAS
>>504
なぜBroadR-Reach Ethernetの話しが関係するんですか？
あと、何かが問題やねんって、気持ち悪いですよ。
519(3): (ｱｳｱｳ Sac1-w8Te) 2016/04/13(水)12:38 ID:hHdMAs2qa(2/5) AAS
>>507
話をすり替えないように。
信頼性の話はしていません。
正常時の遅延の話を片付けましょう。
そのあと、異常時の話をしましょう。
ここで信頼性が絡みますよね。
大西さんは話しが散らかってばかりなので、
整理して話す癖を付けた方が良いですよ。
UDP/IPは制御に使えないほど遅延が発生するか？
答えはノーです。
省2
520(2): (ｱｳｱｳ Sac1-w8Te) 2016/04/13(水)12:40 ID:hHdMAs2qa(3/5) AAS
>>511
だからUDP/IPを使って通信しています。
UDP/IPを使っていないというなら、
くだらない画像(ソースを出せ)を張ってないで、
自分が情報源を出してください。
自分の判断や主観や思い込みは、情報源ではありません。
521(2): (ｱｳｱｳ Sac1-w8Te) 2016/04/13(水)12:43 ID:hHdMAs2qa(4/5) AAS
>>511
通信制御の同期という言葉は、
要求に対して応答を必要とするか否かを
区別するためにあります。
回答を必要とする通信方法は同期型、
未回答でも次の要求を発行できるなら非同期型です。
大西さんが言っているような、
アプリケーション層よりも上の概念
(運用フェーズ、使用感覚)は、別の議論をすべき事です。
522(1): (ﾜｲｰﾜ2 FFe6-w8Te) 2016/04/13(水)12:48 ID:T9e+ukZmF(1) AAS
>>512
新規規格は従来の規格を拡張します。
当然、デメリットに手を打ちます。
設計者が考えなければいけないことは、
そのプロトコルの機能が必要十分かです。
私は、UDP/IPが必要十分で、
デメリットと言われている遅延についても
問題にはならない事を示してきました。
問題を発見できるのは大西さんしかいません。
そういう意味で、大西さんがやっている現地調査は
省6
523(4): (ｱｳｱｳ Sac1-w8Te) 2016/04/13(水)12:54 ID:hHdMAs2qa(5/5) AAS
>>513
＞>>512 つづき
＞１．いつフレームが相手に届くか不明(スイッチ由来の遅延等) → スイッチを１０段も接続していて、いつフレームが相手に届くか不明なので、運転士が制御できない。
スイッチ一個あたりの遅延秒は既に答えました。
過去のレスを見てください。
＞２．プログラム(ストリーム)の使えるバンド幅不定、パケット損失も有 → パケット損失が大きいから、回生ブレーキがほとんど使えない。特に停止点で、本来全電気ブレーキでは必要ない、大きな空気ブレーキ圧が加わる。
電力はこの議論が終わってから話してください。
＞３．各ノードを時間同期する仕組みの欠如
省2
524(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水)15:18 ID:/ec/MokwM(10/24) AAS
>>518-523 ID:hHdMAs2qa はまたヨウワカラン理屈を考えてきたっぽいなあ。
そもそも、オマエは以下のような主張をしてきたのとはどう説明つけるねん？
−−−−−−−−−−−−−
>>316
UDPは非同期で早く、トークンパスとTCPは
同期なので遅いと言われればその通りです。
>>395
省4
525(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水)15:19 ID:/ec/MokwM(11/24) AAS
>>523 つづき
私はTCPでもUDPでもアカンけど、とりわけTCPはコネクション確立のために要らんパケット送受信が１対１で発生するから、遅延が発生してアカンと言うてきた。
それをしれっと認めてまうなよな。
そのうえで
>>519
省5
上下前次1-新書関写板覧索設栞歴
あと 477 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.020s