On 4/14/08, Andrew Campbell <[EMAIL PROTECTED]> wrote: > > If the macholib problem you got was unknown command 27 then its an old > bug that's fixed in svn. The release version of macholib and family > hasnt been updated in a year despite several important fixes in svn. >
That was one of them, but it _wasn't_ fixed in svn. There was also another unknown LC that I needed to fill in. Alex. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~9.patch > > > In today's logic of finding a new task, we assign only one task per heartbeat. > We probably could give the tasktracker multiple tasks subject to the max > number of free slots it has - for maps we could assign it data local tasks. > We could probably run some logic to decide what to give it if we run out of > data local tasks (e.g., tasks from overloaded racks, tasks that have least > locality, etc.). In addition to maps, if it has reduce slots free, we could > give it reduce task(s) as well. Again for reduces we could probably run some > logic to give more tasks to nodes that are closer to nodes running most maps > (assuming data generated is proportional to the number of maps). For e.g., if > rack1 has 70% of the input splits, and we know that most maps are data/rack > local, we try to schedule ~70% of the reducers there. > Thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
