This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Delays while network processing


On Monday, 3. June 2002 18:26, Roland Caßebohm wrote:
> On Monday, 3. June 2002 18:02, Gary Thomas wrote:
> > On Mon, 2002-06-03 at 09:58, Roland Caßebohm wrote:
> > > Hello,
> > >
> > > I am using the ARM7 SNDS port from Grant Edwards. I don't use ecos 2.0.
> > >
> > > In my application there are several threads and each have some TCP
> > > connections. I'm using pthreads.
> > > Sometimes the network transfer stops for many seconds or even minutes.
> > > This happens sometimes on all threads, but sometime only on one thread
> > > and it could happen while data is incoming or/and data is outcoming.
> > > The threads have the same priority (15). But while the delay the
> > > scheduler seems to be in idle state.
> > > The problem happens more often if there is more network traffic in my
> > > theads, but sometime is also there, if I use a simple telnet menu
> > > (can't be much traffic).
> > >
> > > Does anybody have any idea?
> >
> > Have you tried breaking in using GDB while the system is in this state?
> > Doing that, you can use "info threads" to get some idea about what's
> > happening and even get complete backtrace & state information on all the
> > threads in the system.
>
> I don't know how to break in while the system is in this state, because I
> can only break using GDB if the system just make some output on the gdb
> channel.

I have installed now an abort interrupt so I can break in by generating an 
external interrupt.

The delayed threads are in sleep state. One thread is in select() and another 
which is blocked is in sleep(). This thread only prints some memory 
informations over a TCP connection in a loop with one second delay ( sleep(1) 
).

The at the following output the thread stops:

meminfo:
arena    =      763968 uordblks =      141904 fordblks =      622044
+-------------+-------------+-------------+
|     pid     | stack usage |    state    |
+-------------+-------------+-------------+
|     snmp    |        4672 |      n      |
| main   2048 |        1852 |      R      |
|        4098 |        2280 |      R      |
|        3073 |        2164 |      R      |
+-------------+-------------+-------------+

meminfo:
arena    =      763968 uordblks =      141904 fordblks =      622044
+-------------+-------------+-------------+
|     pid     | stack usage |    state    |
+-------------+-------------+-------------+
|     snmp    |        4672 |      n      |
| main   2048 |        1852 |      R      |
|        40

I think the thread have to be in sleep state after printing the hole 
information and not while.

The "Network alarm support" thread is in cyg_flag_timed_wait() (sleep state). 
Because I show the current thread number at the LEDs of my board, I can see 
that the "Network alarm support" thread is still working (the corresponding 
LED is flashing 
beneath the one off the idle thread, which seems to get most time).

The "Network support" thread is in cyg_flag_wait() (sleep state).


Roland

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]