Nikos Ntarmos schrieb am 24.02.2010 16:37 (localtime):
On Fri, Feb 19, 2010 at 11:55:39AM +0200, Nikos Ntarmos wrote:
On Thu, Feb 18, 2010 at 10:41:28PM +0100, Harald Schmalzbauer wrote:
Kevin Oberman schrieb am 18.02.2010 20:23 (localtime):
...
window allows for many packets to be in flight
On Thu, Feb 25, 2010 at 10:03:01AM +0100, Harald Schmalzbauer wrote:
Since I could only capture bad IP length packets with checsum
offloading enabled on the em, I guess it does also IP checksum
offloading, not only TCP. I'll have to set up a port mirroring test
bed to get the line packets. I
Patrick Mahan schrieb am 18.02.2010 16:20 (localtime):
See inline...
...
Please clarify my TCP understanding.
If I have the window set to 65535 in the header and a MSS of 1460, how
often should the receiver send ACK segments? window/MSS, right?
How soon you see the ACK is based on two
Harald Schmalzbauer wrote:
Some experimental results:
When rsyncing with windows, and FreeBSD is receiver, I see the same
ACK ever two segemnts, but speed is at 72MB/s.
When FreeBSD is sender and Windows is receiver, it looks more I
expected. There are about 20 data segments before a ACK is
Stephen Hurd schrieb am 18.02.2010 17:09 (localtime):
...
A TCP SHOULD implement a delayed ACK, but an ACK should not be
excessively delayed; in particular, the delay MUST be less than 0.5
seconds, and in a stream of full-sized segments there SHOULD be an ACK
for at least every second segment.
On Thu, Feb 18, 2010 at 10:24 AM, Harald Schmalzbauer
h.schmalzba...@omnilan.de wrote:
The problem is not with the windows box, these transfer rates are sensible.
The problem is with two RELENG_8 machines.
I'm doing this whole thing because I observed slowdowns under 20MB/s and I
try to
Adam Vande More schrieb am 18.02.2010 17:28 (localtime):
On Thu, Feb 18, 2010 at 10:24 AM, Harald Schmalzbauer
h.schmalzba...@omnilan.de mailto:h.schmalzba...@omnilan.de wrote:
The problem is not with the windows box, these transfer rates are
sensible. The problem is with two RELENG_8
On Thu, Feb 18, 2010 at 05:52:37PM +0100, Harald Schmalzbauer wrote:
Stephen Hurd schrieb am 18.02.2010 17:18 (localtime):
...
one retransmit per five packets). Is this what you're seeing? If
you have a capture you could share covering a few seconds, I could
take a look and provide a better
All those duplicate ACKs look like a problme to me... I would be inclined to
capture from the other end or from a monitor port on the switch to make sure
those are actually hitting the wire. The only explination I can think of is
that the system sending the duplicate ACKs is assuming that it's
Date: Thu, 18 Feb 2010 17:24:05 +0100
From: Harald Schmalzbauer h.schmalzba...@omnilan.de
Sender: owner-freebsd-sta...@freebsd.org
Stephen Hurd schrieb am 18.02.2010 17:09 (localtime):
...
A TCP SHOULD implement a delayed ACK, but an ACK should not be
excessively delayed; in
Kevin Oberman schrieb am 18.02.2010 20:23 (localtime):
...
window allows for many packets to be in flight and with a 3 Gbps flow,
that is a LOT of data. While an ACK is sent every two packets of
received data, the transmitting side does not wait for the ACKs. It
...
That is a VERY simple and
11 matches
Mail list logo
