System runs only if I move the mouse ...

I have a device simulator running on Windows which connect via socket to my
application running on Neutrino 6.2.1B. The simulator has successfully
connected up to 81 socket connection (same address but different port on
each connection). Everything works fine until it connects the 82nd
connection where the whole system in Neutrino got lock up. And strangely it
continues working when I move the mouse and lock up again if I stop the
moving the mouse. I have run spin that shows the following information:
Mem free: 61%
Net en0: < 1 %
Threads = 529
Total processes = 473
Memory = 132m
Total FDs = 4296
CPU% procnto > 90, spin 4

I have to move the mouse cotinuously to get the spin running, and when I
stop the mouse, spin also stops.

Looks like we have some interrupt problem here. My processes open a lot of
sockets, and I have timer running in almost all processes.

Can anyone help me with this problem? Have I reached some system limitation?
I have set -F10000 to my procnto.

Johannes <Jsukamtoh@infolink.co.id> wrote:
J > I have a device simulator running on Windows which connect via socket to my
J > application running on Neutrino 6.2.1B. The simulator has successfully
J > connected up to 81 socket connection (same address but different port on
J > each connection). Everything works fine until it connects the 82nd
J > connection where the whole system in Neutrino got lock up. And strangely it
J > continues working when I move the mouse and lock up again if I stop the
J > moving the mouse. I have run spin that shows the following information:
J > Mem free: 61%
J > Net en0: < 1 %
J > Threads = 529
J > Total processes = 473
J > Memory = 132m
J > Total FDs = 4296
J > CPU% procnto > 90, spin 4

J > I have to move the mouse cotinuously to get the spin running, and when I
J > stop the mouse, spin also stops.

J > Looks like we have some interrupt problem here. My processes open a lot of
J > sockets, and I have timer running in almost all processes.

J > Can anyone help me with this problem? Have I reached some system limitation?
J > I have set -F10000 to my procnto.

Sounds like you need one of those wheels to let your mouse keep running
without stopping. ;~}

Just to confirm, you are taking about moving the QNX mouse, right?

Is your mouse sharing an interrupt with something else? Like your
network card?

If so, try putting it or the network on a different interrupt.

It’s Phindows mouse, running on XP. I haven’t tried to move the mouse on the
Neutrino machine yet, but one thing I am sure of is the system stops
running.

I am not sure about the interrupt. When I install the O/S, it doesn’t ask
for which interrupt to use for the mouse and network, and I used all the
default setting. BTW, how can I check which interrupt used by the mouse and
network card? Any tools?

However, I don’t think it is the interrupt that causes the problem because I
notice the problem appears only when the number of opened files (shown by
spin) is approaching 4096. I have tried to create a small program which
keeps on spawning new processes and it worked just fine (over 5000 opened
FDs). So my assumption is that the problem is not due to spawning child
process itself, but it is due to the combination of opening file, sockets,
spawning child process, and timer, that my application uses quite a lot
here.

I am still not getting the answer from QNX regarding the limitation of
Neutrino in term of number of processes, file opened, sockets, timers, etc.
etc. which is not documented anywhere. Why is it so hard to get their answer
on this matter?

“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:bj7dg6$n8e$2@inn.qnx.com

Johannes <> Jsukamtoh@infolink.co.id> > wrote:
J > I have a device simulator running on Windows which connect via socket
to my
J > application running on Neutrino 6.2.1B. The simulator has successfully
J > connected up to 81 socket connection (same address but different port
on
J > each connection). Everything works fine until it connects the 82nd
J > connection where the whole system in Neutrino got lock up. And
strangely it
J > continues working when I move the mouse and lock up again if I stop
the
J > moving the mouse. I have run spin that shows the following
information:
J > Mem free: 61%
J > Net en0: < 1 %
J > Threads = 529
J > Total processes = 473
J > Memory = 132m
J > Total FDs = 4296
J > CPU% procnto > 90, spin 4

J > I have to move the mouse cotinuously to get the spin running, and when
I
J > stop the mouse, spin also stops.

J > Looks like we have some interrupt problem here. My processes open a
lot of
J > sockets, and I have timer running in almost all processes.

J > Can anyone help me with this problem? Have I reached some system
limitation?
J > I have set -F10000 to my procnto.

Sounds like you need one of those wheels to let your mouse keep running
without stopping. ;~}

