Winsock select timeout

Hi,

i'm communicating with more than 40 serial devices connected thru' an
serial hub. the pc has to communicate thru' UDP to the serial hub.

since the response is quite sensitve, ( the application has to timeout
within 100msec) we are using "select" call with timeout.

There are around 100 threads that are parallely polling all the 40
devices on the serial hub.

I noticed that the select call is timingout i.e. returning 0
eventhough there is socket in the buffer..does this mean that the
timer got expired when that thread is in the sleep state (i.e. some
other thread is running) and later when the thread resumes, it is just
returning the previous state...

I'm running this application on a 2.66G Pentium PC..will the context
switching be an issue at all here. i dont see this problem if the
number of threads is reduced...,meaning less context switching.

thanks

Scott
Wed Oct 17 07:40:49 PDT 2007

<vanisathish@gmail.com> wrote in message
news:1192630618.951354.298320@e34g2000pro.googlegroups.com...
> Hi,
>
> i'm communicating with more than 40 serial devices connected thru' an
> serial hub. the pc has to communicate thru' UDP to the serial hub.
>
> since the response is quite sensitve, ( the application has to timeout
> within 100msec) we are using "select" call with timeout.
>
> There are around 100 threads that are parallely polling all the 40
> devices on the serial hub.
>
> I noticed that the select call is timingout i.e. returning 0
> eventhough there is socket in the buffer..does this mean that the
> timer got expired when that thread is in the sleep state (i.e. some
> other thread is running) and later when the thread resumes, it is just
> returning the previous state...
>
> I'm running this application on a 2.66G Pentium PC..will the context
> switching be an issue at all here. i dont see this problem if the
> number of threads is reduced...,meaning less context switching.
>
> thanks
>

It is hard to be sure without understanding more about your program, but the
thread switching period is probably 20 milliseconds. So if you have 100
threads it could be as long as 2000 msec before each one gets a turn. So of
course a 100 msec timeout seems likely to fail. The fact that the problem
seems to go away with fewer threads supports this theory. This sounds like
a serious design scalability problem.

Since all the UDP messages come from the same place they must be sequential,
and you could consider a design that uses only one thread to process all UDP
input.

--
Scott McPhillips [VC++ MVP]

vanisathish
Wed Oct 17 08:33:34 PDT 2007

On Oct 17, 10:40 pm, "Scott McPhillips [MVP]" <org-dot-mvps-at-
scottmcp> wrote:
> <vanisath...@gmail.com> wrote in message
>
> news:1192630618.951354.298320@e34g2000pro.googlegroups.com...
>
>
>
>
>
> > Hi,
>
> > i'm communicating with more than 40 serial devices connected thru' an
> > serial hub. the pc has to communicate thru' UDP to the serial hub.
>
> > since the response is quite sensitve, ( the application has to timeout
> > within 100msec) we are using "select" call with timeout.
>
> > There are around 100 threads that are parallely polling all the 40
> > devices on the serial hub.
>
> > I noticed that the select call is timingout i.e. returning 0
> > eventhough there is socket in the buffer..does this mean that the
> > timer got expired when that thread is in the sleep state (i.e. some
> > other thread is running) and later when the thread resumes, it is just
> > returning the previous state...
>
> > I'm running this application on a 2.66G Pentium PC..will the context
> > switching be an issue at all here. i dont see this problem if the
> > number of threads is reduced...,meaning less context switching.
>
> > thanks
>
> It is hard to be sure without understanding more about your program, but the
> thread switching period is probably 20 milliseconds. So if you have 100
> threads it could be as long as 2000 msec before each one gets a turn. So of
> course a 100 msec timeout seems likely to fail. The fact that the problem
> seems to go away with fewer threads supports this theory. This sounds like
> a serious design scalability problem.
>
> Since all the UDP messages come from the same place they must be sequential,
> and you could consider a design that uses only one thread to process all UDP
> input.
>
> --
> Scott McPhillips [VC++ MVP]- Hide quoted text -
>
> - Show quoted text -

