ken@gvax.cs.cornell.edu (Ken Birman) (08/16/90)
We have had a few queries about the reduction on the total number of
processes + clients in a group from 125 to 29...
1) These values are controlled by a parameter you can change when building
the system: in protos/pr_pgroups.h
PG_ALEN (max. number of members + clients) + 3
PG_ALEN used to be 128 and was reduced to 32 for performance reasons.
You can certainly change it back to 128 or even a larger number.
2) Performance can be expected to degrade if a group actually has a large
number of members/clients. My guess is that 32 is a practical limit
with BYPASS enabled and that 128 is a practical limit with BYPASS
disabled.
In the future, this limit will NOT apply to the number of clients that
use pg_client(). I.e. you will be able to have a group with 2 members
and 200 clients, and it will work fine with BYPASS mode.
3) Recommendations:
a) structure systems hierarchically if the number of "servers" really
needs to be large.
b) plan to use pg_client() in the future
c) meanwhile, if this is a problem for you, recompile with a larger
value of PG_ALEN and with BYPASS disabled.
Regarding the number of sites in the system: the effective limit on this
is currently around 100 "primary" sites if you use isis_remote and MAX_SITES
(127) sites if you never use isis_remote. There is no built-in limit on the
number of remote sites, so we could probably support 1000 sites now,
provided that each cluster of 10 or 20 has a single "primary" site in it.
In principle, MAX_SITES could be pushed to 254, but I wouldn't be surprised
if this kicks off some sort of sign-extend bug that would need to be fixed
first (we sometimes represent site-numbers in a single character). Any
such problem would be minor.
The problem with having big sites files when using isis_remote is that
the site_names array is shipped at client registration time using a UDP
packet. We plan to change this to use our streams code, but in the mean
time you are limited by the maximum size of packet that UDP will accept,
namely 8k. Actually, the site_names array is full of air and could be
compressed too, so there are two obvious ways to reduce this cost. And,
in fact, almost nothing in ISIS actually wants to see this array up in
client-land, so we could probably dispense with shipping it completely.
But, in ISIS V2.1, we do ship it and this poses a size problem...
Ken