From owner-freebsd-net@FreeBSD.ORG Tue Feb 14 21:41:36 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88F3E16A420 for ; Tue, 14 Feb 2006 21:41:36 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from lara.cc.fer.hr (lara.cc.fer.hr [161.53.72.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id C67AF43D6B for ; Tue, 14 Feb 2006 21:41:35 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [127.0.0.1] (localhost.cc.fer.hr [127.0.0.1]) by lara.cc.fer.hr (8.13.4/8.13.4) with ESMTP id k1ELfIea018786; Tue, 14 Feb 2006 22:41:19 +0100 (CET) (envelope-from ivoras@fer.hr) Message-ID: <43F24E7E.4060503@fer.hr> Date: Tue, 14 Feb 2006 22:41:18 +0100 From: Ivan Voras User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ragnar Lonn References: <43F0CE40.5040800@fer.hr> <43F1A2D1.7040402@packetfront.com> In-Reply-To: <43F1A2D1.7040402@packetfront.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: TCP Performance advice needed [long!] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 21:41:36 -0000 Ragnar Lonn wrote: > I don't know what tcp.inflight does but I know that this type of > application > protocol, that expects a reply before sending the next piece of data, will > always be completely dependent upon roundtrip times for its throughput - > the roundtrip time for the exchange "transmit-reply" will limit the > possible throughput you can get so if you want higher performance, either I understand this bottleneck, and know (at least in theory :) ) how it could be solved, but my problems are not directly related to that: - For small (but consistent in size) packet sizes, I get randomly varying round-trip times, and much lower packets-per-second ratio then with big packets (consistent in size) with the exact same lock-step protocol. Packet generation and processing are not CPU intensive. - When using big packets (actually, when switching back and forth from small packets to big packets), the PPS performance starts low and climbs to "normal" levels, and I'd like to avoid this. This is a local network with 0 errors. (if you like it, replace the word "packets" with "messages" in the above explanation :) ) I think the above problems are not directly related to the protocol (which could be better, I agree, but it won't happen at least until I understand what is happening with this version) but on fine-tuning of the network or socket options.