Re: ICMP benchmark?

Dan Stromberg <strombrg@xxxxxxxxxxxxxxx> wrote:
> On Tue, 22 Nov 2005 18:38:11 +0000, Rick Jones wrote:
>> In comp.benchmarks Dan Stromberg <strombrg@xxxxxxxxxxxxxxx> wrote:
>>> We (at UCI) have a gigabit network we need to troubleshoot. It
>>> seems to be underperforming quite a lot - like it's performing about
>>> 1/10th of what it should.
>>
>> Have you looked in your local stats for the usual suspects of packet
>> loss and the like?

> We have good stats on the two endpoints, and on one of the routers, but
> not all of the routers. The things we've checked don't appear to be
> losing packets, and mtr thinks we aren't losing packets, endpoint to
> endpoint.

If your stats on the endpoints show _NO_ drops or retransmissions,
(zero, not simply seemingly low) then from _that_ aspect at least the
stats in the middle are a don't care. No drops/retrans recored on the
ends means no drops in the middle (well, as I type that I suppose a
retransmitting link-level.... sigh)

>> Compared TCP window sizes (min of receive, cwnd and send) to the RTT?

> I'm not familiar with these three attributes of a TCP window size.
> Do you perhaps have a moment to characterize them?

There are basically three "windows" for a TCP connection these days
(at least that I can think of :). First is the classic receive window
- the one that is carried in the window field of the TCP header.

The second is the congestion window (aka cwnd) - this is basically a
figment of the sender's imagination (as it were :) in that it does not
appear in a header field - it is the sender's best guesstimate of how
much data she can dump onto the network without triggering
congestion-induced packet loss.

The third is what I call the send window but that name isn't all that
good. TCP has to retain a reference to all data it sends, until the
ACK arrives. There are limits to how much TCP can track, often it is
based on what is set via the SO_SNDBUF size. This is why the sending
TCP has to set SO_SNDBUF size in addition to the receiving TCP setting
SO_RCVBUF size...

TCP will (should) never have more data outstanding at any one time
than the minimum of those three "window" sizes.

> Anyway, we've been jacking our TCP window sizes as large as they'll
> go, which has been about 1.2 megabytes so far. We've also looked at
> our RTT.

And what is your RTT? In particular, what happens when you plug that
and your assumed window size into the equation below?

> Do you have a moment to describe the relationship between the TCP
> window size and the RTT?

Throughput <= Window/RTT

rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
.

Relevant Pages

  • Re: TCP congestion avoidance
    ... TCP BANDWIDTH DELAY PRODUCT WINDOW LIMITING ... due to the fairly small default buffers made available for a connection ... point where the RTT stops increasing, indicating that you have filled the ...
    (freebsd-questions)
  • Re: Interesting TCP issue
    ... }} Subject: Re: Interesting TCP issue ... }}> idiotically small window the remote server is advertising. ... }} turn off window scaling and see if that helps ...
    (freebsd-hackers)
  • RE: RWIN (TCP Window Size) negotiates properly after upgrading to SP2
    ... Apparently SP2 uses a different registry setting than SP1: ... TCP window size. ... There are 3-4 places in the Windows Registry that affect the TCP Window. ...
    (microsoft.public.windowsxp.network_web)
  • Re: large tcp window
    ... Additionally about TCP window size (TcpWindowSize registry key) on XP (at ... > on the first glance Nagle have to decrease performance but with TCP ...
    (microsoft.public.win32.programmer.networks)
  • Re: 2.6.17.1: fails to fully get webpage
    ... the RFC standard window scaling field of the TCP headers. ... I have customers and they have customers. ...
    (Linux-Kernel)