Hello Andy,
Thanks for the explainations. Right, a quick code
browsing and your Mask << operation + code layout and var
type check explains the 64 limit as well.
We are definitely interrested in the coming version
with auto-config and infinite number of nodes support. Anything
we can do to help ??
In the mean time, will persue with a restricted
deployement or a tree architecture (cutting the namespace
does not work out, the 190 nodes are almost identical and
there are no reasons / no boundaries for cutting the
datatasets in 64 bundles).
Andrew Hanushevsky wrote:
> Hi Jerome,
>
> ----- Original Message -----
> From: "Jerome LAURET" <[log in to unmask]>
> To: "Peter Elmer" <[log in to unmask]>
>
>>[...]
>>
>>> At the moment you can build a hierarchy where each group of 64 has
>>>a redirector and then those subscriber to a meta-redirector. What Andy
>>
>>OK, we will look into this.
>
> No need, see my previous mail file.
>
>
>>What is the reasonning behind the 64 limit ?? I have not
>>looked at the source code and wondering if this is a low level
>>limitation or a simple hard-coded choice ??
>
> You will have to read our paper that we are writing submitting to the
> Intellegent Agent Technology Symposium. The reason for the limit is that the
> system has to scale and it can't do that if the cell size (i.e., the nodes
> that technically know about each other) is too large. Even 64 is stretching
> it a bit but it worked out to be a convenient number for efficiently
> performing bit vector operations (and we do quite a bit of those in the olbd
> :-). It was my intenetion all along to allow you to stack cells of olbd's
> together and the architectural elements are there to do that. I just didn't
> put it all in to keep the complexity down while we were deploying the system
> in production (i.e., use the simple stuff first).
>
> Andy
--
,,,,,
( o o )
--m---U---m--
Jerome
|