Subject: OT - Mac network diagnostics?

From: Lance Levsen <[email-masked]>
Date: Fri, 20 Jul 2001 15:44:19 -0600

Apologies for the off-topic, but one of our RB developers is 
having a b*tch of a time getting good performance on an internal 
application.

The scenario is:
100baseT network,
Linux PostgreSQL database
Mac RealBasic application connects to the database

Small queries happen fast, Large Macintosh LAN queries take 
forever, 6-13 seconds. W2K and an Ultra Sparc clients get 
returns of .08 seconds w/ the same query.

The strange thing is that the same query from a remote Mac 
client via Internet takes about 1.5 sec.

I've proved (four times now) that it isn't the network hardware, 
firewall or cabling that is causing the delay.

What I'd like to do is take the diagnostics to the next step . . 
. the iMac. Is there any tool for the Mac that sits in 
front/beside/or behind Open Transport that will allow me to 
track Ethernet packets on the Mac?

-- 
Support Intellectual Property.	|	Lance Levsen
Surrender yours to Microsoft.	|	Programmer
- Ed Craig			|	PWGroup - S'toon.

---

From: Tom Lane <[email-masked]>
Date: Fri, 20 Jul 2001 19:38:24 -0400

> client via Internet takes about 1.5 sec.

That makes it a networking problem, not a Postgres problem, so
it's a bit out of my depth.  However, I did just yesterday discover
a hack that helped me with a Linux networking problem: it seems the
Linux kernel has some weird retransmit behavior when there is a lot
of data pending in the send-queue.  Maybe you are being bit by the
same thing.  Try doing this on the Linux box:

	echo 0 > /proc/sys/net/ipv4/tcp_retrans_collapse

and see if things work any differently.  This parameter is documented
thus:

tcp_retrans_collapse - BOOLEAN
	Bug-to-bug compatibility with some broken printers.
	On retransmit try to send bigger packets to work around bugs in
	certain TCP stacks.

and I'm currently thinking that it creates more bugs than it fixes...
but it seems to be defaulted ON.

			regards, tom lane