Re: Console app freezes

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Ilya Tumanov [MS] (ilyatum_at_online.microsoft.com)
Date: 12/21/04


Date: Tue, 21 Dec 2004 04:56:59 GMT

Oh, boy... I wish we can add some pin toggling code in key places, attach
an oscilloscope and see all timing relations right away like I used to do
back in my firmware development days... Too bad, that's probably not an
option.

Anyway, I'm starting to wonder if it's a simple case of performance
problem. Geode@300 MHz is probably slower than 200MHz ARM.
To make things worse, CF V1 is very slow on x86. Any chance you can try it
on CF V2 (released with VS 2005 Beta)? It's way, way faster.
Your app should run without recompilation (with config file if you have V1
in ROM).

We can't rule out thread interaction issues as well, however.
Can you disable all threads (or do nothing in them) but one serial thread
and see if it can handle, say, 200 packets per second?

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
> Thread-Topic: Console app freezes
> thread-index: AcTnCQZq3JeJx5bQS7aDw22pv2S38w==
> X-WBNR-Posting-Host: 202.6.138.45
> From: "=?Utf-8?B?TWljaGFlbC0tSg==?=" <MichaelJ@discussions.microsoft.com>
> References: <2A88D523-2302-4891-943E-2170F347100A@microsoft.com>
<41c11d2a$1@news.microsoft.com>
<BE00D6F5-A077-47D8-9C4A-3528F9494CE9@microsoft.com>
<KNzYqk64EHA.3512@cpmsftngxa10.phx.gbl>
<728DC81F-04A6-43A7-BCE5-D4132D86CDF6@microsoft.com>
<UQI8R$r5EHA.2600@cpmsftngxa10.phx.gbl>
<17826F3A-DA24-4C76-A645-7DF5087B4805@microsoft.com>
<Y3W9t5v5EHA.3200@cpmsftngxa10.phx.gbl>
<F25AB25D-C049-416F-9F9E-E0AC0B60BE81@microsoft.com>
<Nzk9Ncw5EHA.764@cpmsftngxa10.phx.gbl>
> Subject: Re: Console app freezes
> Date: Mon, 20 Dec 2004 18:59:02 -0800
> Lines: 287
> Message-ID: <CDD1EC4A-2B8B-45AA-9FCF-6D34BA5B2B34@microsoft.com>
> MIME-Version: 1.0
> Content-Type: text/plain;
> charset="Utf-8"
> Content-Transfer-Encoding: 8bit
> X-Newsreader: Microsoft CDO for Windows 2000
> Content-Class: urn:content-classes:message
> Importance: normal
> Priority: normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
> Newsgroups: microsoft.public.dotnet.framework.compactframework
> NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
> Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA02.phx.gbl!cpmsftngxa06.phx.gbl!TK2MSFTNGP08
phx.gbl!TK2MSFTNGXA03.phx.gbl
> Xref: cpmsftngxa10.phx.gbl
microsoft.public.dotnet.framework.compactframework:67304
> X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework
>
> At the moment, i open all 4 comports but i'm only giving serial input to
2
> ports (1 & 3). When i had 20 packets/sec going into each port1 and port3,
the
> app worked fine (40 packets/sec total). When i increased that to 30
> packets/sec each (60 packets/sec total) the app would "freeze" after a
while.
> Increasing it to 40 packets/sec each (80 packets/sec total) also made it
> "freeze".
>
> I then decided to test the app with only one port processing serial
input. I
> used port1 and inputted 80 packets/sec. It worked fine. There's some kind
of
> serious threading issue happening and i can't seem to pinpoint it.
>
> Also, i am using System.Threading timers. Thanks.
>
> ""Ilya Tumanov [MS]"" wrote:
>
> > No, it should not cause problems as it would release ticks to OS while
> > waiting.
> >
> > If you leave only, say, two serial ports, is it working? Is it working
if
> > you discard of serial data without processing it?
> >
> > About timers: are you using one in Windows.Forms or in System.Threading?
> >
> > Best regards,
> >
> > Ilya
> >
> >
> > This posting is provided "AS IS" with no warranties, and confers no
rights.
> >
> >
> > --------------------
> > > Thread-Topic: Console app freezes
> > > thread-index: AcTnAKQ4g7fe4r2XTIeutiQV26gjCw==
> > > X-WBNR-Posting-Host: 202.6.138.45
> > > From: "=?Utf-8?B?TWljaGFlbC0tSg==?="
<MichaelJ@discussions.microsoft.com>
> > > References: <2A88D523-2302-4891-943E-2170F347100A@microsoft.com>
> > <41c11d2a$1@news.microsoft.com>
> > <BE00D6F5-A077-47D8-9C4A-3528F9494CE9@microsoft.com>
> > <KNzYqk64EHA.3512@cpmsftngxa10.phx.gbl>
> > <728DC81F-04A6-43A7-BCE5-D4132D86CDF6@microsoft.com>
> > <UQI8R$r5EHA.2600@cpmsftngxa10.phx.gbl>
> > <17826F3A-DA24-4C76-A645-7DF5087B4805@microsoft.com>
> > <Y3W9t5v5EHA.3200@cpmsftngxa10.phx.gbl>
> > > Subject: Re: Console app freezes
> > > Date: Mon, 20 Dec 2004 17:59:01 -0800
> > > Lines: 193
> > > Message-ID: <F25AB25D-C049-416F-9F9E-E0AC0B60BE81@microsoft.com>
> > > MIME-Version: 1.0
> > > Content-Type: text/plain;
> > > charset="Utf-8"
> > > Content-Transfer-Encoding: 8bit
> > > X-Newsreader: Microsoft CDO for Windows 2000
> > > Content-Class: urn:content-classes:message
> > > Importance: normal
> > > Priority: normal
> > > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
> > > Newsgroups: microsoft.public.dotnet.framework.compactframework
> > > NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
> > > Path:
> >
cpmsftngxa10.phx.gbl!TK2MSFTFEED02.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGXA0
> > 3.phx.gbl
> > > Xref: cpmsftngxa10.phx.gbl
> > microsoft.public.dotnet.framework.compactframework:67300
> > > X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework
> > >
> > > WaitCommEvent() is actually a P/invoke method which calls the Win
API's
> > > (coredll.dll) WaitCommEvent() method. Quoting the MSDN: "This
function
> > waits
> > > for an event to occur for a specified communications device. The set
of
> > > events that are monitored by WaitCommEvent is contained in the event
mask
> > > associated with the device handle."
> > >
> > > Would calling WaitCommEvent be a problem?
> > >
> > > I will see if i can use a circular buffer. Thanks.
> > >
> > > ""Ilya Tumanov [MS]"" wrote:
> > >
> > > > What's in WaitForCommEvent()? It's not a while loop which checks
for
> > some
> > > > variable set from event, is it?
> > > >
> > > > I would also suggest using circular buffer instead of creating new
> > array
> > > > lists and arrays for every packet.
> > > > You'll need to firure out what to do in case buffer overflows
> > (terminate,
> > > > log event, ignore extra data, etc.).
> > > >
> > > > Best regards,
> > > >
> > > > Ilya
> > > >
> > > > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> > > > --------------------
> > > > > Thread-Topic: Console app freezes
> > > > > thread-index: AcTm7jZvbF/weKNQT22YrExp4stGvg==
> > > > > X-WBNR-Posting-Host: 202.6.138.45
> > > > > From: "=?Utf-8?B?TWljaGFlbC0tSg==?="
> > <MichaelJ@discussions.microsoft.com>
> > > > > References: <2A88D523-2302-4891-943E-2170F347100A@microsoft.com>
> > > > <41c11d2a$1@news.microsoft.com>
> > > > <BE00D6F5-A077-47D8-9C4A-3528F9494CE9@microsoft.com>
> > > > <KNzYqk64EHA.3512@cpmsftngxa10.phx.gbl>
> > > > <728DC81F-04A6-43A7-BCE5-D4132D86CDF6@microsoft.com>
> > > > <UQI8R$r5EHA.2600@cpmsftngxa10.phx.gbl>
> > > > > Subject: Re: Console app freezes
> > > > > Date: Mon, 20 Dec 2004 15:47:06 -0800
> > > > > Lines: 116
> > > > > Message-ID: <17826F3A-DA24-4C76-A645-7DF5087B4805@microsoft.com>
> > > > > MIME-Version: 1.0
> > > > > Content-Type: text/plain;
> > > > > charset="Utf-8"
> > > > > Content-Transfer-Encoding: 8bit
> > > > > X-Newsreader: Microsoft CDO for Windows 2000
> > > > > Content-Class: urn:content-classes:message
> > > > > Importance: normal
> > > > > Priority: normal
> > > > > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
> > > > > Newsgroups: microsoft.public.dotnet.framework.compactframework
> > > > > NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
> > > > > Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
> > > > > Xref: cpmsftngxa10.phx.gbl
> > > > microsoft.public.dotnet.framework.compactframework:67289
> > > > > X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework
> > > > >
> > > > > My app uses OpenNETCF.org’s serial comms code
with a few
> > modifications
> > > > in
> > > > > their Port.cs class. This class simply sets up a thread called
> > > > > ‘CommEventThread’ that continually
loops the associated
> > com port for
> > > > data.
> > > > > However, I had to modify this to reflect the modifications I made
to
> > the
> > > > > lower level serial drivers. The serial drivers were changed such
that
> > it
> > > > > suited the data it was processing. The data was basically
composed of
> > > > packets
> > > > > separated by parity errors. I couldn’t use a
parity error
> > event to
> > > > > distinguish between packets because the app couldnâ€â„
¢t keep up
> > with the
> > > > number
> > > > > of parity error events being raised. Instead, I modified the
serial
> > > > driver
> > > > > such that it places an escape ‘f0’
character in the
> > receive stream
> > > > whenever
> > > > > it detected a parity error and my app simply needed to locate
this Ã
> > ¢â‚¬Ëœ
> > > > f0’
> > > > > character. To distinguish between an escape ‘f0âÃ
¢â€šÂ¬Ã¢â€žÂ¢
> > character between an
> > > > actual
> > > > > data ‘f0’, I replaced the data one
with a 6-byte
> > signature which my
> > > > higher
> > > > > level app also searches for. So in pseudo code, this is how the
> > > > > CommEventThread in Port.cs looks like:
> > > > >
> > > > > private void CommEventThread()
> > > > > {
> > > > > while(hPort != invalidHandle)
> > > > > {
> > > > >
> > > > > // Wait for a comm event to take place;
> > > > > WaitForCommEvent();
> > > > >
> > > > > if(error event)
> > > > > {
> > > > > // Handle error;
> > > > > }
> > > > >
> > > > > if(data received)
> > > > > {
> > > > > do
> > > > > {
> > > > > ReadFile() to rxFIFO buffer;
> > > > > }while(bytesread > 0)
> > > > > }
> > > > >
> > > > > while(rxFIFO.Count > 0)
> > > > > {
> > > > > byte u = rxFIFO.Dequeue();
> > > > >
> > > > > if(u == any byte)
> > > > > {
> > > > > // Add ‘u’ to
progressBuffer ArrayList
> > > > > progressBuffer.Add(u);
> > > > > }
> > > > >
> > > > > if(u == ‘f0’)
> > > > > {
> > > > > // Raise ParityError() event and clear
progressBuffer;
> > > > > ParityError();
> > > > > progressBuffer = new ArrayList();
> > > > > }
> > > > >
> > > > > if(u is part of 6-byte signature)
> > > > > {
> > > > > // Take note of it;
> > > > > }
> > > > >
> > > > > if(u is last byte of 6-byte signature)
> > > > > {
> > > > > // Insert ‘f0’ in
the data;
> > > > > progressBuffer.Add(u);
> > > > > }
> > > > > }
> > > > > }
> > > > > }
> > > > >
> > > > > I also added the method ReadProgressBuffer() in Port.cs which
gets
> > the
> > > > > current progressBuffer contents when a parity error event is
raised.
> > This
> > > > > will be called by my main app.
> > > > >
> > > > > public byte[] ReadProgressBuffer(){
> > > > > return (byte[])progressBuffer.ToArray(typeof(byte));
> > > > > }
> > > > >
> > > > > In my main code, I instantiate 4 port objects which means that I
> > > > introduce 4
> > > > > CommEventThreads executing the above code in non-stop looping. My
> > main
> > > > also
> > > > > handles the ParityError events raised by each port by creating 4
> > > > indentical
> > > > > event handlers that process the data by firstly calling
> > > > > portX.ReadProgressBuffer(). Below is the pseudo code:
> > > > >
> > > > > private void portX_ParityError()
> > > > > {
> > > > > byte[] packet = portX.ReadProgressBuffer();
> > > > >
> > > > > // Process the byte array here;
> > > > > // This predominantly involves packet validation -
> > > > > // CRC checks, and updating a set of global data;
> > > > > }
> > > > >
> > > > > When this handler returns, the CommEventThread continues by
clearing
> > the
> > > > > progressBuffer and repeating the whole process.
> > > > >
> > > > > In addition to this, I have 3 timers, TCP/IP stuff, and log
keeping
> > (as
> > > > > described in my first post). Would it definitely be a CPU
overload
> > issue?
> > > > If
> > > > > you need more information regarding my app or any of its code,
please
> > > > feel
> > > > > free to ask. Thanks again.
> > > > >
> > > > >
> > > > > ""Ilya Tumanov [MS]"" wrote:
> > > > >
> > > > > > This behavior seem to be a result if excessive CPU load.
> > > > > > Do you have some tight loops anywhere? Say, waiting for
something?
> > > > > > Do you know what your app will do in case more data is coming
from
> > > > serial
> > > > > > port(s) than can be processed?
> > > > > > Could it wait for available buffer in a loop without sleep() in
it?
> > > > > > That would cause the "serial" thread to use 100% CPU, which
would
> > slow
> > > > down
> > > > > > all other thread, which would slow down data processing, which
> > would
> > > > cause
> > > > > > "serial" thread to wait... and so on. As you remove incoming
data,
> > your
> > > > app
> > > > > > would eventually process data and unlock itself.
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Ilya
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>



