【あれから】ネレイド再生産の話があるんだけど【４年】

「オリゲー・フェスタ☆68 第14回」開催企画中です。

開催日

２０１２年８月２６日（日）

場所

川口駅前市民ホールフレンディア（仮予約済み）

ご協賛のお願い

　2012/8/26の会場本予約に際して、1か月前の2012/7月までに
　会場の予約費用が必要となります。

　つきましてはオリフェスの開催・継続にご賛同いただけますみなさまには
　オリフェス準備会へのご協賛を賜りたく、伏してお願い申し上げます。
　詳細な内容につきましてはご協賛のお願いのページの内容をご覧ください。
　みなさまの温かいご支援を賜りますよう、どうぞよろしくお願いいたします。

■掲示板に戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 最新50

1 ：俺様ラッキョ＠x68ch ★ ：05/06/24 20:14 ID:???: ネレイド再々再生産？の話があるんだけどどうよ。
５０枚分の予約があればＯＫ。
201 ：ラキッ！＠x68ch ★ ：05/10/13 09:44 ID:???: dcache2.x はお使いですか？

※すみません、何か思いついたり、情報を発見する度にメモ代わりに
　書いています。
202 ：あるきち＠京ぽん ：05/10/13 10:30 ID:L+oThG9+: >201
DCACHE2のキャッシュメモリにネレイドを指定できると良いなぁ。
12MBの猫の額から取るのはもったいないので。
203 ：００８３ ：05/10/13 14:43 ID:UhYItXTU: やりましたー！！ついに安定動作しました（^o^）／
とんだ盲点でした。アドバイスにありましたように、
ハイメモリが怪しいと思い、ハイメモリを外す覚悟をして、
最後の使い納めとばかりにハイメモリで動かすには危険なソフトを
動かして遊んでいたら　xip　ifconfig　inetdconfをハイメモリ上で
動かしたところ、バカバカしいくらいに安定動作したのです(^^;
おかげで副作用として転送速度もUPして受信速度が
メインメモリ上では４２ｋｂがハイメモリ上で６６ｋｂに
送信速度がメイン上で１１２ｋｂが１５０ｋｂにまで跳ね上がりました。
この事から弊害？としてハイメモリ上での動作が条件になるため
６８０００モードではNEREIDのLAN機能が不安定になり
使えないと言うことが判りましたが、わざわざ６８０００モードで
使うことはほとんど無いので問題ないと考えています。

XVI(16MHz)+Xellent30+TS-6BE16でNEREIDを安定動作できた
現時点での環境は０３０モード下にて
PROCESS=3 10 10
xip -n8
xip　ifconfig　inetdconfはloadhigh.rを使ってハイメモリ上で起動が
が前提と言うことになるでしょうか。
あと、ether_ne.sys ver0.03+1
hscsi.x ver0.27を組み込みました
もちろんXellent30のアドレスは切り替えてあることが前提で
SRAMにもそれのアドレスで登録しました。

それとNEREIDのスイッチはメモリ増設4MBが設定してあって
バンク切り替えのスイッチはOFFのままで、使ってないです。
USBも今のところ全く使って無いです（将来的にはUSBメモリが使えたら
幸せかもって思ってたりもしますが(^^;）
DCACHE2は組み込んであります。しかし転送するドライブは
キャッシュから外してあります。
FTPF.xはver1.02でもver1.02+1でも問題なかったです。
ですのでFTP.xは試していないんです。
あと、FTPF.x使用時のホスト名入力での使用は、
まだしていないので、取りあえず説明書きを読みながら
じっくり勉強していきたいと思います。

とんだお騒がせをして申し訳なかったですｍ（＿＿）ｍ
これで無事私の環境でもNEREIDが安定して使えるようになりました
丁重なアドバイスをくださったラキッさん
ホントに有り難う御座いました。
204 ：ラキッ！＠x68ch ★ ：05/10/13 16:46 ID:???: >>203
すみません、正しくはDCACHE2.Rですね。

なるほど、やはりDCACHE2をお使いでしたか。
どうもソフト的に衝突があるようなんですよね。
ダウンロード先のドライブをキャッシュ指定していない場合でも、
組み込んであるだけでＮＧっぽいです。
ハイメモリ上に xip 等を上げた場合には、分離されるのでその症状が
出ないという事になると思います。
またこれは、DCACHE2に限らず、usbfdd.sysなども同じ問題が発生するので
ether_ne.sysとデバイスドライバの同居の場合に何かが起きているようです。
ハードウェア的に不安定になっている訳ではなさそうです。

それにしても、LANの送受信共に中々の速度で使えて良かったですね。
僕もハイメモリに上げて使った事は無かったです。今度試してみようっと。
205 ：ラキッ！＠x68ch ★ ：05/10/13 16:50 ID:???: >>202
現状、DCACHE2 と ether_ne.sys が混在している状況で LAN 通信が
ハングアップ（固まって）してしまう症状が一部の環境で確認されて
いますので、しばらくは ether_ne.sys と DCACHE2 の併用は避ける
ようにした方が良いかも知れません。
206 ：ラキッ！＠x68ch ★ ：05/10/13 16:54 ID:???: それにしても、DCACHE2 もそうですが、usbfdd.sys も当たってしまうのは
個人的に『ラッキョぴ～んち』なんですけれども（＾＾；
僕もXellent30（クロックアップ＆ハイメモリ）でDCACHE2使いますし～。
207 ：ラキッ！＠x68ch ★ ：05/10/13 17:20 ID:???: あ、そうだ、あとネレイドのDIP-SWの内容をONとOFFで、できれば書いて
欲しかったのですが・・問題解決しちゃったからもう書いてくれないかな？
208 ：ラキッ！＠x68ch ★ ：05/10/13 17:43 ID:???: あと0083さんの症状は、当初の報告にもある通り何らかの原因で
メインメモリの内容が破壊されいる事が考えられるので、ハイメモリを
使用する事で現状の使用には問題無いかも知れませんが、一度内蔵増設
メモリやXVI本体各基板を清掃・点検した方が良いかも知れません。
209 ：ラキッ！＠x68ch ★ ：05/10/13 17:48 ID:???: X68030でNereidとNeptune-X Evolution2をとっかえひっかえして
検証しているのですが、usbfdd.sys の問題は個別の問題のような
気がしてきた・・（汗
今回の事例を纏めてFAQに追加する事にしよう。
210 ：米屋＠x68ch ★ ：05/10/13 19:41 ID:???: 10枚ｷｯﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
211 ：ラキッ！＠x68ch ★ ：05/10/13 20:53 ID:???: PROCESS=32 10 10
Neptune-X Ethercard Driver version 0.03+1
xipβ5 -n 10
くらいにすると送信で平均250KB/sとか出ます。（ピークじゃないよ）
受信も平均で75KB/sくらいですね。（瞬間値じゃないよ）
瞬間値ならもっと出る事もあります。（目視においてォ）
ftpf.x Ver1.02 Mitsukyさん作において。
各ドライバ、ツール作者の皆さんに地の底から湧きあがる勢いでありがとう！

NFS Clientなら以前も200KB/sくらいで送受信できていて快適でしたが、
今ならもっと出るのかな、最近はもっぱらftpでちょっと使ってなかったけど
また繋げてみようかな。mintから直接ネットワーク先のファイルが見えるので
物凄く便利なんですよね。
そこの場所をsambaとかで共有しておけば、Windowsとかからも直接触れるので
色々と便利です～。
212 ：ラキッ！＠x68ch ★ ：05/10/13 20:56 ID:???: >>211 はX68030+060turboなんですけど、
洩れのクロックアップXVI030ならどうなんだろ。
以前試した結果はもう忘れてしまい・・記録も残ってなくて・・
Xellent30が40MHz駆動でSYSが12.5MHzなんですが。

誰かクロックアップネレイダーはいませんか？ォ
おとなしく自分が押し入れから出せば良いのですが。
213 ：ラキッ！＠x68ch ★ ：05/10/13 20:58 ID:???: >>210
やっべドキドキですよ！
今年中に第二次ロットとはジツはあまり予想していなかったので
ちょっぴり焦ってます。
米屋さん、皆さん、最後まですみません。
最後の最後までお見捨てなきよう、よろしくお願いします！！
214 ：００８３ ：05/10/13 21:22 ID:UhYItXTU: >207
いえいえ、ちゃんと書きますよ(^^)現在NEREIDのDIP-SWは
1 2 3 4 5 6 7 8
off on on off off off off off
となっております。
割り込みレベルは出荷時の設定の状態でレベル４です。

そうそう、dcache2.rとether_ne.sys の相性ですが
私の環境では直接的には関係なかったですよ
つまりNEREIDを使う為だけの純粋な環境
ether_ne.sys float2.x xip.x ifconfig.x inetdconf.x
だけでやっても６８０００モード０３０モード問わず固まってました。
ファイル転送を扱うソフトはハイメモリでは使わない方がいいと
思ってたので、あっさりと動いたときは唖然としましたよ
ハード的なトラブルかと思い予備の電源ユニットまで引っ張り出して
装着したのにｗ

なんでハイメモリで使えば安定したのかが、今はよく分からないのですが
結果良ければ全て良しということで
これでまた６８ライフがエンジョイできます(^^)
215 ：ラキッ！＠x68ch ★ ：05/10/14 00:35 ID:???: >>214
なるほど。Nereidの設定も問題なくメモリの開始位置がぶつかっている
事も無いようです。
だとすればやはり、先頭のほうのメモリ＝本体内蔵と本体内蔵増設メモリの
部分にether_ne.sysが載っている時に症状が再現すると考えると自然ですね。
当然、ハイメモリは物理的に本体メモリとは異なりますから、
本体にあるメモリそれ自体及び、それにアクセスするXellent30や
その他の部分に何か原因があるかも知れませんので、一度点検して
おいた方が今後の使用において安心かも知れませんです。
電源装置についても新品とは言え、どうしても６８の場合は、
１ヶ月前に製造された新品という訳にはいかないので、現在問題なく
動作している間に、休ませているほうの古い電源装置をリフレッシュ
しておいた方が良いかも知れません。
久々の復活なので最初はちょっと手間が掛かってしまうかも知れませんが
もし可能であればお時間のある時に検討してみて下さい。
この度はご報告どうもありがとう御座いました。
お寄せ頂いた情報はＦＡＱに追加させて頂きます。
216 ：ラキッ！＠x68ch ★ ：05/10/14 00:49 ID:???: >>214
それと本体のDMAも絡んできますね。
ちょっとこれ以上は技術的な話題になるので触れません。
現状としてはこのままでも問題無くオーナーもご満足という事で
これ以上は必要が生じれば当方で手持ちの同じ環境で試してみます。
それにしても ether_ne.sys 等をハイメモリに上げて非常に高速化でき
快適になるという話題はワクワクしますね～。
グッジョブですよ！（＞＿＜）／
217 ：ラキッ！＠x68ch ★ ：05/10/14 09:09 ID:???: TCP/IPドライバ、Human68kの標準的なものでは xip.xβ5 ですが、
パケットwindowサイズ変更などを試してみた事がある方いらっしゃいませんか？
xps の以前の掲示板 Nereid FAQ を見ていて ftp の get でハングアップ
する事例が比較的多い事に関連してちょっと興味があったので、パケットを
ダンプしながら ftp の通信を見てみたのですが、X680x0 からの送信では
相手がパケットwindowサイズに合わせて応答するので円滑に通信可能なのですが、
X680x0 が受信する際には相手の ftpサーバが 65535 などのサイズで送って
くるのでほとんどの場合でデータが無駄になってしまっています。
また、データを正しい順序で連結する為、X680x0側では煩雑な処理を
行わなければならないのですが、もっとバッファを取れればまだ楽なのですが
いかんせん X680x0 のメモリ容量には限界があります。
試しに xip.x を常駐する際にwindowサイズ変更の -w オプションにて
65536等を指定するとmemory exhaust.が頻発して大変な事に（送受信共に）。
この事から、昨今のネットワークやサーバ事情からして、通信がより高速に
行われれば行われる程、X680x0 には辛い事態となってしまう訳です。
これって送ってくる相手にwindowサイズを縮小強制できませんでしたっけ？
ちょっと今眠くてTCP/IPの事忘れちゃいーのTCP/IP教科書見ようにも目が
しょぼしょぼり～んなので何方か是非。
よろしくお願いします。
218 ：ラキッ！＠x68ch ★ ：05/10/14 09:20 ID:???: >>217
0083さんのXVI X68000モード時に発生した症状は、これも関係していると
思います。この仮説では、程々に高速な環境、比較的高速な通信、MPUの
処理はちょっぴり遅めの場合、ワーストケースと言わんばかりに効いて
来ると思います。
219 ：ラキッ！＠x68ch ★ ：05/10/14 09:37 ID:???: 昔の事例で、LAN内の高速な通信が可能なサーバとのftpだと頻繁に
ハングアップするけど、ルータを経由したプロバイダのftpとかだと
7KB/sとかしか出ないけどハングアップせずに安定というものが
ありましたが、それは多分、途中経路のルータでパケットサイズが
小さめに調整されるのと、通信速度が遅く程々に減速されているので
データ再構成の遅延が発生しないというストーリーだと思います。
220 ：００８３ ：05/10/14 17:16 ID:frkgYrlY: ラキッ！さんの説を元に検証してみました。
現在、私のXVIは０３０モード時３３．４MHｚで使ってますが
０３０モード時２０．０MHｚに切り替え、同じようにハイメモリで
xip.x ifconfig.x inetdconf.xを動かし、全く同じ設定でFTP転送してみたところ
固まってしまいました。
このことから、高速なLAN環境下では６８の処理速度もそれなりの
性能が必要と言うことなんでしょうか。
221 ：ラキッ！＠x68ch ★ ：05/10/14 20:08 ID:???: >>220
ただ、多くの場合はこれまで同様、PROCESS=の設定や xip.x -n の数値
設定の組み合わせでそのタイミングを逃れる事ができると思います。
より高速なマシンで安定させたい場合には xip.x -n 2 などで、遅めの
マシンならば xip.x -n 8～16 とかにすると良いと思います。
それと、ftp の get の場合にはストレージの速度も足を引っ張るので、
内蔵SCSIとかの場合で本体DMAよりもMPU転送した方が速い状況が割と辛い
かも知れません。つまりは0083さんがお使いのXellent30+内蔵SCSIなどの
環境が一番微妙かも知れないという事になります･･･。
遅いマシンだと遅いなりにそもそもゆっくりと処理が行われ、LANの転送速度も
抑えられるので、こうした問題は起きにくい傾向があります。
また、Mach-2搭載の環境では「タイミング」が異なってくるのでまた状況が
違ってきます。
なので現状、Human68kでLANを利用する上において、今のところ言える事は、
「調整しましょう」という事になります。
222 ：ラキッ！＠x68ch ★ ：05/10/14 20:14 ID:???: >>220
NetBSD/x68k においては、そのような問題はありません。
223 ：ラキッ！＠x68ch ★ ：05/10/14 23:51 ID:???: xip -n 8 -w 8192 あたりも具合良さそうです。
試してみて頂けますか？
224 ：ラキッ！＠x68ch ★ ：05/10/15 00:20 ID:???: xipでトラップを使用しない、 -t -1 オプションも試してみてください。
xip -n 8 -w 8192 -t -1 などとします。
225 ：ラキッ！＠x68ch ★ ：05/10/15 00:21 ID:???: ああそうか、この辺は xip のドキュメントには無い記載で inetd.x hinetd.x からの
継承なので気付かない人も多いかも知れないなぁ。
226 ：００８３ ：05/10/15 00:45 ID:QSGqAxko: >224
なるほどぉ、そのオプションは全然気づきませんでした
今度試してみます。
227 ：ラキッ！＠x68ch ★ ：05/10/15 05:32 ID:???: その他、Neptune-Evolutionサポートコーナーを参照して、
様々なネットワークアプリケーションを利用してみて下さい。
Windowsとのファイル共有には、最近フリーウェアとなったSFU3.5が
お勧めです。
http://homepage1.nifty.com/ht_deko/neptune.html
228 ：ラキッ！＠x68ch ★ ：05/10/15 11:20 ID:???: Neptune-X/Nereidで楽々。Windowsファイル共有でバビンチョ！(X68K.NET)：
http://x68k.net/diary/?200510b&to=200510151#200510151
229 ：GACHA ：05/10/15 22:37 ID:???: 本日，PROにもNereidをセットしました。
今までは、simm版がついてたけど、これで晴れて正式版。
RAMDISKも使えるよっ！っていうことで、compact030で速度アップした
WebXpressionのキャッシュをRAMDISK上に指定する方法を試してみました。
例によってX68k.netのトップページの表示時間を測定しました。

使用ハード：X68000PRO(RAM10MB)+Xellent30PRO(20MHz)

結果
SCSI-HDD 46秒
RAMDISK 42秒

微妙ですね(^^;)
230 ：ラキッ！＠x68ch ★ ：05/10/15 23:52 ID:???: >>229
キャッシュからの読み込みよりもjpgなどの展開のほうが圧倒的に重いので
差がそれほど顕著でない？
WebXpression起動時にjpegedをメモリ上に置くようにして次回からは
メモリ上のjpegedを使うようにとかできませんでしたっけ？
というか既にそうなってしまたっけ？
231 ：００：05/10/15 23:57 ID:QSGqAxko: >224
xip -n* 8 -w 8192 -t -1
xip -n* 8 -w 8192
xip -n* 8 -t -1 の三通りを現在動作不安定の６８０００モードで
試してみたんですが、どれもダメでした・・・・ｶﾞｯｸｼ
やっぱ、ハイメモリ装着で電気的なタイミングがシビアなのかなぁ・・・
>228
それとNFS。調べたのですが、私の使っているLANDISKは今のところ
NFSは普通には使えそうにないみたいです。裏技では出来るみたいですが
便利なソフトだけに使えないのは残念・・・・

LANの設定が取りあえず落ち着いたので
バンク切り替えメモリの設定をしました。
ハイメモリとの共存は難しいかと思いましたが、
何の問題も無く動くことが確認できました(^o^)
232 ：ラキッ！＠x68ch ★ ：05/10/16 00:34 ID:???: >>231
うーん、後ソフト的に試せる事としては、xip -n の値を全て試してみるとか
PROCESS=32 10 10を PROCESS=32 10 9 とか微妙なところで探ってみるとか
本体のチェックを兼ねてメモリチェッカを何度か走らせて調べてみるとか
ですかね･･･。

LANDISKのNFSについてですが、hackネタと書きましたように仰る通りに
ちょっとしたテクニックを要するようで、せっかくの製品なのにメーカー保証が
使えなくなるなどがあるといけないので、一般的にはおすすめできるものでは
ないようですね。
ですのでその場合は日記にある通り、WindowsマシンがあればそこにSFUを
インストールすると便利だと思います。
NFSの場合、ファイル受信時の速度が改善されますし、
現在不具合のある状況についても変化があるかも知れないので
かなりオススメです。

バンクメモリについてですが、ＸＶＩでバンクメモリラムディスクを
使用する場合は、本体メモリについては本体内蔵増設までの８Ｍとして
ネレイド上のメモリは全てバンクメモリラムディスクにしてテンポラリや
ASKの変換辞書置き場などにすると良いと思います。
233 ：００８３ ：05/10/16 00:55 ID:Pd70JPO2: >232
PROCESS=3 10 10 においては-nの数値は全部試したんですが
結果は今のところ改善されなかったです。
メモリチェックも一晩中走らしたのですが異常は検出されませんでした
まぁ、この辺の設定には時間が要する作業になるようなので
ゆっくり調べていくことにします(^^)
234 ：ラキッ！＠x68ch ★ ：05/10/16 01:48 ID:???: >>233
あとはもし可能ならNFSにしてしまう方が対処としては楽だと思います。
※TCPでなくUDPを使うようにする。
Human68k用TCP/IPドライバに改良を加える事は、現状としては非常に
難しい事情があります。
235 ：ラキッ！＠x68ch ★ ：05/10/16 01:49 ID:???: >>233
そう言えば聞いてなかった・・Windows環境もあるんですよね？
236 ：GACHA ：05/10/16 13:46 ID:???: >>230
レス有り難うございます。
一応、jpeged.rはXellentのローカルSRAM上で動かしてます。
これが一番速いかなぁと。

それと、００８３さんの症状、私の方も確認しました。
サーバがWindowsのQuickFTP，クライアントがXellent30PRO(20MHz)の
環境下で、ftpf.xにて15MBのファイルをダウンロードしようとした所、
1.5MBダウンロードした時点でストップ。
保存ドライブをネレイドのRAMDISKにしたところ、6MBでストップしました。
030compactだと問題ないので、後は色々試してみようかなぁと思っています。
237 ：ラキッ！＠x68ch ★ ：05/10/16 19:37 ID:???: >>236
ftp.x の場合も同じくらいのタイミングでストップするのでしょうかね？
GACHAさんはTCP/IPとか詳しいです？？

とうとう xip.x を dis る時が来たのか・・
とかって・・『disる』って懐かしくないですか？？ｗ

それか NFS で、、と nfs.x 好きの僕が来ましたよっとｗ
238 ：ラキッ！＠x68ch ★ ：05/10/16 20:15 ID:???: 例えば、PCなどから大きなサイズの ping を打つと、
例:
　ping -s 32768 192.168.0.68
↑このようにするとしばらくして memory exhaust.と標準出力され
BEEP が鳴るのですが、この辺の処理をリカバリーする方向に変更すれば
良いように思うのですが、如何でしょうか？
239 ：ラキッ！＠x68ch ★ ：05/10/16 20:27 ID:???: リカバリーと言っても６８では処理速度でゴリ押しはできないので、
スッパリ諦めてもう一回お願いします系でないと駄目ですね。
あとは処理が重くなってきた時にはお返事しないシカト系も必要かも
知れません。
240 ：ラキッ！＠x68ch ★ ：05/10/16 20:33 ID:???: PC UNIX から ping -i0.01 192.168.0.68 とかやりながら、
X680x0 Human68k上で色々と操作して負荷を掛けるようにして
様子を見ているのですが、nfs.x の接続処理のところで、
ether_ne.sys の立花えり子さん版だと ping の遅延がどんどん
大きくなって memory exhaust. が発生するのですが、
ether_ne2_m01.sys だと同じ状況でもしばらくすると復活して
ping の遅延も 2ms くらいに戻ります。
この辺、何かあるかな？？
241 ：ラキッ！＠x68ch ★ ：05/10/16 20:35 ID:???: >>240
説明書きが足りませんでした。
etehr_ne2_m01.sys は、Mitsuckyさんのether_ne.sys 改造版 +M01です。
ダウンロードやその他ネレイド関連ソフトウェアについては、
桑島技研Ｏｎｌｉｎｅ内ネレイド特設ページをご覧下さい。
http://kuwa.xps.jp/nereid/nereid.html
242 ：ラキッ！＠x68ch ★ ：05/10/16 20:40 ID:???: そうか、元になっているコードが、
ether_ne.sys ver0.02系とether_ne.sys ver0.03系で異なって
いるんですね。
243 ：ラキッ！＠x68ch ★ ：05/10/16 23:33 ID:???: ちょっとまだチラッとしか見てないのですが、xip.x のバッファ残量に
関係する部分か 0 とイコール比較している部分があるので、今度時間の
ある時に軽く全体的に見てみようと思います。

どなたかご興味ありましたら、お時間取れましたら結構ですので、
xip.x の memory exhaust. で grep して見て頂けたらと思います。
上手くパッチできるといいなぁ。
244 ：００８３ ：05/10/17 01:41 ID:HLD+wDbA: >235
ありますよ、WindowsXPです。
ただ、このWindowsマシン、自分のじゃないので、
NFS入れたくても、あまり下手に触れないのが現状なんです(T-T)
245 ：００８３ ：05/10/17 01:47 ID:HLD+wDbA: >236
その症状、私だけじゃなかったんだ。
なんかそれを聞いて安心しました。喜んで良いのかな(^^;
246 ：ラキッ！＠x68ch ★ ：05/10/17 03:27 ID:???: >>245
段々と情報が集まってきてどうも>>243に書いてあるような部分に問題が
あるかも知れないという所あたりを妄想中です。

うー６８修理作業があるので、、しばらくお待ちください。
もしくは、どなたか、、、
もしくは、0083さんが途中にダミーネットカマして帯域制御を・・って
そんなのいきなり無理ですよね。。すみません。逝ってきます。

あ、あと・・僕はTCP/IPドライバを書いた経験は無いので、
今回の問題を僕の能力で解決できるかどうかは微妙と言うか、
正直言ってあまり自身ありませんですぅ。すみません、ごめんなさい。
しかも、xip.x は著作権問題か何かでソースファイルを公開できないと
以前、作者の方に伺った事がありまして、ディスアセンブルした結果から
修正するには更に技術的に高度な要求が発生します。
どうしましょうヒー！（必死
247 ：ラキッ！＠x68ch ★ ：05/10/17 05:22 ID:???: >>244
この機会に自分用の安いWindowsマシンを用意すると良いかも知れませんね。
どちらにせよ、インターネットでＷｅｂ閲覧などする際にもNFSをインストール
できないくらいの他人のマシンを使いつづける事はセキュリティ上好ましくないかも
知れません（＾＾；

>>245
とりあえず、ハード的な要因が薄くなったという事で、問題の切り分けが
進んでいる状況としては喜んで良いと思います。
ただ、これ以上は、僕が何回か書いておりますように歴史的に見ても対応が
困難な状況がありますので、少々我慢をして頂かなければならない部分が
あると思います。
元々、Human68k はネットワーク接続を前提としたOSではありませんので、
根本的な事を言えば、Human68k互換ネットワーク対応新OSを新しく作り
上げる必要があり、これは現時点では現実的な話ではない事は言うまでも
ないと思います。
なので、とりあえずは僕のほうでもTCP/IPドライバにパッチを当てるなどの
試みをしてみますので、0083さんは症状が再現する68000モードで何とか
それを切り抜ける方法を探してもらえますか？
248 ：ラキッ！＠x68ch ★ ：05/10/17 06:00 ID:???: ああそうだ、また基本的なことですが、転送が止まった時に、[HELP]キーを
押してみてください。押している最中にファンクションキーの脇にXが出ますか？
試してみて下さい。
※xipの強制タイムアウト機能です。但し、タイムアウトできるかどうかは
　状況に因るそうです。
249 ：ラキッ！＠x68ch ★ ：05/10/17 06:33 ID:???: X68030だと XF1 を押しながら起動でX68000相当や、
XF2 を押しながら起動でX68000XVI相当などの簡易実行速度調整機能が
ありますが、それを利用して再現チェックをしてみても、なかなか再現
しませんね。GACHAさんのX68030ではどうですか？
X68000色々機能参考資料(STUDIO KAMADAさん)：
http://homepage2.nifty.com/m_kamada/docs/unlistedx68k.htm#startupkey_xf1

あと何かマルチキャストパケットとかがちょっと多めに流れるとマズいですね。
昨今のネットワーク環境とは何故こうもX68000に厳しいかなぁ～（＾＾；汗
250 ：ラキッ！＠x68ch ★ ：05/10/17 06:49 ID:???: [zip] (46KB)

マシンを激遅にしても再現しません記念 xip_l01.x アップロード。
xip_l01.zip になってますので適宜解凍してX68に持っていって
試してみてください。
251 ：ラキッ！＠x68ch ★ ：05/10/17 08:26 ID:???: >>250
イカんです！ただワーニングのBEEPと文字列切っただけのものをＵＰして
しまいました（汗
バッファの最後尾に余裕を持たせるつもりの改変を加えたものは後程。
それまでは -+-s: スタックサイズ指定オプションで 256KB とかを
指定してみてください。
252 ：ラキッ！＠x68ch ★ ：05/10/17 08:49 ID:???: X68030環境でも再現するようになりました。
XF1を押しながら起動とcache offです。
再現しなかった状況はautoexec.batでcacheがonになっちゃってました。
xip -n 8 -+-f -+-s:262144 -w 4096 -t -1
で、FTPF.x ver1.02 にて45MBのファイルを受信中に25MBのところで
転送が止まりました。[HELP]キーでファンクションキーの右脇にXが出ます。
BREAKも利くし、COPYキーも利きます。
次はスタックをもっと大きくして試してみます。
253 ：ラキッ！＠x68ch ★ ：05/10/17 10:18 ID:???: FTPF.x Ver1.02にて get で転送が止まる症状が再現する環境で、
45MBのファイル転送が無事に行えるようになりました。
---
X68030 XF1押しながら起動cache off確認後 ftpf.x ver1.20にて45MBの
ファイル受信テスト・・ＯＫ
---
PROCESS=32 10 10
---
xip -n 20 -+-f -+-s:524288 -w 4096
---
遅いマシンの場合は思い切って -n の値を上げた方が良いように思います。
254 ：ラキッ！＠x68ch ★ ：05/10/17 10:31 ID:???: X68000 PRO (10MHz) + Xellent30PROの方で下記のように設定されている
方がいらっしゃるようです。

[CONFIG.SYS]
PROCESS = 16 10 50
device = \sys\ether_ne.sys

[nereid.bat]
xip -n 4 -t -1 -+-f -+-h:524288 -+-s:262144
ifconfig lp0 up
ifconfig en0 192.168.1.11 netmask 0xffffff00 up
inetdconf +router 192.168.1.1 +dns 192.168.1.1 -rip
255 ：ラキッ！＠x68ch ★ ：05/10/17 13:41 ID:???: >>253
駄目だ・・オリジナルのxip.xだと転送が止まってしまいます。
謎パッチの不思議パワー改造版は転送が止まりません。
時間の掛かる検証なのでまだ数回ですが確率１００％は辛いです。
後で何故か止まらない不思議パワー版xip_L02.zipをアップします。
便宜上区別する為にファイルネームを変えてますが、あくまでもこれは
実験版で正式なリリースではありません。
256 ：ラキッ！＠x68ch ★ ：05/10/17 14:11 ID:???: [zip] (46KB)

↑xip.xβ5改造版（不思議パワー実験版）xip_L02.x[無保証]
xip.xβ5を使っていてftpのgetで転送が止まってしまう症状が出る場合のみ、
くれぐれも注意しながらお使い下さい。
xip.x原作者の方に迷惑が掛からないように、改造版についての質問などは
こちらのスレでお願いします。
下記環境で症状が改善する事を確認しています。
X68030 XF1 押しながら起動 cache off X68000相当の処理速度
Nereid白
Human68k Ver3.02
PROCESS=32 10 10
xip_L02.x -n 20 -+-f -+-s:524288 -w 4096
約45MBのwavをftpでget。
257 ：GACHA ：05/10/17 22:46 ID:???: 永井様。
色々と、対応有り難うございます。
早速ダウンロードして、>>256,>>254の設定などを試してみました。
(PRO+Xellent30です。)
でも、やっぱり大きなファイルは止まってしまいますねー。
現在、Processなど色々値を変更して試しています。
258 ：○○電子工業 ：05/10/17 23:30 ID:j2wWECrg: >>256
そういや、当方でも止まる現象が出ました！SUPER+Xellent30sですが。
X68030+060Turboでは何とか停止しません。
なかなか触ってる時間が無いので、今度の休みにでも試してみます。
259 ：ラキッ！＠x68ch ★ ：05/10/17 23:59 ID:???: 駄目か・・XVIとXellent30は押入れという海外の住んでいるのでｗ
改修作業とかで場所が無くて出せないので今試せるのは>>256の限りです･･･。
現状で止まる現象が出るのが全てXellent30絡みなのが非常に何かあり気
で興味が湧きますが、あてずっぽうでパッチ当てまくっても仕方が無いので
皆さんの知恵をお借りしてから・・。
原因が複数あって僕の対応が噛み合ってないんでしょうね。
とりあえず、久しぶりに dis って楽しかったです。皆さんにもオススメ～。
260 ：ラキッ！＠x68ch ★ ：05/10/18 00:35 ID:???: そうだ！GACHAさんや想田さんはお分かりになるかな！
Xellent30をお使いの時、内蔵SCSIをお使いですか？
内蔵SCSIをお使いの場合、内蔵SCSIの転送モードは
DMAですか？MPUですか？その違いにより挙動に差はありますか？
それと、大きなファイルの尺度ですが、数ＭＢ単位ですかね？
やり取りした容量も併記して頂けると、何かが刺さる可能性が高まる
「時間」というものを想像する為の尺度になるやも。
また、XT30DRVを組み込まない状況でどうなるか、試してみて頂きたいのですが・・。
261 ：ラキッ！＠x68ch ★ ：05/10/18 00:39 ID:???: >>257
>>258
あと、当方で転送が止まらないのを確認した ether_ne.sys は、
etehr_ne2_m01.sys 、Mitsuckyさんの ether_ne.sys 改造版 +M01
ですからね～。
前提条件色々とあって物凄く大変なことになってますが、現在出ている
ether_ne.sys各種は全てそれぞれ別物ですからね～。
いつか統合できると良いですね～。
262 ：００８３ ：05/10/18 00:49 ID:vfX7R/YQ: 私もダウンロードして、いろいろ試したんですが、ダメでした・・・・
私の場合の状況は１MB前後のJPGファイルを５０個纏めて
転送しようとしてるのですが、やはり固まります。

ちなみに、DMA、MPUのどちらの転送で試しても
変化は見られなかったです
また、XT30DRVを組んでも組み込まなくても状況の改善には至らなかったです
263 ：ラキッ！＠x68ch ★ ：05/10/18 00:55 ID:???: テストする際にはなるべくX680x0と転送元のftpだけの接続になるように
接続を工夫してみて下さい。既製品のネットワーク機器（ルータとかも）が
あるとどんなパケットを出しているか分かりません。
僕のほうで確認しただけでも、大きめのパケットや細かいパケットでxipが
ハングアップする現象を確認していますので、ftp転送中にそれが起これば
転送が止まる事になります。
あともし可能ならダムＨＵＢ（リピータＨＵＢ、バカＨＵＢなどと呼称する人も居ます）
を接続するなどしてパケットキャプチャして刺さる時に何か異常がないか
見て頂きたいのですが・・。
うーお願いするのが段々辛くなってきましたが、更に、転送中にコリジョン
パケットの衝突が起きているかどうかも確認して頂きたく、簡単な確認方法
としては、スイッチングハブでその表示があるものを使うなどです。
ただ、これは僕のテスト環境でも用意できていて、コリジョンはあるんだけど
特にそれが問題とはなっていないようです。

ふぅ・・という訳で割と大事なんですが・・どうしましょう･･･。
264 ：ラキッ！＠x68ch ★ ：05/10/18 00:59 ID:???: >>262
そのJPGファイルを纏めて５０個転送指定して転送が止まるのは何個目
とか、いつも同じくらいですか？
またお持ちの機種はXVIだけですよね？
XVIの本体内（電源部以外）のアルミ電解コンデンサもなかなかお疲れ
なので、その点も心配だったりします。
あともしよろしければ、Xellent30を取り外して同じ結果になるか
見てみたいのですが・・なんかどんどん大変な事になりますが・・。
265 ：ラキッ！＠x68ch ★ ：05/10/18 01:01 ID:???: そのJPGファイルは一個あたりだいたいでよいのでファイルの大きさを
教えて下さい。
細かいのを連続で駄目なのかなぁ。
いやでも、経過時間内の確率っぽいなぁ。
266 ：ラキッ！＠x68ch ★ ：05/10/18 01:03 ID:???: ファイルネームとか普通に8+3とかですよね？
abc.jpg
def_geh1.jpg
等。
267 ：ラキッ！＠x68ch ★ ：05/10/18 01:05 ID:???: ＞0083さん

あと、転送が止まった時に [HELP]キーを押してファンクションキーの
右脇に X が出るか見て下さい。
あと、[COPY]キーを押してみてね。
268 ：ラキッ！＠x68ch ★ ：05/10/18 01:20 ID:???: みんな～
inetdconf.x に -rip をくっつけて。
269 ：ラキッ！＠x68ch ★ ：05/10/18 01:24 ID:???: >>262
ether_ne.sys はとりかえた状態ですか？
ご面倒でしょうが、毎回、試した状況を書いて頂かないと、この
流動的な事態になっている時期なので、色々と分かりません。
当方で転送が止まらないのを確認した ether_ne.sys は、
etehr_ne2_m01.sys 、Mitsuckyさんの ether_ne.sys 改造版 +M01
ですからね～。
270 ：ラキッ！＠x68ch ★ ：05/10/18 01:31 ID:???: Xellent30系とMach-2の組み合わせの状況も知りたいですね。
271 ：ラキッ！＠x68ch ★ ：05/10/18 02:02 ID:???: X680x0 の ftp の get を外から止める方法が分かりました。
比較的遅いマシンだと、ftp の get それ自体は問題無くできますが、
転送の最中に ping や arp などのパケットが加えて流れてくると
応答不能になります。
この傾向はより遅いマシンで顕著となります。
多分、今回の地雷はこれです。

再現状況
X68030 XF1起動 cache off Mach-2 バスマスタ転送
Human68k Ver3.02
PROCESS=32 10 10
etehr_ne2_m01.sys
xip_L02.x -n 20 -+-f -+-s:524288 -w 4096
ftpf.x ver1.02
5KB～50KBのMAGファイル110個転送中に同じLAN内のPC-UNIXから
ping を打ち、４つ目で応答なし。ftpの転送も停止。

PING 192.168.0.68 (192.168.0.68): 56 data bytes
64 bytes from 192.168.0.68: icmp_seq=0 ttl=254 time=15.384 ms
64 bytes from 192.168.0.68: icmp_seq=1 ttl=254 time=82.911 ms
64 bytes from 192.168.0.68: icmp_seq=2 ttl=254 time=12.645 ms
^C
--- 192.168.0.68 ping statistics ---
8 packets transmitted, 3 packets received, 62% packet loss
round-trip min/avg/max/stddev = 12.645/36.980/82.911/32.497 ms

という感じです。
どうしましょう（＾＾；汗
272 ：ラキッ！＠x68ch ★ ：05/10/18 02:10 ID:???: ぶっ飛んだあとも、割り込みは掛かるしハードは正常に見えているので、
こりは本格的にソフトの問題になってくるのですが、既述しました通り、
本来ネットワーク接続を前提としたOSではないHuman68kなので、、、
どうしましょう！
どうしましょう！ったら、どうしましょう！
（＾＾；
ぶっ飛んだあと、メモリの中身とか破壊されてるんでcommand.xとかも
変な動きしちゃうんですけど、何とか nereidEB.x 他に辿り着いて
チェックできました。

で、この飛び方だと watch dog とかそういう問題では無くなってしまうので
どうしましょう～。どうしましょう～。あたふたあたふたっ（＾＾；
273 ：ラキッ！＠x68ch ★ ：05/10/18 02:15 ID:???: おう！そうだ！
/etc 以下の protocols の内容変更で回避できるか？？
274 ：ラキッ！＠x68ch ★ ：05/10/18 02:26 ID:???: うおー駄目だ～protocolsに書いてあるicmpの行を削除してもpingに
応答するよ～。
６８の手前でパケットフィルタできませんかね。

ここで皆さんおさらいと確認です。
環境変数 SYSROOT は設定してありますか？
してない方は逝ってヨシですｗ
/etc 以下のファイルはきちんとありますか？
この期に及んで /etc ってなーに？と言っている方は居ませんよね？
275 ：ラキッ！＠x68ch ★ ：05/10/18 04:05 ID:???: >>274
という訳で、僕もSYSROOTが設定されてませんでしたが何か。というお約束ｗ
皆さんとは生活のサイクルが異なるので飯喰ってきたりして（＾＾；

この ftp の get で転送中に何かパケットを受け取るとハングアップする
問題についての対処法ですが、現在のところ、特にネットワークに詳しい方
でない場合は下記のような対処が考えられます。

１．既製品ルータなどを同じLANに繋がない。
　これは一定期間おきに arp などで接続されているホストを
　検出しに来る（パケットを出す）からです。
２．Windowsとのファイルのやり取り時には、WindowsのUPnPをOFFにする。
　　その他、パケットを出しそうなアプリケーションの起動＆常駐は避ける。
３．接続先FTPサーバにはFreeBSDをお奨め。接続先WindowsはWindows2000をお奨め。
４．これを機会にネットワークを勉強してみよう～！

といったところです。
また、Xellent30機の場合には 0083さんが挙げたようなloadhighでドライバを
動かして何とか切り抜ける方法があります。

現状でもTCP/IPドライバの機能や出来は中々のものなので、あとはこの、
突き刺さる瞬間だけを無くせばHuman68kでは概ね満足な結果になると
思うんですよね。これってether_ne.sysのほうで何とかできるもの
ですかね？
276 ：ラキッ！＠x68ch ★ ：05/10/18 04:08 ID:???: あとは0083さんのLANDISKが何か余計な振る舞いをしてくれなければ
良いのですが・・親切機能満載の多機能高性能な周辺機器なので・・
ドキドキ・・（＾＾；

それにしても刺さる瞬間、とても残念ですね～。
277 ：ラキッ！＠x68ch ★ ：05/10/18 04:14 ID:???: 問題のトリガが分かったので、この他にも何か手がないか、
現状の条件内で何とかこれを回避する他の方法も探してみます。
278 ：ラキッ！＠x68ch ★ ：05/10/18 04:16 ID:???: あっれーオリジナルのxipだとping一発目でもう症状が再現されちゃうん
ですよね～。
xipをもう少しイヂってみようかしらん。
279 ：ラキッ！＠x68ch ★ ：05/10/18 04:42 ID:???: あれちょっと待った。
ftpf.x ver1.02 を動かしている時に、外から68にping打っていると
[a]キー（全てのファイル選択）をするとpingが止まるぞ。
もう一回[a]を押すと押した間のpingは通る。
何か地雷がありそうな予感。
280 ：ラキッ！＠x68ch ★ ：05/10/18 04:50 ID:???: PROCESS=32 20 20
で、だいぶ粘るようになった。
281 ：ラキッ！＠x68ch ★ ：05/10/18 05:04 ID:???: というのも偶然のタイミングなんだろうなぁ。
ftpサーバの方が前回の強制切断で接続が待たされる時に、
そこを見計らって ping を打つとエラー：接続に失敗しました。
になって二度と xip.x が甦らないしなぁ。
どうしようかなぁ（＾＾；
282 ：ラキッ！＠x68ch ★ ：05/10/18 05:08 ID:???: それとああそうか、FTPだけじゃなくてHTTPとかはどうでしょうね。
xgetで割と大きめのファイルをダウンロードするの。
誰かテストできますか？
283 ：あるきち＠京ぽん ：05/10/18 08:27 ID:75ghKhAw: なんか熱いなぁ。
自分も早くネレイド環境を整えたいな。
284 ：ラキッ！＠x68ch ★ ：05/10/18 08:58 ID:???: >>283
あ・・あるきちさん、お待たせして本当に申し訳ありません。。。
早くお返しして是非、この問題解決への参加をお願いしたいと思います。
この問題が解決できれば、長年ちょっと不便に感じていた事がすっかり
解消されるかも知れないので期待が膨らみます。
285 ：GACHA ：05/10/18 10:24 ID:???: 永井さん。

風邪を引いて、会社を休んだので、取り敢えず色々試してみましたぁ。

FTPサーバプログラム：QuickFTP
クライアント：ftpf.x
確認方法：80MBのwavファイルをftpfでGET

・xip.x or xip_L02をLOADHIGHで動かす。
私のはノーマルXellentですので、ハイメモリ256KBしか積んでおらず駄目でした。
(メモリが足らないとメッセージが出ます、そんなに消費するんでしょうか?)

・ルータなどを外す
そういえば、無線LANのベースステーションを繋いでいたので、外しました。

・ether_ne_m02.sysにする
こちらは長時間繋がっているのですが、get時の転送速度がノーマルether_ne.sysに
比べて何故か1/10(20KB/s→2KB/s)に落ちてしまうので、どこまで転送できるかは、
試しておりません。

・process，その他の値など。
掲載されていたXellent30PROの設定，永井さんの安定した設定，その他数値の
組み合わせなど、考えられる範囲で調整。

何れの場合も途中で転送が止まり、helpを押してもXマークは出るが転送中断も
復帰ができず。
030compactでも1回は完走しましたが、1回同一症状が出ました。

止まる時のファイルサイズは数百KB～十数MBまで様々です。
また、030compactの方が、止まる場合でもかなりファイルサイズが大きくなってから
止まります。(転送速度は、56KB/s位です)

以上ですが、この結果を見ると、CPUの速度に依存している様な気がするのですが、
如何でしょうか？
あまりお役に立てず済みません。
286 ：あるきち＠京ぽん ：05/10/18 11:04 ID:fUjMyLbo: >284
あ、いえいえ。
SUPERでもネレイド環境は作れるので、コンパクツの修理とは関係ないですよ。
ディスクの調子が悪くてランプつきっぱなしなることが多いので、あまり68をいじってないのですよ。
IOの例の奴に替えようかな。
しかし、68がNFSに繋がればシンクライアント化も出来そうですな。
SCSI機器が入手困難な今日、とても有用です。
SCSIディスクだけでもあればあとはWinマシンからの共有で賄える。
いや、FD起動にすればディスクすら不要か。ちょっと遅いけどｗ
287 ：ラキッ！＠x68ch ★ ：05/10/18 12:02 ID:???: >>285
GACHAさん、ご報告ありがとう御座います。
皆さんからの報告と、夢中になって現象を再現していたら、何ということでしょう
今だ！とか心の中で叫んで ping 狙撃して確実にしとめるゴルゴラッキョが
できるようになってしまいました･･･。
X68030 XF1 ～ 060turbo まで、自由自在です。
しかも、初代Nereid、Nereid緑、Nereid黒、Nereid青、Neptune-EvolutionIIまで
全て同様にサービス不能攻撃可能です（＾＾；汗
※念のために満開060turbo高速化改修対応・非対応論理も両方試しました。
X680x0が put 中は若干難しいですが、get 中は簡単に落とせます。
こういうのを巷ではサービス不能攻撃DOSとか、脆弱性とか言うのでしょうかねォｗ

まいりました、パケットが飛んでこられてはマズい瞬間が確実に存在し、
その「マズい瞬間」の長さがMPUの速度に関係している事が分かりました。
僕の調べた限りなので、まだ結論を急ぐべきではありませんが、
感触としては、これは歴史的に引き継いできた問題だと思います。
そしてこの時点では、この問題がネプチューンのドライバで回避できるのか
TCP/IPドライバに問題があるのか等は、まだ分かりません。

次のフェーズでは、ネプチューンのドライバ部分を見ていこうと思います。
RTL8019AS のドライバ記述例などを大募集します。
もしよろしければ、このスレに情報を上げてください。
他機種用、組み込み用、使用言語などは問いません。
何でも分かりませんが、分かりますし！？、僕以外のエロい方はぜんぜん平気です。
ネットで検索すると結構出てくると思うのですが、うー僕は修理もしないと・・
とか、悶々としていたらネレイド２次ロット分のお申し込み枠が残り３です。
やべー全部並行してできないでしょう。どうしましょう。僕のPROCESS=は最初の数字が
1しか許容しないんで全然PROCESS=の意味ないですね。すみませんｗ
288 ：ラキッ！＠x68ch ★ ：05/10/18 12:10 ID:???: で、こういう情報を上手く纏めると、ナレッジベースというか、今後に
役立つ情報源にできるのですが・・。
僕はあまり得意ではないなぁ。
まぁとにかくwikiに書いていきますかねっ
289 ：ラキッ！＠x68ch ★ ：05/10/18 12:12 ID:???: >・xip.x or xip_L02をLOADHIGHで動かす。
>私のはノーマルXellentですので、ハイメモリ256KBしか積んでおらず駄目でした。
>(メモリが足らないとメッセージが出ます、そんなに消費するんでしょうか?)

そうでしたそうでした！
xip.xだけでも、デフォルトでバッファで256KB、スタックで128KB取るので
ぜんぜん足りませんね。
0083さんはいいなぁ。僕も昔ツクモハイメモリ持ってたんですが、今は
生基板しか無いですよ～。しかも不良品ｗ
290 ：GACHA ：05/10/18 12:30 ID:???: 永井さん。
後そういえば、私の環境下では、xipの替わりにhinetdを使用すると、
pingも通り、FTPサーバにも接続は出来るのですが、get,lsなどの
コマンドを送信すると確実に固まります。
(quitは出来る)
今回のことと、関係は薄いかと思うのですが、何か参考になれば・・・。
291 ：ラキッ！＠x68ch ★ ：05/10/18 12:30 ID:???: なんだ、Neptune持ってるじゃん。と、言わないで下さい・・
ジツは、ジツはですよ、2001年にいりやさんから直々にお借りしまして、
えぇ、お借りしまして、お借りしましてですよ、ギャッフン・・＿（＿＿；
いりやさん、このスレなんか絶対見ていてくださらないとは思いますが、
僕はこうして今でも頑張っています。神よ長期間お借りしっぱなしですが
お許しください・・お許しくだ・・バキッ

という訳で僕のものではなく、生基板も一緒にお借りしたのですが、
僕のではなく・・うぇーん、、ほすぃ・・・
292 ：ラキッ！＠x68ch ★ ：05/10/18 12:46 ID:???: >>290
quit はできる固まり方＝データポートの通信ができていなくて
lsの結果とかが返ってきてないとかですかね？？
でも、どうしてそうなるんでしょうね。
xip.xのhistoryにWindows98との接続でハングアップするバグを取る
旨の記述がありますが、関係してますかね？
あそうだ、ftpクライアントによってはデータポートを再利用しようとして
２回目以降の接続で不具合が起きるものがあります。
ftp.xはその点はＯＫでしたっけ？
293 ：ラキッ！＠x68ch ★ ：05/10/18 12:53 ID:???: ひとまずー、ether_ne.sys +M01 を DEBUG 指定でコンパイルして
試してくれるチャレンジャー大募集！
突き刺さる瞬間のメッセージを書いてキボンヌ。
DEBUGINTでも良いかも～。
受信時のバッファ残り少ないよ～とコリジョンなどの場面での挙動とか
どうですかね。
どの辺りか、秋葉原のおでん缶でも賭けますか～？ｗ
294 ：ラキッ！＠x68ch ★ ：05/10/18 12:58 ID:???: >・ether_ne_m02.sysにする
>こちらは長時間繋がっているのですが、get時の転送速度がノーマルether_ne.sysに
>比べて何故か1/10(20KB/s→2KB/s)に落ちてしまうので、どこまで転送できるかは、
>試しておりません。

060turboでの送信時に多少不具合があった時にウェイトを多めに挿入した
そうなので、それで遅くなっているのだと思います。
Mitsukyさんのドキュメントによれば、060turbo以外の人は関係無い
ウェイトだという事ですが、このwait挿入で速度は遅いけれども、
絶対に刺さらないようになるという事であると、今回の問題についても
影響が出ます。
仮説はこうです。パケットを受信した後は何某か応答のパケットを出すので
それが突き刺さって停止に至っている可能性もある。
となります。
もしも可能であれば、長期テスト実施お願いします。
295 ：GACHA ：05/10/18 13:39 ID:???: >>294
ええと、確か民法上借用品に関して、一定期間返却の請求がない物に
関しては、所有権が移動します。(つまり、踏み倒し)
という訳で、たぶんそのNeptuneXは、現在永井様の物orもうすぐ永井様
の物になります(^^;)

冗談はさておき、ether_ne_m02.sysにて現在実験中です。
途中ping攻撃を仕掛けていますが、未だに停止する様子無し。

しかし速度は3.5KB/s・・・。
ところで、m01ってどこでダウンロードできるんですか?
Mitsukyさんのページに置いてあるのは、m02だし・・・。
296 ：ラキッ！＠x68ch ★ ：05/10/18 13:46 ID:???: >>295
え！マジですか！うれ！・・ドカバキグシャッ　ツーッツーッツーッｗｗｗ

ping攻撃も狙いすましてヒットした時にはヤッター！と思いますね！
って、喜んで良いのだろうか・・（－－；汗

m01は下記URLからダウンロードOKです。
http://www2j.biglobe.ne.jp/~iritani/bin/ndrv_m01.Lzh
297 ：ラキッ！＠x68ch ★ ：05/10/18 13:47 ID:???: 店長すみません、ちょっと休憩逝ってきまつ！
298 ：GACHA ：05/10/18 15:12 ID:???: >>297
1時間程度，ether_ne_m02.sysでping攻撃も仕掛けてのですが、止まる
気配がないので一時中断しました。
永井さんの方でether_ne_m02.sysで使用した場合はどうですか？
pingで止まったりしますか？
299 ：ラキッ！＠x68ch ★ ：05/10/18 21:34 ID:???: >>298
早速試して報告します！
300 ：ラキッ！＠x68ch ★ ：05/10/18 21:37 ID:???: 今回、皆で発見した「刺さる瞬間」というのは、安定して通信が
行われている場合は一定期間毎に訪れるので、pingの間隔も一定ですから
時と場合によっては永久に当たらなかったりもするので慎重に検証する
必要がありそうです。

252KB

新着レスの表示

掲示板に戻る全部前100 次100 最新50