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