qnx_vc_*

QNX Newsgroups (Archives) qdn.public.qnx4
1

I have a number of nodes that talk to each other through VCs. I also have a
UDP watchdog that informs me of nodes joining the network or leaving the
network.

The problem exists when a process has a VC with another device and it tries
to Send() to that VID before it gets a message from the UDP watchdog. The
Send() waits for ~4 seconds and then timesout. 4 seconds is too long.

Is there a way to either quickly refresh the status of the VC before sending
or reduce the timeout to .5-1 second?

Will qnx_vc_poll_parm do this?

Any help is appreciated.

Doug

2

Doug Rixmann <rixmannd@rdsdata.com> wrote:

I have a number of nodes that talk to each other through VCs. I also have a
UDP watchdog that informs me of nodes joining the network or leaving the
network.

The problem exists when a process has a VC with another device and it tries
to Send() to that VID before it gets a message from the UDP watchdog. The
Send() waits for ~4 seconds and then timesout. 4 seconds is too long.

Is there a way to either quickly refresh the status of the VC before sending
or reduce the timeout to .5-1 second?

Look at the netpoll utility.

Look at the Net.driver -t and -n parameters.

Will qnx_vc_poll_parm do this?

It will do, essentially, the same things that the netpoll utility
will do. Not that this is NOT per-vc, it is a configuration for
vc polling on your (or another) node.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

3

Ok, thanks. So now I’ve done the qnx_vc_poll_parm and set the options as
follows:
poll_parm.poll_period = 1;
poll_parm.idle_time = 1;
poll_parm.max_idle_time = 600;
poll_parm.num_polls = 1;
poll_parm.num_qpkts = 255;
poll_parm.zero1 = 0;
poll_parm.zero2 = 0;

Everything is working ok now… can anyone see an issue with this?

Doug

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:aommv1$eb3$4@nntp.qnx.com…

Doug Rixmann <> rixmannd@rdsdata.com> > wrote:
I have a number of nodes that talk to each other through VCs. I also
have a
UDP watchdog that informs me of nodes joining the network or leaving the
network.

The problem exists when a process has a VC with another device and it
tries
to Send() to that VID before it gets a message from the UDP watchdog.
The
Send() waits for ~4 seconds and then timesout. 4 seconds is too long.

Is there a way to either quickly refresh the status of the VC before
sending
or reduce the timeout to .5-1 second?

Look at the netpoll utility.

Look at the Net.driver -t and -n parameters.

Will qnx_vc_poll_parm do this?

It will do, essentially, the same things that the netpoll utility
will do. Not that this is NOT per-vc, it is a configuration for
vc polling on your (or another) node.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

4

It should be noted that increasing the aggressiveness of the poll period may
cause other problems on your network. You’re now sending poll messages out
faster, and you’re potentially ripping out VC’s which have idled out
artifically. On a busy network, this just adds to the problem and does not
solve it.

–

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

Doug Rixmann <rixmannd@rdsdata.com> wrote in message
news:aopebo$lsh$1@inn.qnx.com…

Ok, thanks. So now I’ve done the qnx_vc_poll_parm and set the options as
follows:
poll_parm.poll_period = 1;
poll_parm.idle_time = 1;
poll_parm.max_idle_time = 600;
poll_parm.num_polls = 1;
poll_parm.num_qpkts = 255;
poll_parm.zero1 = 0;
poll_parm.zero2 = 0;

Everything is working ok now… can anyone see an issue with this?

Doug

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:aommv1$eb3$> 4@nntp.qnx.com> …
Doug Rixmann <> rixmannd@rdsdata.com> > wrote:
I have a number of nodes that talk to each other through VCs. I also
have a
UDP watchdog that informs me of nodes joining the network or leaving
the
network.

The problem exists when a process has a VC with another device and it
tries
to Send() to that VID before it gets a message from the UDP watchdog.
The
Send() waits for ~4 seconds and then timesout. 4 seconds is too long.

Is there a way to either quickly refresh the status of the VC before
sending
or reduce the timeout to .5-1 second?