Hi,

1) Since i'm communicating with a serial hub (each serial hub is
capable of communicating with 16 RS232 devices). The UDP messages
coming from the serial will be parallel. So i definitely need to read
parallely.i.e. from multiple threads..

If the winsock select timer expires when the thread is suspended and
later when the thread resumes, will it just report timeout/will check
the socket buffer for data. Appreciate if you can clarify this.

2) when i'm reading for response messages on the UDP socket, i want to
make sure the entire message reading loop timesout in <=150 millisec.
Since i'm doing network serial programming, the serial data will be
coming in multiple UDP messages..I want to do multiple reads i.e.
thru' select but timeout exactly/approx at 150 msec. how do i make
sure this can happen. The current code that i'm using is using the
GetTickcount() & this seem to be incorrect..if the thread switching
latency is so high..how can i specify a relative timeout here

dw = GetTickCount()

while ((dw - Gettickcount()) <=150)
{

nRetValue = select(timeout 100);
if(nRetValue >0)
recvfrom(); //non-blocking read..
}

In the above code, how do i ensure this thread really waits for
150msec..excluding the thread switching latency..
Appreciate your help
Thanks

Scott
Wed Oct 17 08:57:19 PDT 2007

<vanisathish@gmail.com> wrote in message
news:1192635214.003888.274170@k35g2000prh.googlegroups.com...
> Hi,
>
> 1) Since i'm communicating with a serial hub (each serial hub is
> capable of communicating with 16 RS232 devices). The UDP messages
> coming from the serial will be parallel. So i definitely need to read
> parallely.i.e. from multiple threads..

Is there only one network card? If there is only one network card then the
UDP messages cannot arrive in parallel.

> 2) when i'm reading for response messages on the UDP socket, i want to
> make sure the entire message reading loop timesout in <=150 millisec.
> Since i'm doing network serial programming, the serial data will be
> coming in multiple UDP messages..I want to do multiple reads i.e.
> thru' select but timeout exactly/approx at 150 msec. how do i make
> sure this can happen. The current code that i'm using is using the
> GetTickcount() & this seem to be incorrect..if the thread switching
> latency is so high..how can i specify a relative timeout here
>
> dw = GetTickCount()
>
> while ((dw - Gettickcount()) <=150)
> {
>
> nRetValue = select(timeout 100);
> if(nRetValue >0)
> recvfrom(); //non-blocking read..
> }
>
> In the above code, how do i ensure this thread really waits for
> 150msec..excluding the thread switching latency..
> Appreciate your help
> Thanks
>

If you are asking how to prevent the thread switching, you can't. I think
you would do better to make the design event-driven, processing all received
messages when they are received.

--
Scott McPhillips [VC++ MVP]

Mark
Wed Oct 17 09:29:41 PDT 2007

The design sounds extremely inefficient, both in resources and CPU use.

You aren't getting any benefit using 100 threads on a single CPU.
I bet you could use an IO completion port with 2 threads and get much better
performance.
This would be an event-driven solution, as Scott suggested.

Mark

--
Mark Salsbery
Microsoft MVP - Visual C++


<vanisathish@gmail.com> wrote in message
news:1192630618.951354.298320@e34g2000pro.googlegroups.com...
> Hi,
>
> i'm communicating with more than 40 serial devices connected thru' an
> serial hub. the pc has to communicate thru' UDP to the serial hub.
>
> since the response is quite sensitve, ( the application has to timeout
> within 100msec) we are using "select" call with timeout.
>
> There are around 100 threads that are parallely polling all the 40
> devices on the serial hub.
>
> I noticed that the select call is timingout i.e. returning 0
> eventhough there is socket in the buffer..does this mean that the
> timer got expired when that thread is in the sleep state (i.e. some
> other thread is running) and later when the thread resumes, it is just
> returning the previous state...
>
> I'm running this application on a 2.66G Pentium PC..will the context
> switching be an issue at all here. i dont see this problem if the
> number of threads is reduced...,meaning less context switching.
>
> thanks
>

