Topic: Flexible mining proxy - page 14. (Read 88666 times)

I'm not sure what you mean.  Can you elaborate?

Neat, I'll merge the fix into master.

How to set up a "no admin ask password" to test it

Works like a charm, and it fixed my 100% problem with Diablo too ^^

It's a custom lightweight MVC framework that doesn't do terribly fancy routing, but still allows me to separate my code better. 

I've pushed a fix to the diablo-lp-fix branch.  Can you try that and see if it fixes the issue for you?

Thanks!  I'll have a look later today.

Just issued a pull request for the hashing speed and shares in the last hour on the dashboard for each worker. Hope you like it ^^

I'm not really familiar with the framework you're using, so I started by implementing the hash speed for the workers. As for the routing of the post request, I guess you'd be faster than me :-)

Ah, good catch.  I should have followed the "be lenient in what you accept" rule when coding...

Absolutely, as long as you release your patches under the AGPLv3.  Have you patched it to accept POST for long-polling requests, or should I fix that?

I should have seen it immediately: Diablo uses POST request while well behaving clients (phoenix, poclbm, ...) use GET requests. Should be a simple matter of routing POST to the same handler
In the meantime I'm working on a hashrate estimate for the workers, which I'd find quite usefull. Do you accept patches/pull requests?

Will do ^^

Hmm... run a packet sniffer and see what's going on with the LP request?

Yes it's already disabled in php.ini:

;
; Safe Mode
;
safe_mode = Off

Though I think it would be a good idea to go back and mention as dependencies (in the INSTALL file) that safe_mode should be disabled, and that this (quite obviously) requires php json support, which is an add-on for PHP versions prior to 5.3.

Anyway this could very well have something to do with long polling.  I tried setting my max execution time (php.ini) to 1500 seconds, up from 30 seconds.  It did the following:

[08/05/2011 23:21:44] Connected to server
[08/05/2011 23:21:49] Result: be0189d3 accepted
[08/05/2011 23:21:54] Result: 62cffe98 accepted
[08/05/2011 23:21:58] Result: 65b66b0e accepted
[08/05/2011 23:22:31] Result: 2ca96088 accepted
[08/05/2011 23:22:38] Result: 8bd7c27e accepted
[08/05/2011 23:22:39] LP: New work pushed
[08/05/2011 23:22:47] Result: c662da7b accepted
[08/05/2011 23:23:20] Result: b9b3a17f accepted
[08/05/2011 23:23:30] Result: 889e14f2 accepted
[08/05/2011 23:23:31] Result: 1b237f90 accepted
[08/05/2011 23:23:38] Result: 9da72831 accepted
[08/05/2011 23:24:33] Result: ca84878c accepted
[08/05/2011 23:24:40] Disconnected from server
[08/05/2011 23:24:41] Connected to server
[08/05/2011 23:24:43] Result: 1b1964ce accepted
[08/05/2011 23:24:57] Result: 6b5df998 accepted
[08/05/2011 23:25:41] Result: 86510be4 accepted

Any other ideas?

The long-polling request is probably getting terminated.  This should only happen if you have PHP's safe mode enabled -- set_time_limit() has no effect when running under safe mode, so the most likely cause here is that PHP is simply killing the script doing the long-polling request because it is running for too long.  (Note that the "disconnection" message comes almost exactly two minutes after the "connection" message.)

Try disabling safe mode.  Safe mode can only be disabled in php.ini or your Apache configuration; .htaccess files can not disable safe mode.

Thanks, that gets connected and accepting work now, but after maybe 3 minutes of mining, I see a random disconnect:

[08/05/2011 20:27:46] Connected to server
[08/05/2011 20:28:30] Result: 9f0a0a6e accepted
[08/05/2011 20:28:31] Result: 6731f6a4 accepted
[08/05/2011 20:28:55] Result: a0527e09 accepted
[08/05/2011 20:28:59] Result: 196f2c04 accepted
[08/05/2011 20:29:17] Result: 65173661 accepted
[08/05/2011 20:29:21] Result: 564ba46a accepted
[08/05/2011 20:29:47] Disconnected from server
[08/05/2011 20:29:48] Connected to server
[08/05/2011 20:30:05] Result: 40071f20 accepted
[08/05/2011 20:30:24] Result: a6206ab4 accepted
[08/05/2011 20:30:33] Result: 73d3021d accepted
[08/05/2011 20:30:34] Disconnected from server
[307.16 Mhash/sec] [9 Accepted] [0 Rejected] [RPC (+LP)]

Let me know how I can help diagnose this.

I'm glad you like it.

This is a good idea.  I've added it to the issue tracker.

Hmm, I see.  I'll try to implement something so that if a pool doesn't respond normally to a share submission (e.g. it doesn't accept or reject the share, but gives some other HTTP or JSON-level error) the software will retry a few times, and disabled the pool for some time if it still can't reach the server.  This will depend on the other feature being implemented first.  (This one has also been added to the issue tracker.)

Hmm, that is definitely weird.  Can you sniff those requests and paste the HTTP conversation (sanitizing authentication details) so that I can see what's going on?

Fix just got pushed to the Git repository; please pull and see if the problem goes away.

Thanks, that's all I need to know to fix the problem.  Apparently the older PDO library doesn't support using the same query argument twice in a query.  A fix is forthcoming.

This is the result, sanitized to remove portions of my email/password at deepbit:

original: No rows found
hardcoded: Success (array (
  'pool_id' => '1',
  0 => '1',
  'username' => '[email protected]_10',
  1 => '[email protected]_10',
  'password' => 'xxx',
  2 => 'xxx',
  'url' => 'http://deepbit.net:8332',
  3 => 'http://deepbit.net:8332',
))
nodup: Success (array (
  'pool_id' => '1',
  0 => '1',
  'username' => '[email protected]_10',
  1 => '[email protected]_10',
  'password' => 'xxx',
  2 => 'xxx',
  'url' => 'http://deepbit.net:8332',
  3 => 'http://deepbit.net:8332',
))
no underscore: No rows found

I love this one. It make switching really painless, especially after todays outage of slush's pool this proved a timesaver. What I noticed however that the failing pool will still be asked for work, and only he doesn't return any, the next one will be asked. Are there plans for exponential backoff in order to avoid the extra request and the extra idle time? Just a mechanism to automatically blacklist a pool should it fail, and increase the blacklist time on each subsequent failure would be cool.
The problem today is that slush sometimes gives me work, but does not accept the result (timeout/502 errors/...).

Also I get a lot of these:
Which makes me think that the diablo miner does not really take advantage of the long polling feature, and I start feeling bad for bombing pools with all those long poll requests. Any ideas?

#$%&.  Me either... though I do have a few ideas...

It should work fine.  I'm on PHP 5.3.3, but all my code should be compatible with most PHP5 versions (and probably some PHP4 versions too).

To further diagnose this, can you try this script now?


Cool, thanks!  Hopefully we can get this working soon.  Obscure bugs are annoying.