Look at the netpoll utility.

Look at the Net.driver -t and -n parameters.

Will qnx_vc_poll_parm do this?

It will do, essentially, the same things that the netpoll utility
will do. Not that this is NOT per-vc, it is a configuration for
vc polling on your (or another) node.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

5

Actually, I’ve seen this. What I am seeing now is that I have an abundance
of zombie processes. Would decreasing the max_idle_time do this?


“Adam Mallory” <amallory@qnx.com> wrote in message
news:aopn1h$dig$1@nntp.qnx.com…

It should be noted that increasing the aggressiveness of the poll period
may
cause other problems on your network. You’re now sending poll messages
out
faster, and you’re potentially ripping out VC’s which have idled out
artifically. On a busy network, this just adds to the problem and does
not
solve it.

–

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

Doug Rixmann <> rixmannd@rdsdata.com> > wrote in message
news:aopebo$lsh$> 1@inn.qnx.com> …
Ok, thanks. So now I’ve done the qnx_vc_poll_parm and set the options as
follows:
poll_parm.poll_period = 1;
poll_parm.idle_time = 1;
poll_parm.max_idle_time = 600;
poll_parm.num_polls = 1;
poll_parm.num_qpkts = 255;
poll_parm.zero1 = 0;
poll_parm.zero2 = 0;

Everything is working ok now… can anyone see an issue with this?

Doug

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:aommv1$eb3$> 4@nntp.qnx.com> …
Doug Rixmann <> rixmannd@rdsdata.com> > wrote:
I have a number of nodes that talk to each other through VCs. I also
have a
UDP watchdog that informs me of nodes joining the network or leaving
the
network.

The problem exists when a process has a VC with another device and
it
tries
to Send() to that VID before it gets a message from the UDP
watchdog.
The
Send() waits for ~4 seconds and then timesout. 4 seconds is too
long.

Is there a way to either quickly refresh the status of the VC before
sending
or reduce the timeout to .5-1 second?

Look at the netpoll utility.

Look at the Net.driver -t and -n parameters.

Will qnx_vc_poll_parm do this?

It will do, essentially, the same things that the netpoll utility
will do. Not that this is NOT per-vc, it is a configuration for
vc polling on your (or another) node.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
\

6

No, that just specifies the amount of time a VC can ever be idle before
being ripped out.

What exactly does a node leaving the network entail? Where are the zombies?
Local or remote node?

Why not querry the amount of time since the last watch dog, before sending
and then if it’s been “a while” force a watchdog poll.

Or make some type of lower level node poll at the ethernet level.

–

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>


Doug Rixmann <rixmannd@rdsdata.com> wrote in message
news:aopn89$2eu$1@inn.qnx.com…

Actually, I’ve seen this. What I am seeing now is that I have an abundance
of zombie processes. Would decreasing the max_idle_time do this?


“Adam Mallory” <> amallory@qnx.com> > wrote in message
news:aopn1h$dig$> 1@nntp.qnx.com> …

It should be noted that increasing the aggressiveness of the poll period
may
cause other problems on your network. You’re now sending poll messages
out
faster, and you’re potentially ripping out VC’s which have idled out
artifically. On a busy network, this just adds to the problem and does
not
solve it.

–

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

Doug Rixmann <> rixmannd@rdsdata.com> > wrote in message
news:aopebo$lsh$> 1@inn.qnx.com> …
Ok, thanks. So now I’ve done the qnx_vc_poll_parm and set the options
as
follows:
poll_parm.poll_period = 1;
poll_parm.idle_time = 1;
poll_parm.max_idle_time = 600;
poll_parm.num_polls = 1;
poll_parm.num_qpkts = 255;
poll_parm.zero1 = 0;
poll_parm.zero2 = 0;

Everything is working ok now… can anyone see an issue with this?

Doug

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:aommv1$eb3$> 4@nntp.qnx.com> …
Doug Rixmann <> rixmannd@rdsdata.com> > wrote:
I have a number of nodes that talk to each other through VCs. I
also
have a
UDP watchdog that informs me of nodes joining the network or
leaving
the
network.

