[過去ﾛｸﾞ] JR東日本 山手線の新型電車 7編成目©2ch.net (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
504(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-1BXU) 2016/04/13(水) 09:46:05.61 ID:/ec/MokwM(1/24)調 AAS
>>500
ハイ、飛んで火にいる春の虫、乙。
私その資料読んで、ココで出して主張しようと思うたけど、それあくまでイチ企業が出した資料やから、私から出したら、
「イチ企業が出したプレゼン資料で説明すな！」
ってツッコミが入ると思うて出さんかってん。
たとえば、14枚目で、
既存：IEEE 802.3 100BASE-TX Ethernet
これから：BroadR-Reach Ethernet
として、ベツモノで書いてきとるやろ。
この２つはなにかが違うねん。
然るに、JR東日本E235系INTEROSは、“車載Ethernet”という根本はいじらずに、既存の”IEEE 802.3 100BASE-TX Ethernet”はいじらずに制御をやっとるところが問題やねん。
506(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-1BXU) 2016/04/13(水) 10:00:30.59 ID:/ec/MokwM(2/24)調 AAS
この資料、P26-27で、なんでか自己否定しとるなあ。
BroadR-Reachは、CAN等の代替として 車載ネットワークの決定版になりうるか? − 答えはNO
って書いとるやん。
けど、詳細に見ると、私がいちばん問題と言うとる、ブレーキ制御の規格である”1TPCE”については、イーサネットであるIEEE802.3委員会で策定されようとしとるっぽいなあ。
−−−−−−−−−−−−−−
外部ﾘﾝｸ:techon.nikkeibp.co.jp
802.3bpは「1000BASE-T1」と呼ばれ、ワーキンググループは「RTPGE（Reduced Twisted Pair Gigabit Ethernet）」。15mの距離を、1対の信号線で1Gビット/秒で伝送することを目標にする。
507(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-1BXU) 2016/04/13(水) 10:00:59.60 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通信を行っても問題ないやろ。
めちゃくちゃ高速な上に、信頼性も保てるとしとるんやから。
けどこれは、”2016年9月に公開する予定”であって、既に運用中のE235系INTEROSは、この規格策定とは全く別のところで、既存のIEEE802.3規格の上で、低信頼性のまま非同期通信しとる。
それが問題なんやぞ。
508(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-1BXU) 2016/04/13(水) 10:09:46.05 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:32.98 ID:/ec/MokwM(5/24)調 AAS
>>508 つづき
これはどういうことかというと、Windows のOSのバージョンが上がるのと同じくらいインパクトが大きい。
Windows のOSのバージョンが上がったら、これまでWindowsで利用できていたソフトウェアが使えるかどうか、イチから検証せなアカンやろ？
そういう意味では、イーサネットといいながら、イーサネットとはベツモノを作っているといっていい。
同じ名前を冠することで、あたかも同じものを提供しているかのような錯覚をユーザに起こさせて、まるで買い替えが義務かのように思わせるトリックやなあ。
510: おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-1BXU) 2016/04/13(水) 10:16:46.18 ID:/ec/MokwM(6/24)調 AAS
たとえば、この資料のP47の書き込み、コレ問題やと言うとるんやぞ。
−−−−−−−−−−−−−
スイッチの動作
バッファリング
受信したフレームを一時的に溜め
込むことで、バンド幅の異なるポ
ート間の通信実現(100M/1G/…)
−−−−−−−−−−−−−
この、”一時的に溜め
込む”という動作のぶんだけ、データ転送が遅延してまう。
だからこそ、制御ではスイッチを間に挟むのはアカンと言うとる。
間に挟んでも、このタイミングならばエラー含めてリアルタイム処理可能、という時間を担保できたら、そのぶんにおいてはスイッチを噛ませてもええやろけどなあ。
511(3): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-1BXU) 2016/04/13(水) 10:24:34.59 ID:/ec/MokwM(7/24)調 AAS
この資料の、P63の、”UDP / TCP概観
”でもあるとおり、
UDP
デメリット 低信頼性
例 VoIP、ビデオ会議
TCP
デメリット 複雑、低速
例 ファイル転送、ウェブ閲覧
とあり、TCPもUDPも、制御に向いているなんてどこにも書いてない。
とりわけTCPの”ファイル転送、ウェブ閲覧”なんて、どんだけ時間かかるかワカランもんばっかやろ。
これのどこが同期通信なんか、説明してもらおうか？
もちろんユーザにとっては、「いつ必要なファイルがダウンロードされるんかなあ？」と待ち焦がれるという意味においては、システムと同期しとるんやけど、その意味における”同期”と、
運転士が「あぶない！」と思った瞬間に制御して止まれる即時性をシステムが持つという意味の”同期”とは、全く概念が異なる。
512(3): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-1BXU) 2016/04/13(水) 10:33:58.81 ID:/ec/MokwM(8/24)調 AAS
この資料のP75なんかでも、書いてあるなあ。そのまま転載するか。
背景
しかし標準のEthernetでは・・・
１．いつフレームが相手に届くか不明(スイッチ由来の遅延等)
２．プログラム(ストリーム)の使えるバンド幅不定、パケット損失も有
３．各ノードを時間同期する仕組みの欠如
規格追加
１．タイミング保証：802.1Qav
２．ストリーム予約：802.1Qat
３．クロック同期：802.1AS
４．AVBシステム全体：802.1BA
−−−−−−−−−−−−
私が、E235系INTEROSで問題と言うとる点は、”標準のEthernet”の問題そのまんまやないか。
513(2): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-1BXU) 2016/04/13(水) 10:35:13.91 ID:/ec/MokwM(9/24)調 AAS
>>512 つづき
１．いつフレームが相手に届くか不明(スイッチ由来の遅延等) → スイッチを１０段も接続していて、いつフレームが相手に届くか不明なので、運転士が制御できない。
２．プログラム(ストリーム)の使えるバンド幅不定、パケット損失も有 → パケット損失が大きいから、回生ブレーキがほとんど使えない。特に停止点で、本来全電気ブレーキでは必要ない、大きな空気ブレーキ圧が加わる。
３．各ノードを時間同期する仕組みの欠如 → そもそも既存のIEEE802.3規格は非同期通信やし。
それで、工作員、なんか反論ある？
工作員が出してきた資料を基にして、私は説明したんやから、工作員もこの資料を基にして説明してもらおうか？
524(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水) 15:18:02.39 ID:/ec/MokwM(10/24)調 AAS
>>518-523 ID:hHdMAs2qa はまたヨウワカラン理屈を考えてきたっぽいなあ。
そもそも、オマエは以下のような主張をしてきたのとはどう説明つけるねん？
−−−−−−−−−−−−−
>>316
UDPは非同期で早く、トークンパスとTCPは
同期なので遅いと言われればその通りです。
>>395
ちなみに、TCP/IPもUDP/IPも、
アプリケーションの作り次第では非同期にでも同期にでもできますよ。
−−−−−−−−−−−−−
それでいまなんで、TCPの議論を捨ててUDPがいい！ってすり替えとるねん？
525(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水) 15:19:10.44 ID:/ec/MokwM(11/24)調 AAS
>>523 つづき
私はTCPでもUDPでもアカンけど、とりわけTCPはコネクション確立のために要らんパケット送受信が１対１で発生するから、遅延が発生してアカンと言うてきた。
それをしれっと認めてまうなよな。
そのうえで
>>519
> 信頼性の話はしていません。
> 正常時の遅延の話を片付けましょう。
> そのあと、異常時の話をしましょう。
> ここで信頼性が絡みますよね。
アホ。
526(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水) 15:23:37.88 ID:/ec/MokwM(12/24)調 AAS
>>525 つづき
遅延のハナシ（正常時とか異常時とか関係ない。遅延は遅延や）を考えたら、信頼性が問題になるやろが。
信頼性がなければ、どんくらい遅延するかなんて検討したって意味がない。
正常時にこんだけ遅延します、異常時にはこんだけ遅延します、って、
「じゃあその”異常時”っていったいどんな条件で、回線は”異常時”をどうやって判定するの？」
と言われたら、回答に詰まってまうわなあ。
だから、”異常時”の判定基準について、オマエが説明するのが先。
私からは、信頼性と遅延について、これ以上説明する必要がない。
527(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水) 15:27:05.77 ID:/ec/MokwM(13/24)調 AAS
>>519
> UDP/IPは制御に使えないほど遅延が発生するか？
> 答えはノーです。
> 遅延のオーダーがマイクロ秒だからです。
じゃあクルマで、恐らくオマエが書いてきた >>500 の資料でも、どうして既存のイーサネット上のUDP/IPをベースとするのではなく、新たな通信手段を規定してきたの？
なにが問題やったの？
カネかけて「無駄やけどこんなシステム作りました！」って、自動車業界は揃いも揃って、鉄道業界よりもアホの集まりなんか？
説明してみ？
528(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水) 15:36:20.71 ID:/ec/MokwM(14/24)調 AAS
>>520
> だからUDP/IPを使って通信しています。
いや、既存CANでも、UDPのゆの時も出てこん。
外部ﾘﾝｸ:ja.wikipedia.org
てかさあ、オマエが >>500 で挙げた資料のどこに、UDPを使うと書いてきたの？
それは私が証明すべきことではなく、オマエが証明すべきことやろ？
オマエは、
「電車は電気ではなく、念力で動きます。それはゼッタイです。
大西さん、あなたが証明できてないのだから、あなたがそれを証明してください」
と言うとるのと同じなんやけどさあ・・・。
言うとることが小学生の「おかーちゃんが言うとることがゼッタイやねん！」とカワランよなあ。
529(3): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水) 15:43:34.84 ID:/ec/MokwM(15/24)調 AAS
>>521
> 通信制御の同期という言葉は、
> 要求に対して応答を必要とするか否かを
> 区別するためにあります。
じゃあ、クロックってなんやねん？
同期方式
外部ﾘﾝｸ:ja.wikipedia.org
たとえば、我々が時計を時報に合わせるのも同期やわなあ。
それをいちいち誰かに対して応答しとるんだっけ？
実際は、他のシステムに対して、同期している旨の通知は必要とは思うけど、それは同期している旨の通知であって、レスポンスのときに「要求に対して応答」というレベルで同期しとるかどうかはまた別のハナシ。
530: おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水) 15:44:46.44 ID:/ec/MokwM(16/24)調 AAS
>>529 つづき
とにかく、上の”同期方式”にも示すとおり、”同期”にだっていろんな意味合いがある。
私がクロックに合わせる同期が必要と言うとるところで、オマエは「通信制御では同期というのはこういう意味で」とか言うとっても、オマエがハナシのフェーズをわざとズラしてきとるだけなんやけどさあ。
531(3): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水) 15:57:41.82 ID:/ec/MokwM(17/24)調 AAS
>>523
> スイッチ一個あたりの遅延秒は既に答えました。
> 過去のレスを見てください。
それで説明したことになると思うなよ。
てか私は民意を汲み取るタイプやから、検索したらあったわ。
>>316 の
> 65kのpingでRTT=0.011sです。
コレやな。
てかそもそも”RTT”とはなんぞや？から議論を始めなアカンなあ。
533(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水) 16:01:18.79 ID:/ec/MokwM(18/24)調 AAS
>>531 つづき
−−−−−
ラウンドトリップタイム
外部ﾘﾝｸ:ja.wikipedia.org
ラウンドトリップタイムは、双方向通信を必要とするシステムにおいて重要である。そのようなシステムに、電話や、ラウンドトリップタイムがスループットに直接影響するTCPのようなACK/NAKデータシステムがある。
ラウンドトリップタイムは、ほんの数マイクロ秒のもの（短い通信距離（LoS: Line of Sight）で使われるような無線システム）から何秒もかかるもの（一つ以上の衛星接続がかかわる複合リンク回路）まである。
これには、そのメディア（通信媒体）を通過する時間と同様にノードにおける遅延も含まれる。
−−−−−
534(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水) 16:02:52.83 ID:/ec/MokwM(19/24)調 AAS
>>533 つづき
たとえば、UDPのパケットサイズって、
外部ﾘﾝｸ[html]:net-newbie.com
ココからとっても、データ除いて、64bit=８バイトやんなあ？
それでなんで、”65k”って、突然65キロバイトの平均時間のハナシになるねん？
ハナシに全く繋がりがない。
そこで、検索したらこんなのがあった。
−−−−−
外部ﾘﾝｸ:jehupc.exblog.jp
RTTは11ms=0.011sとなってますね。OSはXPなので、pingのパケット長はXPのウィンドウ最大サイズと同じ64KBにしています。
後は、計算式に当てはめてみると下記のようになります。
65500byte * 8 / 0.011s = 47,636,363bps
−−−−−
535(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水) 16:08:58.46 ID:/ec/MokwM(20/24)調 AAS
>>534 つづき
>>523 → >>316 の工作員は、OSをXPにしてTCPで通信したときの、RTTの値をそのままパクってきただけなんやな。
それで、パソコンのようにノイズ発生源がほとんどないと想定される場所ではなく、鉄道車両やクルマのように、モータがもろにノイズ発生源となりそうな場合に、スイッチがどのような挙動を表すかについては、まったく検討してないんやな？
私が言うとることは、なんらイジワルなことを言うとるのではなく、アタリマエのことを言うとる。
電磁両立性
外部ﾘﾝｸ:ja.wikipedia.org
536(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水) 16:10:17.07 ID:/ec/MokwM(21/24)調 AAS
>>535 中身つづき
電磁両立性（英: electromagnetic compatibility、EMC）とは、電気・電子機器について、それらから発する電磁妨害波がほかのどのような機器、システムに対しても影響を与えず、
またほかの機器、システムからの電磁妨害を受けても自身も満足に動作する耐性である。電磁共存性、電磁的両立性、電磁環境両立性または電磁（環境）適合性とも呼ばれる。
目的
EMC を考慮する大きな目的は、異なった複数の電気・電子機器が同じ電磁的環境に混在しているときお互いに悪影響を及ぼさずに正しく作動することの確保である。
これを達成するため、EMC技術はエミッション[1]とイミュニティ[2]（またはサセプティビティ[3]）の2種類の異なる問題に対処する。
537(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水) 16:10:48.99 ID:/ec/MokwM(22/24)調 AAS
>>536 中身つづき
エミッションは電磁気エネルギーの不必要な発生に関連があり、そのようなエネルギーの発生を減少し、外部環境への漏洩を防ぐための対策が必要となる。
イミュニティはこれとは対照的に、意図的でない電磁気障害の存在下において、電気機器を正しく動作させることに関係する。
妨害またはノイズの軽減すなわち「電磁適合性（EMC）」の達成は、エミッションとイミュニティ問題両方に対処することによって、すなわち発生源の軽減と影響を受ける機器の強化によって可能となる。
あわせて、ノイズ発生源と影響を受ける機器との間の結合路[4]においてより効率的にノイズを減衰する対策にも注意が払われるべきである。
538: おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水) 16:12:28.96 ID:/ec/MokwM(23/24)調 AAS
>>537 つづき
EMCというものが一般的に問題とされ、クルマでもフツーのイーサネットそのまま持ち込めんと思われとるんやから、
電車で一般のパソコンのデータを使ってええはずがないやろ？
541(1): おーにっちゃん ◆yoCsKijoxhpN (ﾜｲﾏｹﾞｰ MM05-Qg88) 2016/04/13(水) 16:19:08.71 ID:/ec/MokwM(24/24)調 AAS
>>539
・・・・・・私に対してなんの開発をしろと？
まさか世界で策定すべき、IEEE802.3に適用する新しい伝送路を開発せよと言うとるんか？
その費用って誰が出してくれるの？
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.051s