<?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: large average round-trip in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/large-average-round-trip/m-p/3712205#M549686</link>
    <description>The first step is to verify the specs on the 1 Mb network line. Does the supplier provide any reliability and performance specs? Is this a shared line (like a cable modem?). You can't really change anything in HP-UX to improve these delays if they are indeed occuring in the communications link. The packet loss seems to indicate that the network link is unreliable.</description>
    <pubDate>Thu, 19 Jan 2006 17:03:03 GMT</pubDate>
    <dc:creator>Bill Hassell</dc:creator>
    <dc:date>2006-01-19T17:03:03Z</dc:date>
    <item>
      <title>large average round-trip</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/large-average-round-trip/m-p/3712201#M549682</link>
      <description>Hi all,&lt;BR /&gt;&lt;BR /&gt;I want some on advise on network performance.&lt;BR /&gt;I have two servers, about 700 miles away from each other, connected with a 1 Mb line.&lt;BR /&gt;Tens of users are using the line for all kind of client/server applications.&lt;BR /&gt;&lt;BR /&gt;Very regurarly and for several minutes, I see large average round-trip times between 500 and 1000 msec's.&lt;BR /&gt;&lt;BR /&gt;Can someone tell me what acceptable round-trip times are ?&lt;BR /&gt;From what round-trip time, are users experiencing a 'slowness' in response times ?&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;Franky</description>
      <pubDate>Wed, 18 Jan 2006 10:21:22 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/large-average-round-trip/m-p/3712201#M549682</guid>
      <dc:creator>Franky Leeuwerck_2</dc:creator>
      <dc:date>2006-01-18T10:21:22Z</dc:date>
    </item>
    <item>
      <title>Re: large average round-trip</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/large-average-round-trip/m-p/3712202#M549683</link>
      <description>Q: How long is a piece of string?&lt;BR /&gt;A: It depends.&lt;BR /&gt;&lt;BR /&gt;Same thing here.  An acceptable round-trip time depends entirely on the applications and their users.  FTP transfers probably don't care so much about RTT unless they don't have a large enough TCP window.  Someone sitting in an editor typing might indeed care about a 1 second RTT.  If they are just sitting in a forms application that normally has a multi-second response time they may not care.&lt;BR /&gt;&lt;BR /&gt;I suspect that when you have the long RTT's you have high utilization on the link and deep queues at one end or the other of it.</description>
      <pubDate>Wed, 18 Jan 2006 20:52:38 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/large-average-round-trip/m-p/3712202#M549683</guid>
      <dc:creator>rick jones</dc:creator>
      <dc:date>2006-01-18T20:52:38Z</dc:date>
    </item>
    <item>
      <title>Re: large average round-trip</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/large-average-round-trip/m-p/3712203#M549684</link>
      <description>Thanks Rik.&lt;BR /&gt;&lt;BR /&gt;Also now and then, but it is occuring less frequently and for shorter intervals, we also see some packet loss (10% .&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Franky</description>
      <pubDate>Thu, 19 Jan 2006 03:10:56 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/large-average-round-trip/m-p/3712203#M549684</guid>
      <dc:creator>Franky Leeuwerck_2</dc:creator>
      <dc:date>2006-01-19T03:10:56Z</dc:date>
    </item>
    <item>
      <title>Re: large average round-trip</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/large-average-round-trip/m-p/3712204#M549685</link>
      <description>10% is not just "some" packet loss.  For protocols such as TCP that is _huge_. &lt;BR /&gt;&lt;BR /&gt;Consider the case when you have a synchronous request/response application, and the normal RTT is say 50 milliseconds. Often as not, the minimum TCP retransmission timeout is 500 milliseconds.  If we assume that 10% of the packets on the network are lost and that the request and the response are each a single TCP segment, then for the transaction to have no RTT delay it means that both the request and the response have to have made it through without a retransmission.  That means a probability of 0.9*0.9  or 0.81.  This means that 0.19 or 19% of the transactions will have at least 500 milliseconds added which yields an average latency of:&lt;BR /&gt;&lt;BR /&gt;0.81*50 + 0.19 * 500&lt;BR /&gt;   40.5 + 95&lt;BR /&gt;   135.5&lt;BR /&gt;&lt;BR /&gt;that 10% packet loss on the network is tripling the average response time in that example.  If the non-loss RTT were 100 ms then it would be nearly doubling it etc etc...&lt;BR /&gt;&lt;BR /&gt;In short (finally :)  a 10% loss rate on a link is doubleplusungood.</description>
      <pubDate>Thu, 19 Jan 2006 13:01:10 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/large-average-round-trip/m-p/3712204#M549685</guid>
      <dc:creator>rick jones</dc:creator>
      <dc:date>2006-01-19T13:01:10Z</dc:date>
    </item>
    <item>
      <title>Re: large average round-trip</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/large-average-round-trip/m-p/3712205#M549686</link>
      <description>The first step is to verify the specs on the 1 Mb network line. Does the supplier provide any reliability and performance specs? Is this a shared line (like a cable modem?). You can't really change anything in HP-UX to improve these delays if they are indeed occuring in the communications link. The packet loss seems to indicate that the network link is unreliable.</description>
      <pubDate>Thu, 19 Jan 2006 17:03:03 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/large-average-round-trip/m-p/3712205#M549686</guid>
      <dc:creator>Bill Hassell</dc:creator>
      <dc:date>2006-01-19T17:03:03Z</dc:date>
    </item>
    <item>
      <title>Re: large average round-trip</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/large-average-round-trip/m-p/3712206#M549687</link>
      <description>Unreliable, or perhaps overloaded.  &lt;BR /&gt;&lt;BR /&gt;TCP (I'm ass-u-me-ing TCP is the dominant protocol) congestion control is one thing, but with enough "mice" (eg short connections or connections where the exchanges are small numbers of segments) there is only so much it can do.&lt;BR /&gt;&lt;BR /&gt;Also, and off the wall question - there is no chance that this link to go 700 miles doesn't sometimes get routed through a satelite?&lt;BR /&gt;</description>
      <pubDate>Thu, 19 Jan 2006 17:06:12 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/large-average-round-trip/m-p/3712206#M549687</guid>
      <dc:creator>rick jones</dc:creator>
      <dc:date>2006-01-19T17:06:12Z</dc:date>
    </item>
    <item>
      <title>Re: large average round-trip</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/large-average-round-trip/m-p/3712207#M549688</link>
      <description>Thanks for your inputs.&lt;BR /&gt;&lt;BR /&gt;The line was surely unreliable and I've contacted the supplier. Have no idea about the specs: I am a 3th party that wants to make sure that the apps respond fast enough.&lt;BR /&gt;&lt;BR /&gt;Satelitte connection ? Could be .&lt;BR /&gt;&lt;BR /&gt;Best regards,&lt;BR /&gt;Franky&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Fri, 20 Jan 2006 03:30:08 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/large-average-round-trip/m-p/3712207#M549688</guid>
      <dc:creator>Franky Leeuwerck_2</dc:creator>
      <dc:date>2006-01-20T03:30:08Z</dc:date>
    </item>
  </channel>
</rss>

