FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

On Sun, Feb 09, 2003 at 02:39:02PM -0500, James K. Lowden wrote:

> Here's a theory:

> 1.  For Gad's data, some kinds of TDS packets don't fit in FreeTDS's
> default packet size (512 bytes) but are less than 1024 bytes.  That leads
> to two roundtrips to the server, resulting in a severe throughput
> degradation.  Server or client, I don't know.  

> 2.  Packet fragmentation doesn't matter, especially on local Ethernets,
> because the underlying OS is good at reassembling fragmented packets. 
> (I'm not sure "fragmentation" is the right term, actually.  We don't have
> tcp packets arriving in separate ip chunks.  We have TDS packets arriving
> as contiguous, unfragmented, in order, tcp packets.  That's a very normal
> tcp duty, transparent to the underlying layers.)  

So we're talking about TDS packetizing, not IP packetizing?  That makes
more sense to me.  And you're right that at that point, there would not
be any tcp fragmentation unless the packets had to be sent across
another link with a lower MTU, and any fragmentation that did occur
would not be TDS's problem.

> Supporting data:

> 1.  Better performance with larger packets.
> 2.  Microsoft servers set packet size to 4096 for bcp.
> 3.  Delays in handling TDS packets lead to still further delays by the
> server.  

> I'm pretty sure Microsoft's documentation advises using 4- or 8- kilobyte
> TDS packets for most situations.  

In light of Gad's findings, is there any reason FreeTDS
couldn't/shouldn't use a default packet size larger than 512?

-- 
Steve Langasek
postmodern programmer

Attachment: pgpzs3I5xOWjS.pgp
Description: PGP signature