Mark
Wed Oct 17 09:31:58 PDT 2007

"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
news:eUdsRvMEIHA.3848@TK2MSFTNGP05.phx.gbl...
> <vanisathish@gmail.com> wrote in message
> news:1192630618.951354.298320@e34g2000pro.googlegroups.com...
>
>but the thread switching period is probably 20 milliseconds.


Hi Scott,

I'm curious, where did you get that number from? That seems like a really
long time and it makes me wonder how my multimedia software works at all :)
Is it really that long?

Cheers,
Mark

--
Mark Salsbery
Microsoft MVP - Visual C++


"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
news:eUdsRvMEIHA.3848@TK2MSFTNGP05.phx.gbl...
> <vanisathish@gmail.com> wrote in message
> news:1192630618.951354.298320@e34g2000pro.googlegroups.com...
>> Hi,
>>
>> i'm communicating with more than 40 serial devices connected thru' an
>> serial hub. the pc has to communicate thru' UDP to the serial hub.
>>
>> since the response is quite sensitve, ( the application has to timeout
>> within 100msec) we are using "select" call with timeout.
>>
>> There are around 100 threads that are parallely polling all the 40
>> devices on the serial hub.
>>
>> I noticed that the select call is timingout i.e. returning 0
>> eventhough there is socket in the buffer..does this mean that the
>> timer got expired when that thread is in the sleep state (i.e. some
>> other thread is running) and later when the thread resumes, it is just
>> returning the previous state...
>>
>> I'm running this application on a 2.66G Pentium PC..will the context
>> switching be an issue at all here. i dont see this problem if the
>> number of threads is reduced...,meaning less context switching.
>>
>> thanks
>>
>
> It is hard to be sure without understanding more about your program, but
> the thread switching period is probably 20 milliseconds. So if you have
> 100 threads it could be as long as 2000 msec before each one gets a turn.
> So of course a 100 msec timeout seems likely to fail. The fact that the
> problem seems to go away with fewer threads supports this theory. This
> sounds like a serious design scalability problem.
>
> Since all the UDP messages come from the same place they must be
> sequential, and you could consider a design that uses only one thread to
> process all UDP input.
>
> --
> Scott McPhillips [VC++ MVP]

Scott
Wed Oct 17 10:23:49 PDT 2007

"Mark Salsbery [MVP]" <MarkSalsbery[MVP]@newsgroup.nospam> wrote in message
news:eMnp%23sNEIHA.5752@TK2MSFTNGP02.phx.gbl...
>>but the thread switching period is probably 20 milliseconds.
>
>
> Hi Scott,
>
> I'm curious, where did you get that number from? That seems like a really
> long time and it makes me wonder how my multimedia software works at all
> :) Is it really that long?
>
> Cheers,
> Mark


The system timer interrupt interval is available from
GetSystemTimeAdjustment(). If my memory is right it was 20 msec for
NT/2K/XP. On my Vista machine it returns 15 msec.

Timer-based thread switching can't go faster than the system timer. But who
knows, with multimedia I/O they may have souped it up to do a thread switch
upon a multimedia interrupt. Sound cards don't need much help though,
because they contain hardware buffering that greatly reduces the interrupt
rate.

--
Scott McPhillips [VC++ MVP]

Mark
Wed Oct 17 10:34:59 PDT 2007

Ah, thanks.

I'm not sure how the OS times switching threads, but it seems much faster
than 20ms. I regularly use multiple threads that wake on 20ms intervals and
it's pretty consistent, even on single CPU machines.
I suppose it's consistent because most threads in the system are waiting
most of the time.

Mark


--
Mark Salsbery
Microsoft MVP - Visual C++


