On Tue, Sep 22, 2009 at 07:48:44AM -0400, Robert Rutherford wrote:
> Hi All,
> 
> Maybe someone can help with the following questions, which don't seem to be covered in any depth in the documentation.

> 
> All relate to 6.3.2A and a quad-core x86 system with 4GB of RAM and thousands of simultaneous TCP/IP connections over 
3 different NICs (all Intel 82544).
> 
> What does the io-net command-line argument "-t threads" actually mean?

It's the size of the thread pool in io-net.  This affects
protocol modules that use io-net's dispatch context like
the tiny stack (npm-ttcpip.so).  The full stack uses its
own rather than io-net's.

> What are the implications of having it too large/too small?

If you're not using the tiny stack the defaults should be
fine.

> How does it relate/interact with the threads_max option for npm-tcpip-v4.so? 

It doesn't.  The 'threads*" options to npm-tcpip* really
refers to the number of possible co-routines therein.
'threads' is really a misnomer that got inherited from the
qnx4 days.

> Does threads_max for npm-tcpip.so need to be at least as large as the -t threads option for io-net?

No.

> Why/when would you play with the stacksize=X option to npm-tcpip-v4.so? Is it only to reduce footprint for small 
systems? Is there value in making it larger?

Really only if you've got a driver or some codepath in
npm-tcpip.so that's too stack hungry (probably a bug).
The stack will generally put a message in the sloginfo
it detects this.

> Why/when would you play with the recv_ctxt=X option to npm-tcpip-v4.so?

This the size of the message that can be handled up front
without doing a MsgRead() to get more.  It's a performance
tuning parameter.

> 
> Thanks in advance,
> 
> Rob Rutherford
> Ruzz TV
> 
> 
> 
> _______________________________________________
> 
> General
> http://community.qnx.com/sf/go/post38463
>