TCP parameters and interpreting tcpdump output

[Dieter]

I found a couple more things that don't look right.

000017 IP bsd.63743 > src.65001: . ack 52 win 65535
000107 IP bsd.63743 > src.65001: . ack 52 win 65535
000012 IP bsd.63743 > src.65001: F 52:52(0) ack 52 win 65535
000005 IP bsd.63743 > src.65001: F 52:52(0) ack 52 win 65535
000172 IP src.65001 > bsd.63743: . ack 53 win 4096
000004 IP src.65001 > bsd.63743: F 52:52(0) ack 53 win 4096
000003 IP src.65001 > bsd.63743: . ack 53 win 4096
000016 IP bsd.63743 > src.65001: . ack 52 win 65535
000011 IP bsd.63743 > src.65001: . ack 53 win 112	<------ why does the window suddenly shrink?
002366 IP src.rfe > bsd.12340: P 1:1317(1316) ack 1 win 4096
099554 IP bsd.12340 > src.rfe: . ack 1317 win 65535     <------ why does it take 99.5 millisec to ack?

The ack time is normally 12 or 13 microseconds, which seems to be okay.
But 99.5 milliseconds is *way* too slow, data will be lost.

Is TCP sitting around waiting for a second packet, so that
it can be "efficient" and ack two packets at once?

What can I do to fix this?  Is there a knob I can turn to say
"ack every packet", or "only wait xxx microseconds for a 2nd packet" ?

Data is generated in real-time, and the src box only has a small buffer.
The bsd box is more than fast enough overall, but I keep finding
cases where the latency to ack a packet is way too long. 
The process reading port 12340 has a very large circular buffer.
The process is running at rtprio 5.  Other processes are running
at normal default priority.  Machine is basically idle.

Suggestions on how to lower the worst case latency welcome.