On 14-Apr-06, at 3:17 PM, Tim Reynolds wrote:
> Thanks for the replies guys.
> Yeah, I know it is fairly unreasonable to run this type of
> simulation. We will figure something out.
Not at all unreasonable. I will do the same very soon, and I want it
to work. I may not use Player when things get very big, as it make so
much use of the network stack (btw, you may find a multi-cpu machine
helps a lot, to reduce context-switch overhead).
One of the two reasons that Stage uses cheap-and-nasty, O(1) models
is so it can scale up a bit. The other reason is left as an exercise
for the reader.
> On 4/14/06, Richard vaughan <vaughan@...> wrote:
> The gui_disable flag is currently not working (which is why it's not
> The connection issue is a Player problem: Stage doesn't know anything
> about connections. 99% of Players have one connection, so I'm not
> surprised that things get a little weird with >900 ! But of course,
> we'd like it to work. The problem is probably due to CPU load an d
> thread scheduling.
> A possible solution is to start Stage paused, then unpause it once
> all the connections are made. That way you could stagger the
> connection requests by a few ms to help it work. This might require a
> teeny Stage hack, but shouldn't be too hard.
> I'll figure this out properly with Brian when I have some time.
> On 14-Apr-06, at 2:48 PM, Toby Collett wrote:
> > Im not sure what the internal sensor models do to calculate their
> > data but you might find it more efficient to run several hundred
> > copies of stage with a few bots in each if there is to be no
> > interaction between them.
> > The gui_disable abort is definately a bug, I will look into it
> > later today if no one has got there first,
> > Toby
> > Tim Reynolds wrote:
> >> Alright, question:
> >> Trying to run Stage without the GUI. gui_disabled 1 causes stage
> >> to crash on an assert. Am I missing something? Googling the site
> >> shows no hits for gui_disable, is this possible?
> >> With a map that is 8000x6000 pixels and 11,000 lines of config
> >> code stage eats roughly 35% of the processor at idle. By setting
> >> the gui-update to 10 seconds it helps once we have bots
> >> connecting, but not enough to get our 900 bots connected.
> >> And yes, I realize this is a really bad idea, however we doubt we
> >> will get the university to allow us to take over 10-20 machines
> >> for this... Though... maybe we could. /shrug.
> >> Thanks
> >> Tim
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > language
> > that extends applications into web and mobile media. Attend the
> > live webcast
> > and join the prime developer group breaking into this new coding
> > territory!
> > http://sel.as-us.falkag.net/sel?
> > cmd=lnk&kid=110944&bid=241720&dat=121642
> > _______________________________________________
> > Playerstage-users mailing list
> > Playerstage-users@...
> > https://lists.sourceforge.net/lists/listinfo/playerstage-users
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> that extends applications into web and mobile media. Attend the
> live webcast
> and join the prime developer group breaking into this new coding
> Playerstage-users mailing list