Pages:
Author

Topic: [ANN][MOTO] Motocoin - page 45. (Read 178225 times)

sr. member
Activity: 434
Merit: 250
August 24, 2014, 10:20:34 AM
Fell asleep on the keyboard.  Grin

Will push a new patch in a moment, removing the path time count and using the correct endx2.  (I'll have to check later if the work measurement was done with the correct endx2 or not, but with the way I've been doing work measurements now I don't expect it will make much impact on the result either way.)

There also appears to be a small memory leak in the path check which I thought I had already fixed but will apparently need to dig a little more on.  I wouldn't hold off on releasing a test build because of it (it only leaks a few bytes per map generation, so it shouldn't be too much trouble for anyone) but we will certainly need to chase it down eventually.

EDIT: first patch pushed.  I'll have to be afk for a couple of hours now, but will be working on chasing down the leak and continuing with gitian when I return.
newbie
Activity: 49
Merit: 0
August 24, 2014, 06:41:00 AM
Cool! Can't wait for binaries!

PS.

Meanwhile, I've downloaded the source code cause I was curious how path searching was implemented.

I'm barely a programmer but maybe endX2 should be used in this line?

Code:
path_head2 = findPath(&newgrid, startX, startY, endX, endY, &score2);
full member
Activity: 204
Merit: 100
August 24, 2014, 02:22:38 AM
Windows build:
Code:
src/moto-engine.cpp: In function ‘int getPathLen(MotoWorld*)’:
src/moto-engine.cpp:574:2: error: ‘clock_t’ was not declared in this scope
src/moto-engine.cpp:574:10: error: expected ‘;’ before ‘c0’
src/moto-engine.cpp:628:2: error: ‘c0’ was not declared in this scope
src/moto-engine.cpp:628:13: error: ‘clock’ was not declared in this scope
src/moto-engine.cpp:650:2: error: ‘c1’ was not declared in this scope
src/moto-engine.cpp:651:40: error: ‘CLOCKS_PER_SEC’ was not declared in this scope
sr. member
Activity: 434
Merit: 250
August 23, 2014, 10:59:46 PM
This also requires maps to have a shortest distance path that is above average.  This rules out the "easiest" half of maps, and in particular most any map which a bot would iterate to search for.  There is now very little advantage in iterating more than a few maps, on the same scales as what a human would iterate.
I don't actually see it, am I missing something?
motoCheck uses motoGenerateWorld and in motoGenerateWorld there is no check for shortest path length.

Eep, good catch!  I'll fix that up right away.

EDIT: got pulled away for a bit, but this change is on github now
full member
Activity: 204
Merit: 100
August 23, 2014, 10:55:22 PM
This also requires maps to have a shortest distance path that is above average.  This rules out the "easiest" half of maps, and in particular most any map which a bot would iterate to search for.  There is now very little advantage in iterating more than a few maps, on the same scales as what a human would iterate.
I don't actually see it, am I missing something?
motoCheck uses motoGenerateWorld and in motoGenerateWorld there is no check for shortest path length.
full member
Activity: 204
Merit: 100
August 23, 2014, 10:29:36 PM
Gitian is being difficult, so I'm still working on binaries.  (If someone else could build and give me the hash for reference that might be helpful.)
I'm running gitian right now
sr. member
Activity: 434
Merit: 250
August 23, 2014, 08:31:29 PM
(Of course the biggest news here is in-between the lines.  The chain is now able to make blocks again, TT is reset to 60 seconds, and bots are entirely offline right now. This makes for (possibly rare) opportunity to mine by hand again. GO GO GO!)
sr. member
Activity: 434
Merit: 250
August 23, 2014, 08:28:47 PM
Here goes nothing.

https://github.com/motocoin-dev/motocoin/commit/fe572e0b6a9542473f034791c060a1431b600555
Quote
Fixes, Formatting cleanups
  Previously planned hard fork adjusted to occur right now!
    (After stalled block 177107)
  Work curve measurements implemented in GetBlockWork
  Block height now passed in work structure to motogame
  Maps now have a minimum shortest path length requirement
  Map filter disabled
  Added -DHEADLESS build option to motogame
  Normalized most indentation