Just to confirm, you are taking about moving the QNX mouse, right?

Is your mouse sharing an interrupt with something else? Like your
network card?

If so, try putting it or the network on a different interrupt.

Ah!

I didn’t get that you were running a Phindows screen. I thought from
your original post that you had an IP application running under windows
that was connecting to a QNX server with all of these sockets.

The first question is to determine which computer is hanging, QNX or
Windows. Is anything running on the Windows system besides the
Phindows session?


Johannes <Jsukamtoh@infolink.co.id> wrote:
J > It’s Phindows mouse, running on XP. I haven’t tried to move the mouse on the
J > Neutrino machine yet, but one thing I am sure of is the system stops
J > running.

J > I am not sure about the interrupt. When I install the O/S, it doesn’t ask
J > for which interrupt to use for the mouse and network, and I used all the
J > default setting. BTW, how can I check which interrupt used by the mouse and
J > network card? Any tools?

J > However, I don’t think it is the interrupt that causes the problem because I
J > notice the problem appears only when the number of opened files (shown by
J > spin) is approaching 4096. I have tried to create a small program which
J > keeps on spawning new processes and it worked just fine (over 5000 opened
J > FDs). So my assumption is that the problem is not due to spawning child
J > process itself, but it is due to the combination of opening file, sockets,
J > spawning child process, and timer, that my application uses quite a lot
J > here.

J > I am still not getting the answer from QNX regarding the limitation of
J > Neutrino in term of number of processes, file opened, sockets, timers, etc.
J > etc. which is not documented anywhere. Why is it so hard to get their answer
J > on this matter?

J > “Bill Caroselli” <qtps@earthlink.net> wrote in message
J > news:bj7dg6$n8e$2@inn.qnx.com

Johannes <> Jsukamtoh@infolink.co.id> > wrote:
J > I have a device simulator running on Windows which connect via socket
J > to my
J > application running on Neutrino 6.2.1B. The simulator has successfully
J > connected up to 81 socket connection (same address but different port
J > on
J > each connection). Everything works fine until it connects the 82nd
J > connection where the whole system in Neutrino got lock up. And
J > strangely it
J > continues working when I move the mouse and lock up again if I stop
J > the
J > moving the mouse. I have run spin that shows the following
J > information:
J > Mem free: 61%
J > Net en0: < 1 %
J > Threads = 529
J > Total processes = 473
J > Memory = 132m
J > Total FDs = 4296
J > CPU% procnto > 90, spin 4

J > I have to move the mouse cotinuously to get the spin running, and when
J > I
J > stop the mouse, spin also stops.

J > Looks like we have some interrupt problem here. My processes open a
J > lot of
J > sockets, and I have timer running in almost all processes.

J > Can anyone help me with this problem? Have I reached some system
J > limitation?
J > I have set -F10000 to my procnto.

Sounds like you need one of those wheels to let your mouse keep running
without stopping. ;~}

Just to confirm, you are taking about moving the QNX mouse, right?

Is your mouse sharing an interrupt with something else? Like your
network card?

If so, try putting it or the network on a different interrupt.

You are right, it doesn’t happen on Neutrino host. Both Neutrino and XP are
not hanging, but only the windows on Phindows have the problem. I have
Momentics and Outlook running on XP, but they are both working just fine
when the problem occurs, except that I can’t debug on Momentic, somehow
qconn doesn’t response, and I can’t ftp from any machine to Neutrino, it
doesn’t response at all (ftp shows connected to … and wait). On Neutrino,
I can run spin, (which is not on Phindows unless the mouse is moved), but I
can’t run netstat -an. Looks like tcpip problem to me. I suspect that I have
reached the maximum of something in the O/S, but I couldn’t figure out which
parameter in the O/S. Please refer to my other post in this group (Too many
open files) which may be related to this problem.

“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:bj7rfm$45a$1@inn.qnx.com

Ah!

I didn’t get that you were running a Phindows screen. I thought from
your original post that you had an IP application running under windows
that was connecting to a QNX server with all of these sockets.

The first question is to determine which computer is hanging, QNX or
Windows. Is anything running on the Windows system besides the
Phindows session?


