Date: Tue, 14 Feb 2006 22:41:18 +0100 From: Ivan Voras <ivoras@fer.hr> To: Ragnar Lonn <raglon@packetfront.com> Cc: net@freebsd.org Subject: Re: TCP Performance advice needed [long!] Message-ID: <43F24E7E.4060503@fer.hr> In-Reply-To: <43F1A2D1.7040402@packetfront.com> References: <43F0CE40.5040800@fer.hr> <43F1A2D1.7040402@packetfront.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43F24E7E.4060503>