|
Actually, Marty, this situation didn't include the INS either. I guess you could consider that statement as a curve ball on my behalf. Your post regarding the T/R and Ethernet environment caused me to get here early this morning and disable the T/R line and change DNS to route the T/R network clients across the bridge. Once that was completed then I restarted the FTP of the 3.6GB file which died after 3.2GB this morning. This time it transferred the data in less than ten minutes. Thanks Marty for a constructive post. Ken Slaugh (707) 795-1512 x118 Chouinard & Myhre, Inc. CA/400 Certified Specialist iSeries Network/MSE Administrator http://www.cm-inc.com/ "Urbanek, Marty" <Marty_Urbanek@xxxxx To: "'midrange-l@xxxxxxxxxxxx'" omm.com> <midrange-l@xxxxxxxxxxxx> Sent by: cc: midrange-l-bounces@x Subject: RE: Why is the iSeries so slow idrange.com 08/13/2003 08:27 AM Please respond to Midrange Systems Technical Discussion Ken, The scenario I spoke of did not involve INS/IXA. I have one T/R NIC and one 10/100 ethernet NIC, both totally owned by OS/400 (none of that "sharing" that can be done between NT and OS/400). I would think that introducing INS/IXA makes it a different ballgame. Without INS/IXA, it is easy enough to test if you can find a time when one of your interfaces isn't. In my case, most people come in through the token-ring, so I just go into WRKTCPSTS *IFC and stop the ethernet interface. Bam, the next FTP session runs great, even on 16Mb t/r versus 100Mb ethernet. It probably doesn't get fixed because it probably isn't broken. I still suspect there is a configuration problem that can be solved. The throughput you are getting is too crappy to just be the "clunky old AS/400". Generally the iSeries works pretty well, and most of the problems I've seen have been the result of configuration errors (i.e. my fault). We subscribe to IBM Support line and have had very good result with those folks helping us work through situations like this. We've just never needed this one bad enough that I could spend the time getting to the bottom of it. Sorry I don't know the real answer. Maybe somebody out here can expose some of the pitfalls of this mixed-interface scenario. I would think that having correct gateway for each interface would be crucial, and I'm not sure how you set that up when you have multiple intrfaces on different network segments. -Marty ------------------------------ date: Wed, 13 Aug 2003 07:47:12 -0700 from: Ken.Slaugh@xxxxxxxxxx subject: RE: Why is the iSeries so slow Marty... I do believe you have tripped on the same issue. The dual Token Ring and Ethernet adapters is certainly the most reasonable situation discussed so far and we certainly have exactly this situation. I guess this brings up the next question... Why? If this impairs throughput so badly then why is it supported or why doesn't it get fixed? This certainly looks like a good reason to avoid the integrated Netfinity server as well with it's virtual T/R adapter. :) Too bad the iSeries still doesn't play well with others. It a great place to store the data, but if you can get the data off the disk then what's the point? Ken Slaugh (707) 795-1512 x118 Chouinard & Myhre, Inc. CA/400 Certified Specialist iSeries Network/MSE Administrator http://www.cm-inc.com/ _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.