Johannes <> Jsukamtoh@infolink.co.id> > wrote:
J > It’s Phindows mouse, running on XP. I haven’t tried to move the mouse
on the
J > Neutrino machine yet, but one thing I am sure of is the system stops
J > running.

J > I am not sure about the interrupt. When I install the O/S, it doesn’t
ask
J > for which interrupt to use for the mouse and network, and I used all
the
J > default setting. BTW, how can I check which interrupt used by the
mouse and
J > network card? Any tools?

J > However, I don’t think it is the interrupt that causes the problem
because I
J > notice the problem appears only when the number of opened files (shown
by
J > spin) is approaching 4096. I have tried to create a small program
which
J > keeps on spawning new processes and it worked just fine (over 5000
opened
J > FDs). So my assumption is that the problem is not due to spawning
child
J > process itself, but it is due to the combination of opening file,
sockets,
J > spawning child process, and timer, that my application uses quite a
lot
J > here.

J > I am still not getting the answer from QNX regarding the limitation of
J > Neutrino in term of number of processes, file opened, sockets, timers,
etc.
J > etc. which is not documented anywhere. Why is it so hard to get their
answer
J > on this matter?

J > “Bill Caroselli” <> qtps@earthlink.net> > wrote in message
J > news:bj7dg6$n8e$> 2@inn.qnx.com> …
Johannes <> Jsukamtoh@infolink.co.id> > wrote:
J > I have a device simulator running on Windows which connect via
socket
J > to my
J > application running on Neutrino 6.2.1B. The simulator has
successfully
J > connected up to 81 socket connection (same address but different
port
J > on
J > each connection). Everything works fine until it connects the 82nd
J > connection where the whole system in Neutrino got lock up. And
J > strangely it
J > continues working when I move the mouse and lock up again if I stop
J > the
J > moving the mouse. I have run spin that shows the following
J > information:
J > Mem free: 61%
J > Net en0: < 1 %
J > Threads = 529
J > Total processes = 473
J > Memory = 132m
J > Total FDs = 4296
J > CPU% procnto > 90, spin 4

J > I have to move the mouse cotinuously to get the spin running, and
when
J > I
J > stop the mouse, spin also stops.

J > Looks like we have some interrupt problem here. My processes open a
J > lot of
J > sockets, and I have timer running in almost all processes.

J > Can anyone help me with this problem? Have I reached some system
J > limitation?
J > I have set -F10000 to my procnto.

Sounds like you need one of those wheels to let your mouse keep running
without stopping. ;~}

Just to confirm, you are taking about moving the QNX mouse, right?

Is your mouse sharing an interrupt with something else? Like your
network card?

If so, try putting it or the network on a different interrupt.

You are right, it doesn’t happen on Neutrino host.

I have Momentics, Outlook, and Words running on XP, they all work as normal,
except I cannot debug on Momentics, I suspect qconn is not responding. I can
ping to Neutrino, but cannot ftp from any computer to the Neutrino host
because there is no response from Neutrino (ftp shows connect to … and
wait until it times out). Ftp works just fine before the problem occurs. On
Neutrino itself, I can run spin as normal (which I can’t in Phindows unless
I move the mouse around), however I cannot run netstat -an, it just hang
without displaying anything. Looks like I have tcpip problem. I suspect that
I have reached some sort of system limitations, but I just couldn’t figure
out which parameter. Please refer to my other post in this group (Too many
open files) which is related to this problem.

“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:bj7rfm$45a$1@inn.qnx.com

Ah!

I didn’t get that you were running a Phindows screen. I thought from
your original post that you had an IP application running under windows
that was connecting to a QNX server with all of these sockets.

The first question is to determine which computer is hanging, QNX or
Windows. Is anything running on the Windows system besides the
Phindows session?


Johannes <> Jsukamtoh@infolink.co.id> > wrote:
J > It’s Phindows mouse, running on XP. I haven’t tried to move the mouse
on the
J > Neutrino machine yet, but one thing I am sure of is the system stops
J > running.

J > I am not sure about the interrupt. When I install the O/S, it doesn’t
ask
J > for which interrupt to use for the mouse and network, and I used all
the
J > default setting. BTW, how can I check which interrupt used by the
mouse and
J > network card? Any tools?

