Turning Off buffering by setting SO_RCVBUF, SO_SNDBUF to zero

[nova-nuker]

Can anyone please explain to me; Is there a real performance gain by switching off SO_RCVBUF and SO_SNDBUF?

Somebody in the forums mentioned that there is no absolute gain by switching off buffering, but many articles like (Windows Sockets 2.0: Write Scalable Winsock Apps Using Completion Ports by Anthony Jones and Amol Deshpande) do say that you gain performance. The only thing one has to take care is about the non-paged memory.

[ahoodin]

Well mostly on MS Platform, there will be no performance gain. TCP/IP works by sending large amounts of data fast. But actually the message count sent per second are rather low. On MS Platform if you want to do that sort of thing, I actaully suggest using UDP instead of TCP. It is capable of sending small messages rather quickly. Winsock TCP has a 200ms timeout built into each message via the Nagle Algorithm that will not be shut off no matter what...in other words you can send a max of 5 messages per second per socket. Alternatively you can try a different TCP Stack....

HTH,

[nova-nuker]

Thanx,
You mentioned "Alternatively you can try a different TCP Stack...."
How to do that? I've no idea.

[ahoodin]

HINT: A cursory search using "alternate TCP Stack Windows" returns the following in the first ten search items:

http://www.cyclone.com/products/software/zerocopy.php
http://learning.lib.vt.edu/wintcpip/trumpwsk.html

:wave:

[MikeAThon]

HINT: A cursory search using "alternate TCP Stack Windows" returns the following in the first ten search items:

http://www.cyclone.com/products/software/zerocopy.php
http://learning.lib.vt.edu/wintcpip/trumpwsk.html
Yikes!! The Trumpet Winsock stack has not been supported since 1995 and is most definitely a 1.0 stack that might not even be usable after Win95, due to the current security model for the Win OSs. And the Cyclone stack is usable only in embedded systems using the VxWorks real-time operating system, so it's not usable in Windos at all.

If you are trying to write programs for Windows, stick to the Winsock stack that comes with every distribution of Windows. Don't try to use an alternative stack. Your users will like the fact that they do not need to intall kernel-level stacks etc, that can often affect all other programs that need the stack.

Mike

[MikeAThon]

Can anyone please explain to me; Is there a real performance gain by switching off SO_RCVBUF and SO_SNDBUF?

Somebody in the forums mentioned that there is no absolute gain by switching off buffering, but many articles like (Windows Sockets 2.0: Write Scalable Winsock Apps Using Completion Ports by Anthony Jones and Amol Deshpande) do say that you gain performance. The only thing one has to take care is about the non-paged memory.
You will only see a performance gain if you are programming with I/O completion ports (IOCP), which automatically means that you can only get this gain in a Windows application (since Windows is the only OS that offers IOCP), and only if you program to the IOCP architecture (which is the most complicated of the prgramming architectures).

In addition, the article you cited basically says that you should never turn off send/recv buffering. According to the article, it's a "really bad idea": It should be clear by now that turning off buffering is a really bad idea for most applications.See http://msdn.microsoft.com/msdnmag/issues/1000/Winsock/ , around half-way down.

If you read other sources, you will see that you should never turn off receive buffering (SO_RCVBUF). There is, however, one tiny way that there might be a perfomance advantage by turning off send buffering (SO_SNDBUF), but you will only see this advantage if you commonly post many overlapped WSASends() without waiting for completion of a prior send. You are the only one in a position to know if you are ready to accept this level of complication, and if the slight performance advantage is worht the effort and added complexity.

Mike

[ahoodin]

OSR has a kernel level implementation of Sockets called KSOCKS.

I'm sorry but Winsock is just kind of hamstrung when it comes to performance and quirky when it comes to use.

Yikes!! The Trumpet Winsock stack has not been supported since 1995 and is most definitely a 1.0 stack that might not even be usable after Win95, due to the current security model for the Win OSs. And the Cyclone stack is usable only in embedded systems using the VxWorks real-time operating system, so it's not usable in Windos at all.

If you are trying to write programs for Windows, stick to the Winsock stack that comes with every distribution of Windows. Don't try to use an alternative stack. Your users will like the fact that they do not need to intall kernel-level stacks etc, that can often affect all other programs that need the stack.

Mike

[nova-nuker]

Thank you Mike,

Now its very clear. It took a while to digest that article.

Also I am using completion ports so I was looking for a way to squeeze my program for performance.

Thanx again. :-)

[ahoodin]

This is a bit closed minded. What is more, I do believe you actually don't know what your talking about here.
Don't try to use an alternative stack. Your users will like the fact that they do not need to intall kernel-level stacks etc, that can often affect all other programs that need the stack.

Mike

I do believe I was providing a hint here. So before you go off on some benal lecture, I think you should understand that I was trying to push the OP in a positive direction. To provide a HINT.

HINT: A cursory

Additionally cursory means that I understood the nature of the results of the search. Obviously english is something you gloss over without actual comprehension.

[MikeAThon]

This is a bit closed minded. What is more, I don't think you actually know what your talking about here.

***

Additionally cursory means that I understood the nature of the results of the search. Obviously english is something you gloss over without actual comprehension.
Relax. I was critical about your advice, but I was not critical about you. Let's not get off on ad hominem attacks. They serve no one.