Relevant Pages

  • Re: DC comics could almost certainly vastly increase the sales of their comics
    ... rights, and appears to have proved a *very* savvy negotiator once it ... versus something like comics which were more of a piece with the ... The maker of a derivative work still owns the copyright in that part ... Spock boy an original character? ...
    (rec.arts.comics.dc.universe)
  • Re: how do i sell my character?
    ... ownership rights and intellectual property rights ... to, any titles, computer code, themes, objects, characters, character ... this License Agreement. ... content which appears in World of Warcraft. ...
    (alt.games.warcraft)
  • Re: Superboy-Prime MAJOR Spoiler
    ... ever believed that Superman and Superboy were depictions ... Tom Hughes invented a character called Harry Flashman who was a schoolboy ... The Frank Baum estate has the rights to the Oz books and Dorothy, ...
    (rec.arts.comics.dc.universe)
  • Re: User Rights Assignment
    ... assigned load and unload drivers rights to him. ... What happens if you take him out of Power Users & add Users to the rights ... equipment using the comm port and to verify that it sets up as ... added assignment of add and remove drivers in the local user ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Wanted: Solution to virtual tty capture problem.
    ... > Under SCO OpenServer 5.0.5, an application that can listen to, and read ... > read from the port. ... > believe paying for a manual (or set of manuals) is warranted for a single ... character that I hope will never be in the real data like ~ or some ...
    (comp.unix.sco.misc)