Lack of network data although having a dual processor

[Andreas_aro]

Hi,

I have a program written in VC using a callback function which
includes a message loop ("WndProc") reacting to the windows messages (network data arrived at a socket connection, reading the socket using the windows API).

The program runs on a single processor machine , but I also have
a dual processor machine available.

The socket gets some data every 10 milliseconds (it works fine, although windows is no real-time operating system !!!).


The only problem is (for example) whenever opening another
program or maximizing a window, there's a lack of data at the
windows socket for a period of ca. 200 milliseconds which prevents the program from working correctly.



I tested the program using the dual processor machine,
distributing the program to the second processor, and (for
example) the windows explorer to the first processor by using
the task manager.

In addition to that, I set the priority of the program on the second
processor to "realtime".

But whenever I try to maximize /minimize the explorer, the
lack of data appears as I described above.

Thanks a lot in advance for some hints in order to solve the problem :-)))

[kuphryn]

What is the winsock I/O model?

Kuphryn

[Andreas Masur]

[Moved thread]

[simpleman]

Hi

I am simpleman

The socket gets some data every 10 milliseconds (it works fine, although windows is no real-time operating system !!!).

i think it will not work fine if the ping time is over 10 ms. from the server. cause TCP is using Nagle algorithm, if the Server side TCP layer didn't get ACK from your client, then the Server side TCP layer will not send the data and it will accumulte until the ack will reach.

and i think it is not good style to send/receive some data every 10ms.

The only problem is (for example) whenever opening another

i think it is because of the Context Switching by Windows kernel.
As far as i know normal thread's working time (including context switching time) is around 10 ms. in windows.
so when you start another application, windows kernel must give a chance to work for the application. it means your socket program can not work..

[Mathew Joy]

i think it will not work fine if the ping time is over 10 ms. from the server. cause TCP is using Nagle algorithm, if the Server side TCP layer didn't get ACK from your client, then the Server side TCP layer will not send the data and it will accumulte until the ack will reach.

and i think it is not good style to send/receive some data every 10ms.
Again what you 'think' is wrong! Nagle alg. doesn't work like that. It only comes into play when the segment size is small and will wait till there is no outstanding acks. When it is in a wait and more small segments arrive it coalesced into one larger segment and any large segment is transmitted immediately. Nagle challenged applications often performs poorly. Nagle alg is ment to increase the throughput. There is often never a case where you have to turn off the Nagle alg. It may be neccessary if you are operating in real time and you want each bytes to send immediately without delay. And for that windows is not a good operating system either.


i think it is because of the Context Switching by Windows kernel.
As far as i know normal thread's working time (including context switching time) is around 10 ms. in windows.
so when you start another application, windows kernel must give a chance to work for the application. it means your socket program can not work..

The threads working time depends on the no of threads that application is having. The more no of thread the less will be the time each gets. And I know it is far above 10ms.

The original poster problem is using inefficient IO model. He hasn't posted what IO model he is using. But using the one that uses windows messages to communicate is not good enough. Maybe if you could specify more about your problem and what sort of program you are doing, we may help. And also the load, and the no of connections.

There is no problem with send/recv every 10ms. The problem is how the server is handling. The IO model that gives the best performance is the IOCP. It scales well with mulitprocessor as well.

[Andreas_aro]

Originally posted by kuphryn
What is the winsock I/O model?

Kuphryn


Sorry for that inaccuracy !

I use UDP as transmission protocol, no TCP.
I know that this protocol will cause some lack of packages depending from the network.

This is no problem.

[Andreas_aro]

Originally posted by simpleman
Hi

I am simpleman



i think it will not work fine if the ping time is over 10 ms. from the server.

The ping time is under 10 ms.
Generally, the delay is not a problem.

The only problem I have is the reason I described above. It's also the reason I opened this thread.

cause TCP is using Nagle algorithm, if the Server side TCP layer didn't get ACK from your client, then the Server side TCP layer will not send the data and it will accumulte until the ack will reach.

and i think it is not good style to send/receive some data every 10ms.

You are right, absolutely !
But concerning to the aim I have, I must do that. I only can imagine to enlarge the period of data from 10 milliseconds
to 15 milliseconds, but that doesn't change anaything.
I was very delighted that Windows works as fast as I hoped and
that I could use this size of packages !

If the socket gets data only every 200 msec, I have no problem,
but I can't do that because of some other reasons.
That's the way it is !


i think it is because of the Context Switching by Windows kernel.
As far as i know normal thread's working time (including context switching time) is around 10 ms. in windows.
so when you start another application, windows kernel must give a chance to work for the application. it means your socket program can not work..

[Andreas_aro]

Originally posted by Mathew Joy
Again what you 'think' is wrong! Nagle alg. doesn't work like that. It only comes into play when the segment size is small and will wait till there is no outstanding acks. When it is in a wait and more small segments arrive it coalesced into one larger segment and any large segment is transmitted immediately. Nagle challenged applications often performs poorly. Nagle alg is ment to increase the throughput. There is often never a case where you have to turn off the Nagle alg. It may be neccessary if you are operating in real time and you want each bytes to send immediately without delay. And for that windows is not a good operating system either.

You are right. I know of course that windows is not a real time
operating system but it's the only thing I have at the moment.


The threads working time depends on the no of threads that application is having. The more no of thread the less will be the time each gets. And I know it is far above 10ms.

The original poster problem is using inefficient IO model. He hasn't posted what IO model he is using. But using the one that uses windows messages to communicate is not good enough. Maybe if you could specify more about your problem and what sort of program you are doing, we may help. And also the load, and the no of connections.


Thank you for your answer (and thanks to everybody in this thread !). As I described below, I used UDP as as transmission protocol.

There is no problem with send/recv every 10ms. The problem is how the server is handling. The IO model that gives the best performance is the IOCP. It scales well with mulitprocessor as well.

[dimm_coder]

Originally posted by Mathew Joy
There is no problem with send/recv every 10ms. The problem is how the server is handling. The IO model that gives the best performance is the IOCP. It scales well with mulitprocessor as well.

If the program's design relies on some real-time behavior (hard-real or even soft-real) and fails if deadline requirements are not met, the op probably should re-think the design. if the kernel is not preemptible (and windoze's kernel is not preemptible. Of course, some additional requirements for the kernel are needed, to consider the kernel as real-time), even 10 ms can be a problem, especially while handling it in user-mode.

2 op: In any case, as Mathew has pointed out, U should remove the use of windows messages and, probably , use the IOCP to achive the maximum performance.

[Mathew Joy]

Hi dimm,

Originally posted by Mathew Joy
There is no problem with send/recv every 10ms.
I was only contradicting what simpleman was he said "i think it is not good style to send/receive some data every 10ms". I didn't mean that you'll always get it on real time.:)