If the discussion is with the internal virtual ethernet that runs on the
backplane and never makes it out to the switch, then of course many of the
limitations Larry just pointed out don't exist. Therefore, when on the
internal virtual network, you can set those ethernet definitions up to 8896
frame size and set the TCP buffer to be very big and you'll get excellent
throughput. The caveat to setting the TCP buffer size is simple, it's
universal for ALL TCP traffic, so as Larry pointed out if there is one slow
ethernet connection, and it's critical, you should tune for that interface.
If it's not critical or performance is good with the larger buffer, I'd
leave it big.
Remember large frames will not play nice when using the virtual LAN with the
short stack in SST/DST for remote PTF and LPP installation.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> On Behalf Of DrFranken
Sent: Wednesday, November 21, 2018 3:18 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Determining Maximum Frame Size - TCP Buffer size
They are of course two distinct though related things.
Think of Frame Size as the 'biggest truck allowed on the highway'. If your
'highway' allows for standard Ethernet trucks that would be 1,500 bytes.
Subtract a tick of overhead and you get 1496. If your 'highway'
supports huge ass Michigan trucks then you get 9000 bytes or with overhead
8996 bytes. What determines this?
#1 the switches in your network. All switches support 1500 Byte frames and
many, dare I say most, support 9000 byte frames, also known as 'Jumbo'
Frames. However virtually ALL switches need to be configured for Jumbo
frames to use them. Using Jumbo frames means more memory allocated per frame
and thus fewer frames in total can be in memory. So don't enable them on
your switches if you do not need them.
#2 is the other devices in the network. So if your IBM i and your switch
both support Jumbo frames but your router or firewall does not then it's
pointless to turn them on. Much like 1000 miles of highway supporting a
massive truck but one bridge does not, your truck cannot get from here to
there. At that bridge you would need to off-load to smaller trucks to cross
that bridge. In the case of the network once offloaded the traffic is never
reloaded to the big truck it stays as little trucks all the way to the
destination.
On the local network (talking Ethernet here, not IP) the devices will
negotiate: "Hey can you take Jumbos??" if the far device says yes then we
can use 'em. If not then we send smaller packets. That's pretty easy.
Going further though if you can get a Jumbo frame to your firewall but from
there out to your vendor or customer only 1500 bytes are supported then the
firewall has extra work to do to 'unload the big truck onto smaller trucks.'
So your IBM i saved a tick of work sending fewer bigger packets but the
firewall got a lot more work by having to do fragmentation at the IP layer.
Now the buffers on the other hand are the amount of memory allocated in
which to store packets that have not yet been acknowledged by the far end.
The further the distance, read 'higher the latency', the longer it takes to
get acknowledgement from the far end. If the pipe is fast once the buffer is
full IBM i must stop sending until some packets in there are acknowledged by
the far end. Then it can free that memory and use it for more packets. So
bigger buffers can help on fast lines. Note that this is a TCP thing only,
UDP does not do this as it merely sends and forgets. IBM i doesn't use much
UDP and for good reason.
Hope that helps!!
- Larry "DrFranken" Bolhuis
www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.
On 11/20/2018 2:12 PM, Steinmetz, Paul wrote:
Started a new thread for this.
<With respect to the TCP buffer size, I almost always set that up higher
anyway so I forgot to mention it, yes setting the buffer size to match the
maximum frame size you use would be prudent.
For Maximum Frame Size, we been using the 1496 default setting since day1.
For TCP Send and Receive Buffers, these were changed back in 2005 from
default of 8192 to 65,536.
How does one determine the Maximum Frame Size?
How does one determine the Maximum TCP buffer Size?
Can Maximum Frame Size be increased from 1496 to 8996, or higher? . any
impacts or gotchas changing this?
Can TCP buffer sizes be increased higher than 65,5536?
All switches, routers, firewalls, and the remote destination will all
impact these settings, correct Any other impacts or gotchas changing
these?
Maximum Ethernet frame sizes
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/rzajy/rzajymaxim
umethernetframesize.htm
Optimization of window size for different operations on the same
system
https://www.ibm.com/support/knowledgecenter/en/SSGSG7_7.1.0/com.ibm.it
sm.perf.doc/c_tcpip_optwindowsize.html
Tuning TCP/IP buffer sizes
https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.we
bsphere.nd.multiplatform.doc/ae/tprf_tunetcpip.html
Thank You
_____
Paul Steinmetz
IBM i Systems Administrator
Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071
610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home
psteinmetz@xxxxxxxxxx
http://www.pencor.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:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