"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
news:eLHaXKOEIHA.1316@TK2MSFTNGP02.phx.gbl...
> "Mark Salsbery [MVP]" <MarkSalsbery[MVP]@newsgroup.nospam> wrote in
> message news:eMnp%23sNEIHA.5752@TK2MSFTNGP02.phx.gbl...
>>>but the thread switching period is probably 20 milliseconds.
>>
>>
>> Hi Scott,
>>
>> I'm curious, where did you get that number from? That seems like a really
>> long time and it makes me wonder how my multimedia software works at all
>> :) Is it really that long?
>>
>> Cheers,
>> Mark
>
>
> The system timer interrupt interval is available from
> GetSystemTimeAdjustment(). If my memory is right it was 20 msec for
> NT/2K/XP. On my Vista machine it returns 15 msec.
>
> Timer-based thread switching can't go faster than the system timer. But
> who knows, with multimedia I/O they may have souped it up to do a thread
> switch upon a multimedia interrupt. Sound cards don't need much help
> though, because they contain hardware buffering that greatly reduces the
> interrupt rate.
>
> --
> Scott McPhillips [VC++ MVP]

Alexander
Wed Oct 17 19:38:54 PDT 2007

20 ms would be a time slice (timer tick). But threads not have to switch at
only timer ticks. A higher priority thread gets CPU as soon as it becomes
ready to run (assuming that it's the only ready thread with this priority).

"Mark Salsbery [MVP]" <MarkSalsbery[MVP]@newsgroup.nospam> wrote in message
news:uTDcMQOEIHA.3980@TK2MSFTNGP03.phx.gbl...
> Ah, thanks.
>
> I'm not sure how the OS times switching threads, but it seems much faster
> than 20ms. I regularly use multiple threads that wake on 20ms intervals
> and it's pretty consistent, even on single CPU machines.
> I suppose it's consistent because most threads in the system are waiting
> most of the time.
>
> Mark
>
>
> --
> Mark Salsbery
> Microsoft MVP - Visual C++
>
>
> "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
> news:eLHaXKOEIHA.1316@TK2MSFTNGP02.phx.gbl...
>> "Mark Salsbery [MVP]" <MarkSalsbery[MVP]@newsgroup.nospam> wrote in
>> message news:eMnp%23sNEIHA.5752@TK2MSFTNGP02.phx.gbl...
>>>>but the thread switching period is probably 20 milliseconds.
>>>
>>>
>>> Hi Scott,
>>>
>>> I'm curious, where did you get that number from? That seems like a
>>> really long time and it makes me wonder how my multimedia software works
>>> at all :) Is it really that long?
>>>
>>> Cheers,
>>> Mark
>>
>>
>> The system timer interrupt interval is available from
>> GetSystemTimeAdjustment(). If my memory is right it was 20 msec for
>> NT/2K/XP. On my Vista machine it returns 15 msec.
>>
>> Timer-based thread switching can't go faster than the system timer. But
>> who knows, with multimedia I/O they may have souped it up to do a thread
>> switch upon a multimedia interrupt. Sound cards don't need much help
>> though, because they contain hardware buffering that greatly reduces the
>> interrupt rate.
>>
>> --
>> Scott McPhillips [VC++ MVP]
>
>

vanisathish
Thu Oct 18 02:19:03 PDT 2007

Thanks for your inputs. I have around 40 devices connected to a
serial hub(portserver from Digi). Currently there are 2 options to
read/write data from the serial hub.

1) Use windows COMM API ( In order to use this we need to install the
Digi Realport driver on the NMS PC). This
real port driver passes the data to the Windows COM layer & our
application will read

