It is local - in the next rack - and we are aware of the frame issue on router and win server.
Appreciate all the responses.
(btw - our 2.5 hr export * 10% = 15 minute savings)
We are looking at the data provider involved - currently OLE DB in iSeries Access...
Jim

----- Original Message ----- From: "DrFranken" <midrange@xxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Monday, October 08, 2012 2:32 PM
Subject: Re: Ethernet Max Frame Size


Jim's basically got this right. If the entire path from the i to
whatever device it's communicating with doesn't handle the frame size
you've selected then the benefit won't be realized. On the way from i to
the target the packet will get fragmented as Jim mentions. The
re-assembly of the data is handled all the way at the far end. One issue
that can actually hurt here is that if you send a jumbo frame let's say
it's 8192 bytes and it gets fragmented along the way due to a link with
576 byte (minimum size) frames due that guy is getting 16 frames while
you sent only one. OK fine but what if of those 16, one frame doesn't
make it? The i then has to send the 8192 by frame over again so errors
on com lines are exacerbated by jumbo frames.

Normally the best use of jumbo frames is for local Ethernet transmission
rarely does it help when crossing the Internet.

- Larry "DrFranken" Bolhuis

On 10/8/2012 1:44 PM, Jim Oberholtzer wrote:
Doesn't the switch network need to all have the same frame sizes set in
order for this to be of any value?

If for instance the switches in the network are all configured for 1496
( I think that's the default ) then when it sees a frame of 8996 it has
to break it down into smaller frames (1496) and send them out. Then on
the other end, the switch there waits for all the frames to arrive and
rebuilds the 8996 frame, then sends it on. All times however many
switches get into the transmission.

I may have over simplified the process a bit but I'll bet the TCP
switches are not configured for the larger frame sizes nullifying any
positives you might have seen.

Another question is the base application on the orginal box. Jim says
it's normal on line during the day and large file batch at night. You
might need to create two lines one with normal 1496 frames and one with
jumbo frames. Optimizing for the large file transfer may kill normal on
line performance depending on the network.

Before I would switch the frame size on the main network connection, I'd
get some one in with monitoring software to tell you what's going on.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 10/8/2012 12:29 PM, Gqcy wrote:
I can't answer you question on "work best",
but I can say that a month ago we changed our max frame size from
1496 to 5984.
We did it for the same reasons you spoke of, we have nightly batch
processes that FTP lots of data across a dark fibre connection (over
20GB connection).
We haven't noticed any determent in the daily processes, and only
decreased the time of our nightly process by no more than 10%.


On 10/8/2012 10:34 AM, J Franz wrote:
Our ethernet definitions still have the 1496 max frame size.
1Gb ethernets(2), v6r1 (but not fiber)
Would like to change to 8996 , but network side concerned the higher frame side
will affect
app performance with many .net apps accessing our db2.
We have heavy interactive use in day, and big data export nightly (which is why
the

idea to increase frame size).
Any thoughts on what would work best.
Jim Franz
--

--
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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.