I do believe I was providing a hint here. So before you go off on some benal lecture, I think you should understand that I was trying to push the OP in a positive direction. To provide a HINT.
Again, and as indicated in my post, I for one do not believe it was a positive direction. Your suggestion was to try an alternate TCP stack (i.e. other than the Winsock stack), and then you provided two examples that were completely inappropriate. First, I maintain my position that the basic premise of an alternate TCP stack is a bad idea. My reasons have been stated already, and mainly involve interference with the correct operation of all other programs on the end-user's machine, and inconvenience to an end-user particularly in view of current security models in the Windows OSs. As one related situation, how many times has your own machine become unworkable because some rougue program installed an LSP that didn't play well with other LSPs already installed.

Second, the two alternatives you suggested were completely unworkable for reasons already stated. I of course recognized that you made a search that was "cursory", in an effort to provide a "hint", but in plain english, I think that the search and the hint were not helpful.

You have stated that "Winsock is just kind of hamstrung when it comes to performance and quirky when it comes to use." You have also suggested that there might be alternatives to the Winsock stack. Together, these suggest that you yourself might have used alternatives to Winsock in the past. If so, tell us what it was. If not, then please help us all and find a good alternative now.

Please take the above as challenges, and do not take anything said here personally. You have been active on this board for a long time, and provide good, cogent help/advice all the time. Just because I tend to disagree with one of your suggestions should not detract from that.

Mike

[ahoodin]

I agree with Mick.

the Winsock stack), and then you provided two examples that were completely inappropriate. First, I maintain my position that the basic premise of an alternate TCP stack is a bad idea.

Well from your answers you don't have any information on the shortcomings of TCP/IP and how to remedy them either.


As one related situation, how many times has your own machine become unworkable because some rougue program installed an LSP that didn't play well with other LSPs already installed.

Obviously you don't do much real time programming, and obviously you dont know the meaning of the word cursory. Maybe if you focus more on the shortcomings of the standard Windows TCP stack and less on how worried you are about installing something that didn't ship on your Windows disk your closed mind will open.


You have stated that "Winsock is just kind of hamstrung when it comes to performance and quirky when it comes to use."

And I supported that statement with the performance stat I provided earlier.


You have also suggested that there might be alternatives to the Winsock stack. Together, these suggest that you yourself might have used alternatives to Winsock in the past. If so, tell us what it was. If not, then please help us all and find a good alternative now.


Its not some mystery.

Ardence has a good alternative.

The RT-TCP/IP stack interfaces directly to an RTX-enabled application through the kernel, resulting in no overhead and microsecond response between application and the stack.

http://www.ikon-gmbh.de/index.htm?../fr_inhalt/products/devtools/ardence_rtx/ardence_rtx_tcpip.htm
There are good alternatives out there....go and find them for yourself.

[MikeAThon]

Well, it's a pity that this post has devolved to this.
Well from your answers you don't have any information on the shortcomings of TCP/IP and how to remedy them either.
What shortcomings are your referring to? You didn't mention anything about them above.
Obviously you don't do much real time programming, and obviously you dont know the meaning of the word cursory. Maybe if you focus more on the shortcomings of the standard Windows TCP stack and less on how worried you are about installing something that didn't ship on your Windows disk your closed mind will open.
It's true that I don't do real-time programming any more. But that of course is entirely irrelevant, since the OP's question was concerned only with Winsock programming under an IOCP architecture. This is completely unrelated to real-time programming.

And again on the "shortcomings". What are the shortcomings you refer to?

And I supported that statement with the performance stat I provided earlier.
There are no performance stats in any of your posts. Please provide them.

Its not some mystery.

Ardence has a good alternative.

The RT-TCP/IP stack interfaces directly to an RTX-enabled application through the kernel, resulting in no overhead and microsecond response between application and the stack.

http://www.ikon-gmbh.de/index.htm?../fr_inhalt/products/devtools/ardence_rtx/ardence_rtx_tcpip.htm
There are good alternatives out there....go and find them for yourself.
Again, this is a completely inappropriate suggestion for a TCP stack for Windows. The Ardence stack you linked to is a TCP stack for embedded systems using a RTOS, which is not Windows.

Good luck!

Mike

[ahoodin]

Again, this is a completely inappropriate suggestion for a TCP stack for Windows. The Ardence stack you linked to is a TCP stack for embedded systems using a RTOS, which is not Windows.


No its not. Again and again you failed to read thoroughly....Mike apparently your closed mind is not evident to you.

Well, it's a pity that this post has devolved to this.
No in your special case it is about time, I think. You are not a very good reader. I think you are not humble in your attitudes, and nor do you think about every word you read. Maybe in your case every other sentence. I am sick of your responses as of late. They are thoughtless and abrupt.


What shortcomings are your referring to? You didn't mention anything about them above.

more proof that you gloss over your reading.


It's true that I don't do real-time programming any more. But that of course is entirely irrelevant,

The reasons that make the standard Windows TCP stack hard to tune to enchance its performance are the same reasons standard Windows TCP is not a very good real time communcations stack.


since the OP's question was concerned only with Winsock programming under an IOCP architecture. This is completely unrelated to real-time programming.

:rolleyes: glossing over.

And again on the "shortcomings". What are the shortcomings you refer to?

:rolleyes: glossing over.

There are no performance stats in any of your posts. Please provide them.

:rolleyes: glossing over.


Good luck!

Take it easy.

Mike

[nova-nuker]

Hey,

Both of you acting like kids. Please stop it. I wonder, you get time for all THIS.
Why don't cool off and take part in Intel's multithreading coding competition?