Received: from maia.hub.org (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id 60BEF63328B
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Thu,  7 Jan 2010 16:13:23 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia,
	port 10024) with ESMTP id 60379-07
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Thu,  7 Jan 2010 20:13:12 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com
	[209.85.219.226])
	by mail.postgresql.org (Postfix) with ESMTP id 6E254632B9F
	for <pgsql-performance@postgresql.org>;
	Thu,  7 Jan 2010 16:13:12 -0400 (AST)
Received: by ewy26 with SMTP id 26so17054915ewy.3
	for <pgsql-performance@postgresql.org>;
	Thu, 07 Jan 2010 12:13:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:mime-version:received:in-reply-to:references
	:date:message-id:subject:from:to:cc:content-type;
	bh=2O2duNqlqpwUzhyXPDRTvYt7GOl6LRp1zBfCeU9t9m0=;
	b=HQWp5huzz1LLp80s/5JWX7eSg4eh8FTahyLhqg0wnUTgM4d3oGN4K/uuZnxxFBFciB
	KNcNibU6nsdVdsDRnenDJU++y6B9U0NwVKrP+CJ6ZnEL746olCGY9C5Hd2clhrO9KgGP
	hFm8q7BF6JMBso+hEAvLWmW0PfHPtN+tgGUHI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	b=Co2uBZs5HK3Vzbq5wtt2sVbyql+Mt7/MG7oCbxuW9YqwNcmHHSR3vUYJd0mdopr+Nl
	y5Pvp3SF8k+0gJKzmEfrUNNJeSEQ40pjwyA/vUq+5XGcV+rgTzYl0TtKAVSlilTK0HV/
	kB3USQ39DFPOsUma7aTasg8Ju70pa66OyfArg=
MIME-Version: 1.0
Received: by 10.216.87.14 with SMTP id x14mr2749809wee.127.1262895188753;
 Thu,
	07 Jan 2010 12:13:08 -0800 (PST)
In-Reply-To: <4B458FD0.8020205@postnewspapers.com.au>
References: <daed64561001041812s602a3098l686f630d6448835f@mail.gmail.com>
	<daed64561001061844q528adafeke89b78adb868b15a@mail.gmail.com>
	<4B458FD0.8020205@postnewspapers.com.au>
Date: Thu, 7 Jan 2010 14:13:08 -0600
Message-ID: <ca24673e1001071213y57e6fd73q757bffd98ef39baa@mail.gmail.com>
Subject: Re: pg_connect takes 3.0 seconds
From: Dave Crooke <dcrooke@gmail.com>
To: Craig Ringer <craig@postnewspapers.com.au>
Cc: Dmitri Girski <mitek17@gmail.com>, pgsql-performance@postgresql.org
Content-Type: multipart/alternative; boundary=0016e6d7dff81d4399047c98b384
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.59 tagged_above=-10 required=5
	tests=BAYES_00=-2.599, FH_DATE_PAST_20XX=3.188, HTML_MESSAGE=0.001
X-Spam-Level: 
X-Archive-Number: 201001/119
X-Sequence-Number: 36999

--0016e6d7dff81d4399047c98b384
Content-Type: text/plain; charset=ISO-8859-1

Oops, I meant to mention this too .... virtually all GigE and/or server
class NICs do TCP checksum offload.

Dimitri - it's unlikely that you have a hardware issue on the NIC, it's more
likely to be a cable problem or network congestion. What you want to look
for in the tcpdump capture is things like SYN retries.

A good way to test for cable issues is to use a ping flood with a large
packet size.

Cheers
Dave

Hang on a sec. You need to ignore bad checksums on *outbound* packets,
> because many (most?) Ethernet drivers implement some level of TCP
> offloading, and this will result in packet sniffers seeing invalid checksums
> for transmitted packets - the checksums haven't been generated by the NIC
> yet.
>
> Unless you know for sure that your NIC doesn't do TSO, ignore bad checksums
> on outbound packets from the local interface.
>
> --
> Craig Ringer
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

--0016e6d7dff81d4399047c98b384
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Oops, I meant to mention this too .... virtually all GigE and/or server cla=
ss NICs do TCP checksum offload.<br><br>Dimitri - it&#39;s unlikely that yo=
u have a hardware issue on the NIC, it&#39;s more likely to be a cable prob=
lem or network congestion. What you want to look for in the tcpdump capture=
 is things like SYN retries.<br>
<br>A good way to test for cable issues is to use a ping flood with a large=
 packet size.<br><br>Cheers<br>Dave<br><br><div class=3D"gmail_quote"><bloc=
kquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, =
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hang on a sec. You need to ignore bad checksums on *outbound* packets, beca=
use many (most?) Ethernet drivers implement some level of TCP offloading, a=
nd this will result in packet sniffers seeing invalid checksums for transmi=
tted packets - the checksums haven&#39;t been generated by the NIC yet.<br>

<br>
Unless you know for sure that your NIC doesn&#39;t do TSO, ignore bad check=
sums on outbound packets from the local interface.<br>
<br>
--<br><font color=3D"#888888">
Craig Ringer</font><div><div></div><div class=3D"h5"><br>
<br>
-- <br>
Sent via pgsql-performance mailing list (<a href=3D"mailto:pgsql-performanc=
e@postgresql.org" target=3D"_blank">pgsql-performance@postgresql.org</a>)<b=
r>
To make changes to your subscription:<br>
<a href=3D"http://www.postgresql.org/mailpref/pgsql-performance" target=3D"=
_blank">http://www.postgresql.org/mailpref/pgsql-performance</a><br>
</div></div></blockquote></div><br>

--0016e6d7dff81d4399047c98b384--