The problem exists when a process has a VC with another device and
it
tries
to Send() to that VID before it gets a message from the UDP
watchdog.
The
Send() waits for ~4 seconds and then timesout. 4 seconds is too
long.

Is there a way to either quickly refresh the status of the VC
before
sending
or reduce the timeout to .5-1 second?

Look at the netpoll utility.

Look at the Net.driver -t and -n parameters.

Will qnx_vc_poll_parm do this?

It will do, essentially, the same things that the netpoll utility
will do. Not that this is NOT per-vc, it is a configuration for
vc polling on your (or another) node.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.


\

7

Doug Rixmann <rixmannd@rdsdata.com> wrote:

Ok, thanks. So now I’ve done the qnx_vc_poll_parm and set the options as
follows:
poll_parm.poll_period = 1;
poll_parm.idle_time = 1;
poll_parm.max_idle_time = 600;
poll_parm.num_polls = 1;
poll_parm.num_qpkts = 255;
poll_parm.zero1 = 0;
poll_parm.zero2 = 0;

Everything is working ok now… can anyone see an issue with this?

If you have network instabilities, they will more quickly be treated
as errors… instead of recovered from.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

8

Actually, I’ll suggest something different: I’m an idiot. Somehow the
changes I have made in the vc_poll_parm is affecting another module… it
isn’t the vc’s that are creating the zombie’s it’s something else.

Thanks for your help. I did learn lots from this thread (other than the
previously stated).


“Adam Mallory” <amallory@qnx.com> wrote in message
news:aopodc$e9a$1@nntp.qnx.com…

No, that just specifies the amount of time a VC can ever be idle before
being ripped out.

What exactly does a node leaving the network entail? Where are the
zombies?
Local or remote node?

Why not querry the amount of time since the last watch dog, before sending
and then if it’s been “a while” force a watchdog poll.

Or make some type of lower level node poll at the ethernet level.

–

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net


Doug Rixmann <> rixmannd@rdsdata.com> > wrote in message
news:aopn89$2eu$> 1@inn.qnx.com> …
Actually, I’ve seen this. What I am seeing now is that I have an
abundance
of zombie processes. Would decreasing the max_idle_time do this?


“Adam Mallory” <> amallory@qnx.com> > wrote in message
news:aopn1h$dig$> 1@nntp.qnx.com> …

It should be noted that increasing the aggressiveness of the poll
period
may
cause other problems on your network. You’re now sending poll
messages
out
faster, and you’re potentially ripping out VC’s which have idled out
artifically. On a busy network, this just adds to the problem and
does
not
solve it.

–

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

Doug Rixmann <> rixmannd@rdsdata.com> > wrote in message
news:aopebo$lsh$> 1@inn.qnx.com> …
Ok, thanks. So now I’ve done the qnx_vc_poll_parm and set the
options
as
follows:
poll_parm.poll_period = 1;
poll_parm.idle_time = 1;
poll_parm.max_idle_time = 600;
poll_parm.num_polls = 1;
poll_parm.num_qpkts = 255;
poll_parm.zero1 = 0;
poll_parm.zero2 = 0;

Everything is working ok now… can anyone see an issue with this?

Doug

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:aommv1$eb3$> 4@nntp.qnx.com> …
Doug Rixmann <> rixmannd@rdsdata.com> > wrote:
I have a number of nodes that talk to each other through VCs. I
also
have a
UDP watchdog that informs me of nodes joining the network or
leaving
the
network.

The problem exists when a process has a VC with another device
and
it
tries
to Send() to that VID before it gets a message from the UDP
watchdog.
The
Send() waits for ~4 seconds and then timesout. 4 seconds is too
long.

Is there a way to either quickly refresh the status of the VC
before
sending
or reduce the timeout to .5-1 second?

Look at the netpoll utility.

Look at the Net.driver -t and -n parameters.

Will qnx_vc_poll_parm do this?

It will do, essentially, the same things that the netpoll utility
will do. Not that this is NOT per-vc, it is a configuration for
vc polling on your (or another) node.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.




\