<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Delay in response after VLAN migration in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/delay-in-response-after-vlan-migration/m-p/5049963#M54799</link>
    <description>If possible, I'd push for a full duplex connection.&lt;BR /&gt;&lt;BR /&gt;That said, the VPN tunnel may introduce addtional overhead and split packets comming from the Alpha.  See &lt;BR /&gt;&lt;BR /&gt;UCX&amp;gt; help set protocol/mtu&lt;BR /&gt;&lt;BR /&gt;The VPN documenation should have a recommended maximum MTU.  &lt;BR /&gt;&lt;BR /&gt;Another option is to upgrade UCX to TCPIP.  You should be able to run 5.0a, possibly 5.1.  TCPIP provides better performance for IP traffic.  &lt;BR /&gt;&lt;BR /&gt;Andy</description>
    <pubDate>Wed, 30 May 2007 12:29:31 GMT</pubDate>
    <dc:creator>Andy Bustamante</dc:creator>
    <dc:date>2007-05-30T12:29:31Z</dc:date>
    <item>
      <title>Delay in response after VLAN migration</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/delay-in-response-after-vlan-migration/m-p/5049962#M54798</link>
      <description>Customer recently migrated from WAN to VLAN.  Because of a security issue they, also, introduced a "tunnel".  Their shop runs a shop floor application from PC's, where the application and files are on an Alpha and the database (Oracle) is on a Sun server.  The Alpha is a 4100 running OpenVMS 7.1-1H2, UCX V4.2 ECO 5 and has an EW_DE500 ethernet card with line speed 100 and full duplex off.  They are now experiencing delays and are asking about MTU (maximum transfer Unit?) detection and discovery and possibly turning it off.  The user has Unix and Windows experience.&lt;BR /&gt;&lt;BR /&gt;I'm not familiar with MTU.  Is there such a thing in this ethernet/ucx environment?  Is there a counter that might reflect their "delay" problem.  There are no waits or drops in "ucx show comm /mem" and nothing jumps out at me in "anal/sys show lan/dev=ewa".  They are not running DECNET. &lt;BR /&gt;&lt;BR /&gt;Thanks in advance for any/all responses.</description>
      <pubDate>Wed, 30 May 2007 11:36:28 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/delay-in-response-after-vlan-migration/m-p/5049962#M54798</guid>
      <dc:creator>Russ Carraro</dc:creator>
      <dc:date>2007-05-30T11:36:28Z</dc:date>
    </item>
    <item>
      <title>Re: Delay in response after VLAN migration</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/delay-in-response-after-vlan-migration/m-p/5049963#M54799</link>
      <description>If possible, I'd push for a full duplex connection.&lt;BR /&gt;&lt;BR /&gt;That said, the VPN tunnel may introduce addtional overhead and split packets comming from the Alpha.  See &lt;BR /&gt;&lt;BR /&gt;UCX&amp;gt; help set protocol/mtu&lt;BR /&gt;&lt;BR /&gt;The VPN documenation should have a recommended maximum MTU.  &lt;BR /&gt;&lt;BR /&gt;Another option is to upgrade UCX to TCPIP.  You should be able to run 5.0a, possibly 5.1.  TCPIP provides better performance for IP traffic.  &lt;BR /&gt;&lt;BR /&gt;Andy</description>
      <pubDate>Wed, 30 May 2007 12:29:31 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/delay-in-response-after-vlan-migration/m-p/5049963#M54799</guid>
      <dc:creator>Andy Bustamante</dc:creator>
      <dc:date>2007-05-30T12:29:31Z</dc:date>
    </item>
    <item>
      <title>Re: Delay in response after VLAN migration</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/delay-in-response-after-vlan-migration/m-p/5049964#M54800</link>
      <description>My understanding is that with some (all) VLAN implementations, as packets are routed through the virtual pipe, they are encapsulated in an outer package that contributes numerous bytes to their size. IP implementations recongnize hardware configurations and by default try to be efficient and create packets that are already at the maximum size supported by the hardware. So, once the size is exceeded (with the addition of the VLAN's overhead) the packets have to be fragmented in order to transfer - and then re-assembled on the other end. I'm not a UCX user so I can't tell you how to (I'm sure someone else reading here can) alter the MTU (yes, the maximum transfer unit which for ethernet is ~1500 bytes) but, I can tell that using MultiNet in similar situations I've had success lowering the MTU from 1500 to 1300 to curb the need for packet fragmentation and re-assembly.</description>
      <pubDate>Wed, 30 May 2007 12:30:50 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/delay-in-response-after-vlan-migration/m-p/5049964#M54800</guid>
      <dc:creator>Jim_McKinney</dc:creator>
      <dc:date>2007-05-30T12:30:50Z</dc:date>
    </item>
    <item>
      <title>Re: Delay in response after VLAN migration</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/delay-in-response-after-vlan-migration/m-p/5049965#M54801</link>
      <description>Needed the MTU option, thanks.</description>
      <pubDate>Wed, 30 May 2007 14:07:04 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/delay-in-response-after-vlan-migration/m-p/5049965#M54801</guid>
      <dc:creator>Russ Carraro</dc:creator>
      <dc:date>2007-05-30T14:07:04Z</dc:date>
    </item>
  </channel>
</rss>