2) Use UDP profile of the portserver..(To read directly from the
portserver without using the intermediate Digi Realport
driver.

The server application that we are running is supposed to write
command requests to the devices continously & read the response within
100 mSec and update its cache..There will be instances where the
device may not be available, so our application shouldn't wait for too
long.

Even for approach (1) using COMM API, we are spawing around 100
threads that continuously does WriteFile & ReadFile..Since with this
approach we found some responses are missing..i.e. not reached to our
applicationw ithin 100msec..

we went for the UDP approach, where in we can eliminate the DigiReal
port driver...Now if i want to go back to the COMM API approach, what
would be the best approach to do the multiple I/O on the various
RS-232 COM ports

Ben
Thu Oct 18 07:40:37 PDT 2007


<vanisathish@gmail.com> wrote in message
news:1192699143.372424.125840@t8g2000prg.googlegroups.com...
> Thanks for your inputs. I have around 40 devices connected to a
> serial hub(portserver from Digi). Currently there are 2 options to
> read/write data from the serial hub.
>
> 1) Use windows COMM API ( In order to use this we need to install the
> Digi Realport driver on the NMS PC). This
> real port driver passes the data to the Windows COM layer & our
> application will read
>
> 2) Use UDP profile of the portserver..(To read directly from the
> portserver without using the intermediate Digi Realport
> driver.
>
> The server application that we are running is supposed to write
> command requests to the devices continously & read the response within
> 100 mSec and update its cache..There will be instances where the
> device may not be available, so our application shouldn't wait for too
> long.
>
> Even for approach (1) using COMM API, we are spawing around 100
> threads that continuously does WriteFile & ReadFile..Since with this
> approach we found some responses are missing..i.e. not reached to our
> applicationw ithin 100msec..
>
> we went for the UDP approach, where in we can eliminate the DigiReal
> port driver...Now if i want to go back to the COMM API approach, what
> would be the best approach to do the multiple I/O on the various
> RS-232 COM ports

One thread per processor, 100 kernel events, overlapped I/O,
WaitForMultipleObjects (with bWaitAll = FALSE). Or use ReadFileEx and
completion routines with an alertable sleep (e.g. SleepEx with bAlertable =
TRUE).

Ben
Thu Oct 18 07:41:50 PDT 2007


"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
news:eLHaXKOEIHA.1316@TK2MSFTNGP02.phx.gbl...
> "Mark Salsbery [MVP]" <MarkSalsbery[MVP]@newsgroup.nospam> wrote in
> message news:eMnp%23sNEIHA.5752@TK2MSFTNGP02.phx.gbl...
>>>but the thread switching period is probably 20 milliseconds.
>>
>>
>> Hi Scott,
>>
>> I'm curious, where did you get that number from? That seems like a really
>> long time and it makes me wonder how my multimedia software works at all
>> :) Is it really that long?
>>
>> Cheers,
>> Mark
>
>
> The system timer interrupt interval is available from
> GetSystemTimeAdjustment(). If my memory is right it was 20 msec for
> NT/2K/XP. On my Vista machine it returns 15 msec.
>
> Timer-based thread switching can't go faster than the system timer. But
> who knows, with multimedia I/O they may have souped it up to do a thread
> switch upon a multimedia interrupt. Sound cards don't need much help
> though, because they contain hardware buffering that greatly reduces the
> interrupt rate.

Multimedia software often calls timeBeginPeriod/timeEndPeriod to get a
faster timer interrupt interval, as low as 1ms.

>
> --
> Scott McPhillips [VC++ MVP]

Mark
Thu Oct 18 11:58:05 PDT 2007

That makes sense. Thank you!

Mark


