 |
 |
Hi Jerome, Hmmm, I don't think you will be completely successful in doing a tree with the way things stand at the moment. I don't immediately see how one could externally lash together a uniform name space without the new olbd (though I would be interested in hearing your proposal). Anyway, having a place where we can actually deploy 190 nodes would be a great help (at the moment I have to artificially limit things two 2 nodes max). There are actually quite a few things that could expedite the process. For one, integrating the IN2P3 rfio interface to Mass Storage via the mps scripts would eliminate the time I need to devote to that effort. There are likely other things that need to be done. The sky is the limit so to speak. Andy On Tue, 22 Feb 2005, Jerome LAURET wrote: > > 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 >