It is not tested much, but I've at least resolved any major issues that I'm aware of.  I'm sure there are more bugs, particularly since I'm operating with very little sleep.

Gitian is being difficult, so I'm still working on binaries.  (If someone else could build and give me the hash for reference that might be helpful.)

These patches include both warp attack fixes, and a work curve that is more accurate and shouldn't overflow any time soon.  Wink

This also requires maps to have a shortest distance path that is above average.  This rules out the "easiest" half of maps, and in particular most any map which a bot would iterate to search for.  There is now very little advantage in iterating more than a few maps, on the same scales as what a human would iterate.

Because it would conflict with the new map requirement, the default map filter has been set to NONE.  I wouldn't suggest changing it, now.  If no-one has a good reason otherwise I'll remove these filters later.

(Until this version gets tested some and the chain is solidly resumed, I'd consider this something of a beta test release version.)

The new GetBlockWork looks up the curve in a constant table, defined by
Code:
int64_t work_a = 9950;
int64_t work_k = 939600000;
int64_t work_b = 14560;
cout << (int32_t)(work_k/(1+exp((log(81)/-work_a)*(i-work_b))));

This is certainly a "weak" estimate.  I'm also still going back and forth on if/how the deficit work should be accounted for.  I've erred toward caution, and made only the minimal change that is necessary for mining to resume right now.

Suggestions for improvements would be appreciated.

sr. member
Activity: 434
Merit: 250
August 23, 2014, 10:59:05 AM
Thank you for answering, but don't you  worry the moto will be remove from the c-cex due to no transactions?

It is a concern, but there would be little reason for it to happen unless the chain remains stalled.  The situation doesn't compromise the security of the network or the integrity of the history, so there's not much harm that can come of it other than the tx processing, itself, being stalled.

Quote
How long the solution will take?

I'm cleaning up the code now, and working on getting Gitian running again.

Quote
I am so surprised that some orders on c-cex take over now when the chain is stucked.

Same thing happened with nodecoin recently, but they aren't even on an exchange yet!  People were just trading wallet passwords on the stuck chain.  It was quite surprising.
newbie
Activity: 6
Merit: 0
August 23, 2014, 10:18:16 AM
Thank you for answering, but don't you  worry the moto will be remove from the c-cex due to no transactions? How long the solution will take? I am so surprised that some orders on c-cex take over now when the chain is stucked.
sr. member
Activity: 434
Merit: 250
August 23, 2014, 09:57:04 AM
Hi all!

Hi!

Quote
I cannot download blocks after 177107, is it a common problem? Is if the finish of moto?

The chain has been stuck for a couple of days because of a rather obscure bug, which (along with a few other things) is being fixed now.

Quote
What have you decided? To launch a new cc like moto or make a release of new wallet?

Both!  Cool
newbie
Activity: 6
Merit: 0
August 23, 2014, 09:53:01 AM
Hi all!

I cannot download blocks after 177107, is it a common problem? Is if the finish of moto?

What have you decided? To launch a new cc like moto or make a release of new wallet?
sr. member
Activity: 434
Merit: 250
August 23, 2014, 09:39:17 AM
Nearly there.  Here are some plots, same layout as the ones posted earlier.


Auto-regressive fit of logistic curve of bot work against new network configuration, with a growth curve transform also shown.



Principle Components regression over the same data-set, almost exactly the same resultant curve, with residuals.


Statistically, this is seemingly a much better curve fit than the last plots I posted.  Although this round of measurement goes much further down on TT, under more difficult conditions, the data-set is also much smaller and generally more constrained.  We'll take better measurements in the future, but this should do for now to get the chain moving again.

I'll be setting up the appropriate values in GetBlockWork and then I think we can go ahead on to Gitian builds soon.
sr. member
Activity: 434
Merit: 250
August 22, 2014, 12:19:19 PM
Sounds great!

At 30 second TT, the best performing general solver (still the "MLSL" based search) averages just under 5 minutes per solution, with a single ~2ghz core behind it.

It's a little worrying though. Just a few more cores and we're in trouble again.

First, this is 5 minutes "without any competition".  Second, adding more cores doesn't scale the solution time 1:1 now, as it did previously, because map search is naturally "embarrassingly parallel" but traversal solving will almost always have a sub-linear gain from parallelism.

In any case, this "well people can just throw more hardware" argument is perpetually true, for any coin.  Don't forget that we'll also have the hashing work scale as well, so we will never get back to the same sort of "trouble" we're in right now, in any case.

Quote
Anyway, I would definitely try to make path length limit as big as possible.

Right now it is basically just requiring that at least the average path length of all maps be met.  We can increase this threshold, but it significantly increases map generation time rather quickly.

Quote
Ideally it should be big enough to require to cross the whole map several times.

Finding such a map quickly is unfeasible.
legendary
Activity: 910
Merit: 1000
August 22, 2014, 10:12:40 AM
can i mine with my cd-player?
newbie
Activity: 49
Merit: 0
August 22, 2014, 10:05:07 AM
Sounds great!

At 30 second TT, the best performing general solver (still the "MLSL" based search) averages just under 5 minutes per solution, with a single ~2ghz core behind it.

It's a little worrying though. Just a few more cores and we're in trouble again.

Anyway, I would definitely try to make path length limit as big as possible. Ideally it should be big enough to require to cross the whole map several times.
sr. member
Activity: 434
Merit: 250
August 22, 2014, 09:13:06 AM
Will you include minimum path length limitation in this patch?

Yes!  Maps will require a jump-point-search shortest path check against a grid approximation, using an (integer, ofc) Manhattan distance heuristic.  Maps will need to have an "above average" path length to qualify.  This adds only a fraction of a second to map generation but explicitly rules out any "fall-through" maps.  As a nice side effect, it also eliminates most maps where the coin is unreachable.

I spent quite a bit of time (too much, probably, in retrospect) comparing different approaches to doing this path check.  The particular path finding that I settled on is quite a bit better than using a "plain" A* search, both because it is much more efficient (our maps show a very high degree of path symmetry) and requires a bit more memory interaction which should better serve to lower GPU/ASIC efficiency advantage for the future.

Work measurements over the past few hours have gone smoothly so far, with a significantly better looking work curve than what we were seeing in practice, before.  Bots that are "tuned" for straight line solutions are significantly under-performing, as would be expected, since they rely almost entirely on the map filter step.  Slightly more general "flipper" style bots (older bots) are performing at about 25% of their normal efficiency, which is also about what I'd expect.  Minim1ner's bot falls behind the pack a little there, coming in at below 10% of what it would normally do with its map filtering enabled.

At 30 second TT, the best performing general solver (still the "MLSL" based search) averages just under 5 minutes per solution, with a single ~2ghz core behind it.
newbie
Activity: 49
Merit: 0
August 22, 2014, 06:13:22 AM
Today the chain stalled because of the existing work credit calculation.  Because log2_work hit the maximum the network will not presently accept further work.  I'll have a fix together within 12-24 hours.  Hopefully that will mean launching the new work curve entirely, but I have a simple fallback plan for a short term solution if not.

Will you include minimum path length limitation in this patch?
sr. member
Activity: 434
Merit: 250
August 22, 2014, 02:45:29 AM
ETA roughly 18 hours, or so.  The new code seems pretty stable, and I've started work measurements on what I think should be the parameters for the relaunch.  It doesn't look like we should expect any problems with resuming the chain.
legendary
Activity: 1526
Merit: 1001
Crypto since 2014
August 21, 2014, 06:19:54 AM
Today the chain stalled because of the existing work credit calculation.  Because log2_work hit the maximum the network will not presently accept further work.  I'll have a fix together within 12-24 hours.  Hopefully that will mean launching the new work curve entirely, but I have a simple fallback plan for a short term solution if not.
That would be good.
Just letting you guys know I haven't abandoned motocoin. Once we get these bots out it will be smooth sailing. Hopefully.
Pages:
Jump to: