re: penalty option, this is where the dynamic penalty option of ryo worked so well.
Ha, I guess I don't trust anything I don't understand... I found for non-prop pools or delayed pools, dynamic penalty would push those quite low and I felt like I was mining unprofitable pools quite often. Oh well, in anycase, hopefully I'll have time to port it over, but not sure how well I can test it.
I think I'm secretly hoping Ryouiki or someone else will take the plunge, I just set the stage by extracting out most of the "scheduling" code
I just added a new LP system and a slice scheduler similar to flowers. New lp is on by default. Scheduler uses --scheduler SliceScheduler
Oh and ryou's dynamic penalty doesn't conflict with my code. Its just another item that needs to get added.
Oh and ryou's dynamic penalty doesn't conflict with my code. Its just another item that needs to get added.
From a project management perspective, I'd recommend letting ryo finish integrating slicing into his fork (which he's working on now, I believe) and then merge it all in together. He's doing time based, multi-threshold with dynamic penalty now and it will be all that including slicing when complete. Seems like merging the complete package would be easier than making it fit into another slicing implementation. Just my two bits.
After the last day of slicing eating everyone's lunch I would just reiterate that Ryo is working on getting slicing integrated into his fork. Let him do the work and then merge commit it.