CHANNELCNT warning - is it valid?

CHANNELCNT warning - is it valid?

Post by Bradford J. Hamilt » Tue, 01 Jul 2003 07:36:19



Folks,

Doc's recent question re: CHANNELCNT have brought up a question I've been
meaning to ask.

SYSGEN sez:

$ mcr sysgen help sys chann

Sys_Parameters

  CHANNELCNT

       CHANNELCNT specifies the number of permanent I/O channels
       available to the system.

       This special parameter is used by Compaq and is subject to
       change. Do not change this parameter unless Compaq recommends
       that you do so.

Aside from changing CHANNELCNT under recommendation from hp or a third-party
software vendor, is there a good reason to leave CHANNELCNT alone?  Is this
warning a remnant from an earlier time, or is it still valid?

_________________________________________________________________
Bradford J. Hamilton                    "All opinions are my own"
bMradAhamiPltSon-at-atMtAbi.cPoSm       "Lose the MAPS, and replace

 
 
 

CHANNELCNT warning - is it valid?

Post by Larry Kilgall » Tue, 01 Jul 2003 08:32:59



Quote:> Aside from changing CHANNELCNT under recommendation from hp or a third-party
> software vendor, is there a good reason to leave CHANNELCNT alone?  Is this
> warning a remnant from an earlier time, or is it still valid?

I would not hesitate to raise it on an end user system.

Lowering it might mean some programs built with higher expectations would fail.

Raising it on an ISV system might lead to unwarranted expectations of a higher
value on customer systems.

 
 
 

CHANNELCNT warning - is it valid?

Post by David Frobl » Tue, 01 Jul 2003 13:54:00



> Folks,

> Doc's recent question re: CHANNELCNT have brought up a question I've been
> meaning to ask.

> SYSGEN sez:

> $ mcr sysgen help sys chann

> Sys_Parameters

>   CHANNELCNT

>        CHANNELCNT specifies the number of permanent I/O channels
>        available to the system.

>        This special parameter is used by Compaq and is subject to
>        change. Do not change this parameter unless Compaq recommends
>        that you do so.

> Aside from changing CHANNELCNT under recommendation from hp or a third-party
> software vendor, is there a good reason to leave CHANNELCNT alone?  Is this
> warning a remnant from an earlier time, or is it still valid?

> _________________________________________________________________
> Bradford J. Hamilton                       "All opinions are my own"
> bMradAhamiPltSon-at-atMtAbi.cPoSm  "Lose the MAPS, and replace


Well, it's a maximum.  There's no rule that says the system has to use as many
channels as it's allowed to.  The individual processes are limited by the SYSUAF
data.  Setting CHANNELCNT to some ridiculously high value should not hurt a
system, however, it might wreck havoc with AUTOGEN.

If you think there is a problem, collect FEEDBACK often.  The report will tell
you the highest usage of many things.  AUTOGEN should bump the parameter if it
sees any need to do so.

Disclaimer, I don't know how AUTOGEN uses and modifies CHANNELCNT, the above is
just from experience, not intimate knowledge of AUTOGEN.

I have seen advice, from DEC, to set CHANNELCNT very high, 64,000 I believe, to
allow a BACKUP user account to make maximum useage of resources.

Dave

--
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      Fax: 724-529-0596

T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486

 
 
 

CHANNELCNT warning - is it valid?

Post by Nic Clew » Tue, 01 Jul 2003 18:50:25



>   CHANNELCNT

>        CHANNELCNT specifies the number of permanent I/O channels
>        available to the system.

> Aside from changing CHANNELCNT under recommendation from hp or a third-party
> software vendor, is there a good reason to leave CHANNELCNT alone?  Is this
> warning a remnant from an earlier time, or is it still valid?

CHANNELCNT is a per process restriction for all processes system wide,
further limited by the FILLM setting per process. A FILLM must never be
bigger than CHANNELCNT + 15. Well it can, just odd things happen. (Never
seen it really cause grief).

The overhead in P1 (pageable) space is 16 bytes per BALSETCNT process on
a VAX, and 32 bytes on Alpha. Multiply the figures up to whatever
CHANNELCNT is to see what the memory overhead is.

You've had suggestions where it can help. Some areas are a little more
subtle. e.g. the linker, if you are linking more discrete modules
together than your FILLM, you can improve your performance a little.
(Observed on Alpha). However after that episode, the linking process was
redesigned (after some readers here *on their coffee).
--
Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences
nclews at csc dot com

 
 
 

CHANNELCNT warning - is it valid?

Post by Michael Moron » Tue, 01 Jul 2003 19:31:14