J > However, I don’t think it is the interrupt that causes the problem
because I
J > notice the problem appears only when the number of opened files (shown
by
J > spin) is approaching 4096. I have tried to create a small program
which
J > keeps on spawning new processes and it worked just fine (over 5000
opened
J > FDs). So my assumption is that the problem is not due to spawning
child
J > process itself, but it is due to the combination of opening file,
sockets,
J > spawning child process, and timer, that my application uses quite a
lot
J > here.

J > I am still not getting the answer from QNX regarding the limitation of
J > Neutrino in term of number of processes, file opened, sockets, timers,
etc.
J > etc. which is not documented anywhere. Why is it so hard to get their
answer
J > on this matter?

J > “Bill Caroselli” <> qtps@earthlink.net> > wrote in message
J > news:bj7dg6$n8e$> 2@inn.qnx.com> …
Johannes <> Jsukamtoh@infolink.co.id> > wrote:
J > I have a device simulator running on Windows which connect via
socket
J > to my
J > application running on Neutrino 6.2.1B. The simulator has
successfully
J > connected up to 81 socket connection (same address but different
port
J > on
J > each connection). Everything works fine until it connects the 82nd
J > connection where the whole system in Neutrino got lock up. And
J > strangely it
J > continues working when I move the mouse and lock up again if I stop
J > the
J > moving the mouse. I have run spin that shows the following
J > information:
J > Mem free: 61%
J > Net en0: < 1 %
J > Threads = 529
J > Total processes = 473
J > Memory = 132m
J > Total FDs = 4296
J > CPU% procnto > 90, spin 4

J > I have to move the mouse cotinuously to get the spin running, and
when
J > I
J > stop the mouse, spin also stops.

J > Looks like we have some interrupt problem here. My processes open a
J > lot of
J > sockets, and I have timer running in almost all processes.

J > Can anyone help me with this problem? Have I reached some system
J > limitation?
J > I have set -F10000 to my procnto.

Sounds like you need one of those wheels to let your mouse keep running
without stopping. ;~}

Just to confirm, you are taking about moving the QNX mouse, right?

Is your mouse sharing an interrupt with something else? Like your
network card?

If so, try putting it or the network on a different interrupt.

Are things SEND blocked on io-net? If so try increasing the ‘threads’
option to the stack:

io-net -ptcpip threads_max=X …

-seanb

Johannes <Jsukamtoh@infolink.co.id> wrote:

You are right, it doesn’t happen on Neutrino host. Both Neutrino and XP are
not hanging, but only the windows on Phindows have the problem. I have
Momentics and Outlook running on XP, but they are both working just fine
when the problem occurs, except that I can’t debug on Momentic, somehow
qconn doesn’t response, and I can’t ftp from any machine to Neutrino, it
doesn’t response at all (ftp shows connected to … and wait). On Neutrino,
I can run spin, (which is not on Phindows unless the mouse is moved), but I
can’t run netstat -an. Looks like tcpip problem to me. I suspect that I have
reached the maximum of something in the O/S, but I couldn’t figure out which
parameter in the O/S. Please refer to my other post in this group (Too many
open files) which may be related to this problem.

Shouldn’t the thread count only affect performance and not cause a
complete hang?


Johannes <Jsukamtoh@infolink.co.id> wrote:
J > Thanks, it works after I increase the thread limit.

J > “Sean Boudreau” <seanb@node25.ott.qnx.com> wrote in message
J > news:bja1jr$59p$1@nntp.qnx.com

Are things SEND blocked on io-net? If so try increasing the ‘threads’
option to the stack:

io-net -ptcpip threads_max=X …

-seanb

Johannes <> Jsukamtoh@infolink.co.id> > wrote:
You are right, it doesn’t happen on Neutrino host. Both Neutrino and XP
J > are
not hanging, but only the windows on Phindows have the problem. I have
Momentics and Outlook running on XP, but they are both working just fine
when the problem occurs, except that I can’t debug on Momentic, somehow
qconn doesn’t response, and I can’t ftp from any machine to Neutrino, it
doesn’t response at all (ftp shows connected to … and wait). On
J > Neutrino,
I can run spin, (which is not on Phindows unless the mouse is moved),
J > but I
can’t run netstat -an. Looks like tcpip problem to me. I suspect that I
J > have
reached the maximum of something in the O/S, but I couldn’t figure out
J > which
parameter in the O/S. Please refer to my other post in this group (Too
J > many
open files) which may be related to this problem.


