×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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/rzajymaximumethernetframesize.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.itsm.perf.doc/c_tcpip_optwindowsize.html
Tuning TCP/IP buffer sizes
https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.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/
midrange.com