"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:uBiEIATEIHA.3712@TK2MSFTNGP02.phx.gbl...
> 20 ms would be a time slice (timer tick). But threads not have to switch
> at only timer ticks. A higher priority thread gets CPU as soon as it
> becomes ready to run (assuming that it's the only ready thread with this
> priority).
>
> "Mark Salsbery [MVP]" <MarkSalsbery[MVP]@newsgroup.nospam> wrote in
> message news:uTDcMQOEIHA.3980@TK2MSFTNGP03.phx.gbl...
>> Ah, thanks.
>>
>> I'm not sure how the OS times switching threads, but it seems much faster
>> than 20ms. I regularly use multiple threads that wake on 20ms intervals
>> and it's pretty consistent, even on single CPU machines.
>> I suppose it's consistent because most threads in the system are waiting
>> most of the time.
>>
>> Mark
>>
>>
>> --
>> Mark Salsbery
>> Microsoft MVP - Visual C++
>>
>>
>> "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
>> news:eLHaXKOEIHA.1316@TK2MSFTNGP02.phx.gbl...
>>> "Mark Salsbery [MVP]" <MarkSalsbery[MVP]@newsgroup.nospam> wrote in
>>> message news:eMnp%23sNEIHA.5752@TK2MSFTNGP02.phx.gbl...
>>>>>but the thread switching period is probably 20 milliseconds.
>>>>
>>>>
>>>> Hi Scott,
>>>>
>>>> I'm curious, where did you get that number from? That seems like a
>>>> really long time and it makes me wonder how my multimedia software
>>>> works at all :) Is it really that long?
>>>>
>>>> Cheers,
>>>> Mark
>>>
>>>
>>> The system timer interrupt interval is available from
>>> GetSystemTimeAdjustment(). If my memory is right it was 20 msec for
>>> NT/2K/XP. On my Vista machine it returns 15 msec.
>>>
>>> Timer-based thread switching can't go faster than the system timer. But
>>> who knows, with multimedia I/O they may have souped it up to do a thread
>>> switch upon a multimedia interrupt. Sound cards don't need much help
>>> though, because they contain hardware buffering that greatly reduces the
>>> interrupt rate.
>>>
>>> --
>>> Scott McPhillips [VC++ MVP]
>>
>>
>
>

Alexander
Thu Oct 18 19:42:05 PDT 2007

You can only wait for 64 events.

"Ben Voigt [C++ MVP]" <rbv@nospam.nospam> wrote in message
news:%23x$jUTZEIHA.5208@TK2MSFTNGP04.phx.gbl...
>
> One thread per processor, 100 kernel events, overlapped I/O,
> WaitForMultipleObjects (with bWaitAll = FALSE). Or use ReadFileEx and
> completion routines with an alertable sleep (e.g. SleepEx with bAlertable
> = TRUE).
>

Ben
Fri Oct 19 07:33:59 PDT 2007


"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:eJexlmfEIHA.3548@TK2MSFTNGP06.phx.gbl...
> You can only wait for 64 events.

Then two threads with WFMO. I don't think that limitation affects alertable
sleep with APCs though.

>
> "Ben Voigt [C++ MVP]" <rbv@nospam.nospam> wrote in message
> news:%23x$jUTZEIHA.5208@TK2MSFTNGP04.phx.gbl...
>>
>> One thread per processor, 100 kernel events, overlapped I/O,
>> WaitForMultipleObjects (with bWaitAll = FALSE). Or use ReadFileEx and
>> completion routines with an alertable sleep (e.g. SleepEx with bAlertable
>> = TRUE).
>>
>
>

Alexander
Fri Oct 19 13:51:06 PDT 2007

Or one thread with IOCP... IOCP doesn't have the 64 handles
limitation either.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"Ben Voigt [C++ MVP]" <rbv@nospam.nospam> wrote in message
news:ufK5j1lEIHA.4712@TK2MSFTNGP04.phx.gbl...
>
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:eJexlmfEIHA.3548@TK2MSFTNGP06.phx.gbl...
>> You can only wait for 64 events.
>
> Then two threads with WFMO. I don't think that limitation affects
> alertable sleep with APCs though.
>
>>
>> "Ben Voigt [C++ MVP]" <rbv@nospam.nospam> wrote in message
>> news:%23x$jUTZEIHA.5208@TK2MSFTNGP04.phx.gbl...
>>>
>>> One thread per processor, 100 kernel events, overlapped I/O,
>>> WaitForMultipleObjects (with bWaitAll = FALSE). Or use ReadFileEx and
>>> completion routines with an alertable sleep (e.g. SleepEx with
>>> bAlertable = TRUE).
>>>
>>
>>
>
>