Bill Caroselli – Q-TPS Consulting
qtps@earthlink.net

Thanks, it works after I increase the thread limit.

“Sean Boudreau” <seanb@node25.ott.qnx.com> wrote in message
news:bja1jr$59p$1@nntp.qnx.com

Are things SEND blocked on io-net? If so try increasing the ‘threads’
option to the stack:

io-net -ptcpip threads_max=X …

-seanb

Johannes <> Jsukamtoh@infolink.co.id> > wrote:
You are right, it doesn’t happen on Neutrino host. Both Neutrino and XP
are
not hanging, but only the windows on Phindows have the problem. I have
Momentics and Outlook running on XP, but they are both working just fine
when the problem occurs, except that I can’t debug on Momentic, somehow
qconn doesn’t response, and I can’t ftp from any machine to Neutrino, it
doesn’t response at all (ftp shows connected to … and wait). On
Neutrino,
I can run spin, (which is not on Phindows unless the mouse is moved),
but I
can’t run netstat -an. Looks like tcpip problem to me. I suspect that I
have
reached the maximum of something in the O/S, but I couldn’t figure out
which
parameter in the O/S. Please refer to my other post in this group (Too
many
open files) which may be related to this problem.

Or at least it tells the user that it has running out of thread allocation.

errno EMFILE is too general since it can mean a lot of things now in
Neutrino.

It would be nice if we have a tool to tell us what is the system limitation
(thread, process, socket, timer, etc. etc.) and how much we have used so
far, just like the memory space and FDs in spin.

“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:bjhu54$a4e$3@inn.qnx.com

Shouldn’t the thread count only affect performance and not cause a
complete hang?


Johannes <> Jsukamtoh@infolink.co.id> > wrote:
J > Thanks, it works after I increase the thread limit.

J > “Sean Boudreau” <> seanb@node25.ott.qnx.com> > wrote in message
J > news:bja1jr$59p$> 1@nntp.qnx.com> …

Are things SEND blocked on io-net? If so try increasing the ‘threads’
option to the stack:

io-net -ptcpip threads_max=X …

-seanb

Johannes <> Jsukamtoh@infolink.co.id> > wrote:
You are right, it doesn’t happen on Neutrino host. Both Neutrino and
XP
J > are
not hanging, but only the windows on Phindows have the problem. I
have
Momentics and Outlook running on XP, but they are both working just
fine
when the problem occurs, except that I can’t debug on Momentic,
somehow
qconn doesn’t response, and I can’t ftp from any machine to Neutrino,
it
doesn’t response at all (ftp shows connected to … and wait). On
J > Neutrino,
I can run spin, (which is not on Phindows unless the mouse is moved),
J > but I
can’t run netstat -an. Looks like tcpip problem to me. I suspect that
I
J > have
reached the maximum of something in the O/S, but I couldn’t figure
out
J > which
parameter in the O/S. Please refer to my other post in this group
(Too
J > many
open files) which may be related to this problem.


\

Bill Caroselli – Q-TPS Consulting
qtps@earthlink.net

Johannes <Jsukamtoh@infolink.co.id> wrote:

Or at least it tells the user that it has running out of thread allocation.

errno EMFILE is too general since it can mean a lot of things now in
Neutrino.

The current resource picture in the stack could be reported to
some utility like netstat but the problem that arises is that
you need a stack thread to process the request. Not much use here.

It would be nice if we have a tool to tell us what is the system limitation
(thread, process, socket, timer, etc. etc.) and how much we have used so
far, just like the memory space and FDs in spin.

“Bill Caroselli” <> qtps@earthlink.net> > wrote in message
news:bjhu54$a4e$> 3@inn.qnx.com> …
Shouldn’t the thread count only affect performance and not cause a
complete hang?

That’s exactly what happens. Socket io messages are held off
until a thread becomes available to process them. You can
interrupt in process requests with a signal. Incoming packets
are still processed (if you were forwarding stuff it wouldn’t
be affected) and timeouts still occur. Non socket operations
aren’t affected.

To contrast with QNX4 (since I believe you have an interest there),
the low thread situation is now recoverable since in process operations
can now be canceled and threads now increase to a specified max.
In QNX4 you could potentially not recover, depending on your input
packet pattern, without restarting the stack and all threads were
created at startup.

-seanb