<?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: lan speed in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/lan-speed/m-p/3829628#M271673</link>
    <description>Steven - wrt the switch problem, I might suggest a shotgun rather than a workaround in the host :)&lt;BR /&gt;&lt;BR /&gt;More seriously, if Subhashni is having duplex problems, and wants to hardcode, please make very certain that it is an autoneg problem that cannot be resolved anyother way.&lt;BR /&gt;&lt;BR /&gt;Steven and others will have already seen this boilerplate:&lt;BR /&gt;&lt;BR /&gt;$ cat usenet_replies/duplex&lt;BR /&gt;How 100Base-T Autoneg is supposed to work:&lt;BR /&gt;&lt;BR /&gt;When both sides of the link are set to autoneg, they will "negotiate"&lt;BR /&gt;the duplex setting and select full-duplex if both sides can do&lt;BR /&gt;full-duplex.&lt;BR /&gt;&lt;BR /&gt;If one side is hardcoded and not using autoneg, the autoneg process&lt;BR /&gt;will "fail" and the side trying to autoneg is required by spec to use&lt;BR /&gt;half-duplex mode.&lt;BR /&gt;&lt;BR /&gt;If one side is using half-duplex, and the other is using full-duplex,&lt;BR /&gt;sorrow and woe is the usual result.&lt;BR /&gt;&lt;BR /&gt;So, the following table shows what will happen given various settings&lt;BR /&gt;on each side:&lt;BR /&gt;&lt;BR /&gt;                 Auto       Half       Full&lt;BR /&gt;&lt;BR /&gt;   Auto        Happiness   Lucky      Sorrow&lt;BR /&gt;&lt;BR /&gt;   Half        Lucky       Happiness  Sorrow&lt;BR /&gt;&lt;BR /&gt;   Full        Sorrow      Sorrow     Happiness&lt;BR /&gt;&lt;BR /&gt;Happiness means that there is a good shot of everything going well.&lt;BR /&gt;Lucky means that things will likely go well, but not because you did&lt;BR /&gt;anything correctly :) Sorrow means that there _will_ be a duplex&lt;BR /&gt;mis-match.&lt;BR /&gt;&lt;BR /&gt;When there is a duplex mismatch, on the side running half-duplex you&lt;BR /&gt;will see various errors and probably a number of _LATE_ collisions&lt;BR /&gt;("normal" collisions don't count here).  On the side running&lt;BR /&gt;full-duplex you will see things like FCS errors.  Note that those&lt;BR /&gt;errors are not necessarily conclusive, they are simply indicators.&lt;BR /&gt;&lt;BR /&gt;Further, it is important to keep in mind that a "clean" ping (or the&lt;BR /&gt;like - eg "linkloop" or default netperf TCP_RR) test result is&lt;BR /&gt;inconclusive here - a duplex mismatch causes lost traffic _only_ when&lt;BR /&gt;both sides of the link try to speak at the same time. A typical ping&lt;BR /&gt;test, being synchronous, one at a time request/response, never tries&lt;BR /&gt;to have both sides talking at the same time.&lt;BR /&gt;&lt;BR /&gt;Finally, when/if you migrate to 1000Base-T, everything has to be set&lt;BR /&gt;to auto-neg anyway.&lt;BR /&gt;</description>
    <pubDate>Mon, 24 Jul 2006 19:58:28 GMT</pubDate>
    <dc:creator>rick jones</dc:creator>
    <dc:date>2006-07-24T19:58:28Z</dc:date>
    <item>
      <title>lan speed</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/lan-speed/m-p/3829624#M271669</link>
      <description>Hi ..&lt;BR /&gt;Is there any other way to make lan settings permanent (settings survive after reboot) , instead of editing rc.config.d/driverspecific file.&lt;BR /&gt;thanks</description>
      <pubDate>Mon, 24 Jul 2006 16:29:29 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/lan-speed/m-p/3829624#M271669</guid>
      <dc:creator>subhashni</dc:creator>
      <dc:date>2006-07-24T16:29:29Z</dc:date>
    </item>
    <item>
      <title>Re: lan speed</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/lan-speed/m-p/3829625#M271670</link>
      <description>Hi:&lt;BR /&gt;&lt;BR /&gt;No, that's why there are configuration files...&lt;BR /&gt;&lt;BR /&gt;Regards!&lt;BR /&gt;&lt;BR /&gt;...JRF...</description>
      <pubDate>Mon, 24 Jul 2006 16:32:16 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/lan-speed/m-p/3829625#M271670</guid>
      <dc:creator>James R. Ferguson</dc:creator>
      <dc:date>2006-07-24T16:32:16Z</dc:date>
    </item>
    <item>
      <title>Re: lan speed</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/lan-speed/m-p/3829626#M271671</link>
      <description>&lt;BR /&gt;&lt;BR /&gt;You can use SAM - although it modifies the driver specific files for you.........&lt;BR /&gt;</description>
      <pubDate>Mon, 24 Jul 2006 16:44:04 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/lan-speed/m-p/3829626#M271671</guid>
      <dc:creator>DCE</dc:creator>
      <dc:date>2006-07-24T16:44:04Z</dc:date>
    </item>
    <item>
      <title>Re: lan speed</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/lan-speed/m-p/3829627#M271672</link>
      <description>Shalom,&lt;BR /&gt;&lt;BR /&gt;Changing the configuration files does make them permanent.&lt;BR /&gt;&lt;BR /&gt;I ran into a situation where a lan was not coming up 100 BaseT full duplex and had to hard code settings into /etc/rc.config.d/hpbtlanconf&lt;BR /&gt;&lt;BR /&gt;This was using configuraiton files to overcome an OS to Switch defect.&lt;BR /&gt;&lt;BR /&gt;SEP</description>
      <pubDate>Mon, 24 Jul 2006 18:21:43 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/lan-speed/m-p/3829627#M271672</guid>
      <dc:creator>Steven E. Protter</dc:creator>
      <dc:date>2006-07-24T18:21:43Z</dc:date>
    </item>
    <item>
      <title>Re: lan speed</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/lan-speed/m-p/3829628#M271673</link>
      <description>Steven - wrt the switch problem, I might suggest a shotgun rather than a workaround in the host :)&lt;BR /&gt;&lt;BR /&gt;More seriously, if Subhashni is having duplex problems, and wants to hardcode, please make very certain that it is an autoneg problem that cannot be resolved anyother way.&lt;BR /&gt;&lt;BR /&gt;Steven and others will have already seen this boilerplate:&lt;BR /&gt;&lt;BR /&gt;$ cat usenet_replies/duplex&lt;BR /&gt;How 100Base-T Autoneg is supposed to work:&lt;BR /&gt;&lt;BR /&gt;When both sides of the link are set to autoneg, they will "negotiate"&lt;BR /&gt;the duplex setting and select full-duplex if both sides can do&lt;BR /&gt;full-duplex.&lt;BR /&gt;&lt;BR /&gt;If one side is hardcoded and not using autoneg, the autoneg process&lt;BR /&gt;will "fail" and the side trying to autoneg is required by spec to use&lt;BR /&gt;half-duplex mode.&lt;BR /&gt;&lt;BR /&gt;If one side is using half-duplex, and the other is using full-duplex,&lt;BR /&gt;sorrow and woe is the usual result.&lt;BR /&gt;&lt;BR /&gt;So, the following table shows what will happen given various settings&lt;BR /&gt;on each side:&lt;BR /&gt;&lt;BR /&gt;                 Auto       Half       Full&lt;BR /&gt;&lt;BR /&gt;   Auto        Happiness   Lucky      Sorrow&lt;BR /&gt;&lt;BR /&gt;   Half        Lucky       Happiness  Sorrow&lt;BR /&gt;&lt;BR /&gt;   Full        Sorrow      Sorrow     Happiness&lt;BR /&gt;&lt;BR /&gt;Happiness means that there is a good shot of everything going well.&lt;BR /&gt;Lucky means that things will likely go well, but not because you did&lt;BR /&gt;anything correctly :) Sorrow means that there _will_ be a duplex&lt;BR /&gt;mis-match.&lt;BR /&gt;&lt;BR /&gt;When there is a duplex mismatch, on the side running half-duplex you&lt;BR /&gt;will see various errors and probably a number of _LATE_ collisions&lt;BR /&gt;("normal" collisions don't count here).  On the side running&lt;BR /&gt;full-duplex you will see things like FCS errors.  Note that those&lt;BR /&gt;errors are not necessarily conclusive, they are simply indicators.&lt;BR /&gt;&lt;BR /&gt;Further, it is important to keep in mind that a "clean" ping (or the&lt;BR /&gt;like - eg "linkloop" or default netperf TCP_RR) test result is&lt;BR /&gt;inconclusive here - a duplex mismatch causes lost traffic _only_ when&lt;BR /&gt;both sides of the link try to speak at the same time. A typical ping&lt;BR /&gt;test, being synchronous, one at a time request/response, never tries&lt;BR /&gt;to have both sides talking at the same time.&lt;BR /&gt;&lt;BR /&gt;Finally, when/if you migrate to 1000Base-T, everything has to be set&lt;BR /&gt;to auto-neg anyway.&lt;BR /&gt;</description>
      <pubDate>Mon, 24 Jul 2006 19:58:28 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/lan-speed/m-p/3829628#M271673</guid>
      <dc:creator>rick jones</dc:creator>
      <dc:date>2006-07-24T19:58:28Z</dc:date>
    </item>
  </channel>
</rss>