Quote:>Aside from changing CHANNELCNT under recommendation from hp or a third-party
>software vendor, is there a good reason to leave CHANNELCNT alone?  Is this
>warning a remnant from an earlier time, or is it still valid?

I'm going to guess it's a warning from the days when memory was expensive
and limited, as most likely memory is consumed at the rate of (N bytes
of nonpaged pool) times (number of potential channels) times (number of
active processes).  It may be there is a loop through all potential
channels to clean things up so that increasing channels unnecessarily
may slow something down unnecessarily.
--
-Mike
 
 
 

CHANNELCNT warning - is it valid?

Post by Bob Koehl » Tue, 01 Jul 2003 22:39:55



> Well, it's a maximum.  There's no rule that says the system has to use as many
> channels as it's allowed to.  The individual processes are limited by the SYSUAF
> data.  Setting CHANNELCNT to some ridiculously high value should not hurt a
> system, however, it might wreck havoc with AUTOGEN.

   Actually there is memeory reserved for all those channels.  On
   todays' systems that's not a terrible big lot of memory, but
   it's worth a few seconds' thought before cranking it up to
   insanely large values.
 
 
 

CHANNELCNT warning - is it valid?

Post by Rob You » Wed, 02 Jul 2003 00:53:36




>>   CHANNELCNT

>>        CHANNELCNT specifies the number of permanent I/O channels
>>        available to the system.

>> Aside from changing CHANNELCNT under recommendation from hp or a third-party
>> software vendor, is there a good reason to leave CHANNELCNT alone?  Is this
>> warning a remnant from an earlier time, or is it still valid?

> CHANNELCNT is a per process restriction for all processes system wide,
> further limited by the FILLM setting per process. A FILLM must never be
> bigger than CHANNELCNT + 15. Well it can, just odd things happen. (Never
> seen it really cause grief).

> The overhead in P1 (pageable) space is 16 bytes per BALSETCNT process on
> a VAX, and 32 bytes on Alpha. Multiply the figures up to whatever
> CHANNELCNT is to see what the memory overhead is.

> You've had suggestions where it can help. Some areas are a little more
> subtle. e.g. the linker, if you are linking more discrete modules
> together than your FILLM, you can improve your performance a little.
> (Observed on Alpha). However after that episode, the linking process was
> redesigned (after some readers here *on their coffee).

        As another data point, you can scour the web and find various
        CHANNELCNT recommendations.  The one for NetBearns on OpenVMS
        recommends raising CHANNELCNT to 2000.

http://www.veryComputer.com/

The recommended SYSGEN values are:

CHANNELCNT  at least 2000

WSMAX       at least the value of WSEXTENT

        There are backup tuning articles in DSNlink.  Recommend
                FILLM = CHANNELCNT - 15
        Where FILLM is your UAF setting for backup account.

        I've set Channelcnt to 2000 or so, when bored I watch to
        see how many channels are open on backup.  Rarely more than
        a couple dozen.

                                Rob

 
 
 

1. POP Mail Troubles - Am I who I really say I am?

Background -  I have a VAX/VMS 4600 running VMS 5.5, Multinet, and PMDF.

Problem - Basically we're having trouble with students using programs like
Eudora on our public machines to send notes to others by configuring Eudora
so that their mail looks like it's from someone who it really isn't from.
While looking at the headers we can tell where the mail was sent from but
anyone could have been using that machine since it is public.

Solutions? - I'm wondering what anyone else is doing about this problem.  

Idea - I don't need people to be able to send mail from the public
computers using Eudora.  Is there a way I can put all private computers in
my DNS and have the SMTP server on my VAX check with DNS before delivering
mail and refuse to deliver any local mail that it didn't find in DNS
tables?

More ideas?

Thanks in advance.  I'm not on info-vax.  I will summarize to the lists.

Sue Chichester  
*******************************************************
SUNY Geneseo             Systems & Network Manager

1 College Cirle          Phone: (716) 245-5577                      
Geneseo, NY 14454        FAX:   (716) 245-5579    

2. aspppls problem in Solaris 2.3

3. Summary: POP Mail Troubles - Am I who I really say I am

4. RJ-45 vs. Patch studies

5. CHANNELCNT question

6. Recurring ToDos

7. CHANNELCNT Usage?

8. epson 680 first impression

9. CHANNELCNT=65532 ?

10. RMS-F-CHN and CHANNELCNT

11. CHANNELCNT question

12. CHANNELCNT and DECnet links

13. Is there a relationship between MAXBOBMEM and CHANNELCNT?