NIO.2 and GC activity

[Leon Finker]

I have discovered that tcp tests on Vista (probably server 2008) are highly
dependent on the new tcp receive window auto-tuning feature. "netsh
interface tcp show global" will show you the current settings. If you type
"netsh interface tcp set global", you'll see the description for those
settings. I think the default in Vista is "highlyrestricted" (at least I had
it on two machines). This interfered with the data throughput tests. When
messages of size 2-4K were sent, exactly 5 seconds pauses would be
introduced where no IO activity is happening (this was circumvented by
setting the SNDBUF to 0) on Vista. 

Once the tcp auto-tuning setting was set to restricted or normal, no such
pauses were observed. Also, with restricted/normal setting no performance
gain or degradation was observed with multiple receives/sends and SND/RCV
buffer size of 256K or 0 sizes. There might be gains on other OS versions,
but I have no interest in pursuing this any farther. Especially since that
model will not map to Solaris/Linux in any case.


-----Original Message-----
From: nio-dev-bounces at openjdk.java.net
[mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Leon Finker
Sent: Wednesday, May 20, 2009 8:49 AM
To: Alan.Bateman at Sun.COM
Cc: nio-dev at openjdk.java.net
Subject: RE: NIO.2 and GC activity

SO_RCVBUF is default of 8192 in all cases. SO_SNDBUF I've set to 0 in all
cases because of the pausing issue on Vista and preventing me to do the
tests.

-----Original Message-----
From: Alan.Bateman at Sun.COM [mailto:Alan.Bateman at Sun.COM] 
Sent: Wednesday, May 20, 2009 3:23 AM
To: Leon Finker
Cc: nio-dev at openjdk.java.net
Subject: Re: NIO.2 and GC activity

Leon Finker wrote:
> FYI, I did some performance testing across two machines (Windows Vista
over
> Wi-Fi connection) with single outstanding read and multiple outstanding
> reads and writes on a socket. For single case I did this in Java NIO2 and
> .NET. The code between the two is basically identical. The performance is
> about the same. For multiple case I only did this in .NET since Java NIO2
> prevents me from doing this. I see ~25% increase in data throughput in
> multiple reads and writes case. And I did not even try to optimize the
code
> for re-sequencing multiple outstanding receives (just took a coarse
grained
> lock to protect shared state). This is with single client connection to a
> server. I don't know if there will be any gains in Java NIO2, but it would
> be nice to test it. If there is, then I would vote for removing the check
> for multiple outstanding reads.
>   
Do you know the size of send/receive buffer in both cases?

-Alan.