RFR(s): Improving performance of Windows socket connect on the loopback adapter

[Nikola Grcevski]

Hi Alan,

> What cheap is VerifyVersionInfoW? The check is done everytime but the overhead might be in the noise. Overall it looks good to me.

I wrote a small benchmark to measure the overhead of the version check (attached below).

On my SurfaceBook 2 running Windows 10 Build 19041, the version check measures about ~2.2us (micro seconds) on average, when the 
version matches. 

Elapsed time 2244us. (for 1,000 iterations)

On a Windows 2016 Data Center Server the version check is much smaller ~0.13us (micro seconds) on average, when the version doesn't
match. 

Elapsed time 128us. (for 1,000 iterations)

I think the overhead is reasonably small compared to everything else. Please let me know if it's acceptable and if we can proceed. 

Thanks,
Nikola

Benchmark program:

int main()
{
	LARGE_INTEGER		start_time, end_time, elapsed_us;
	LARGE_INTEGER		frequency;

	QueryPerformanceFrequency(&frequency);
	QueryPerformanceCounter(&start_time);

	int count = 0;
	for (int i = 0; i < 1000; i++) {
		count += IsWindows10RS3OrGreater();
	}

	QueryPerformanceCounter(&end_time);
	elapsed_us.QuadPart = end_time.QuadPart - start_time.QuadPart;

	elapsed_us.QuadPart *= 1000000;
	elapsed_us.QuadPart /= frequency.QuadPart;

	printf("Elapsed time %lldus.\n", elapsed_us.QuadPart);
}

-----Original Message-----
From: Alan Bateman <Alan.Bateman at oracle.com> 
Sent: July 31, 2020 1:29 PM
To: Nikola Grcevski <Nikola.Grcevski at microsoft.com>; net-dev at openjdk.java.net
Subject: Re: RFR(s): Improving performance of Windows socket connect on the loopback adapter



On 28/07/2020 15:03, Nikola Grcevski wrote:
> Hi Alan,
>
> Thanks again for testing this change. I dug deep into the issue yesterday and got some answers from the Windows Networking team.
>
> The issue is that the flag TCP_INITIAL_RTO_NO_SYN_RETRANSMISSIONS, which we passed in to completely eliminate the network delay, isn't defined (or checked) on Windows 10 versions prior to RS3 (Redstone 3). The flag was interpreted as TCP_INITIAL_RTO_DEFAULT_MAX_SYN_RETRANSMISSIONS, causing a retry of 255 times, each one taking 500ms. This made each individual connect delay take 128 seconds in total.
>
> I was advised to change the code to perform a runtime check on the exact Windows version and unless it's Windows 10RS3 or later, we should set the retransmissions to 1. Strangely enough, we can't set it to 0, which is a special value interpreted as use the default. With retransmission count of 1, we speed up the localhost connects on older versions of Windows by factor of 2.
>
> I have prepared a new webrev with the runtime check for review here:
> http://cr.openjdk.java.net/~adityam/nikola/fast_connect_loopback_4/
>
> For the Windows version check function I followed the naming standards the SDK uses in:
> https://docs.microsoft.com/en-us/windows/win32/api/versionhelpers/
>
> If it's not a suitable function name please let me know. They have added this helper function for .NET 4.8 but it's not there yet for Win32. Hopefully, it comes provided by Microsoft in a future SDK update and we can remove the helper. I attempted to use IsWindowsVersionOrGreater, but unfortunately that API doesn't allow me to specify the build number to detect RS3.
>
What cheap is VerifyVersionInfoW? The check is done everytime but the overhead might be in the noise. Overall it looks good to me.

-Alan