ltcminer.py from LX150 - Githubissues

Hi, It seems that ltcminer.py is only showing half the nonces in the count. (or litecoin is double crediting.)

The below run..

./ltcminer.py Miner started on Wed Aug 14 15:14:30 2013 Sending data to FPGA Payload 00007fff6c6f6f700bf84c1b582e0b5272ae7ba598a8d632ad31b86e7a92756a2e169cee718b7d23efd35579644b2157d0ede2df8d6ceb2aee663f19c0685f21abab29d9727500b3c9231d34860195d002000000 Share found on Wed Aug 14 15:14:38 2013 nonce 0c6faa2f Sending data to FPGA Payload 00007fff6c6f6f700bf84c1b5e2e0b528b4a95a1f0bc3a01f2eb237b6e0b16c83a247a0d455d8424ca98c2873e4bf009d0ede2df8d6ceb2aee663f19c0685f21abab29d9727500b3c9231d34860195d002000000 Upstream result: True [1 accepted, 0 failed, 266.25 +/- 266.25 khash/s] ^CTerminated

According to this we have 1 share that was accepted....

According to: https://www.litecoinpool.org/account

we have : Shares Stale shares Invalid shares
2 0 (0.00%) 0 (0.00%)

I can guarantee the count is correct at litecoin.org because it was a brand new miner account i created to test it....

but also.. if I leave it running for a while , the account on litecoin is always double what the python shows..

Its pretty much unchanged from what's on fpgaminer's githib. I just changed the getwork to use the full header instead of midstate (its not much use in scrypt), added the test payload (which I'd already done for my MOJO bitcoin port, so reused the idea here), and tweaked the hash rate reporting for khash/sec rather than mhash/sec (this could be wrong though, so don't rely on the figures).

The only thing I can think of is the tendancy for litecoin pools to run with variable difficulty (you chose your worker difficulty when you set it up), the default usually being 32. This is why I added the target feature to ltcminer.py so as to avoid getting caught out (no point solving at a fixed 32 diff when the pool may want 64, or worse 16). Perhaps its sending diff=64 and so double counting the shares? No that's wrong, the target is still 7ff (its in the payload you showed in your post). And what is that nonce doing in the getwork block header? I thought the pools always set it to zero. It doesn't matter, but that will be the starting point for the scan (and to answer your PM question, you need to set the macro NOMULTICORE to scan the whole range, else the top nibble is hardwired to zero, you can see it in the synthesis warnings for stuck nodes).

I've only tested using mining-foreman.org, so perhaps other pools behave differently. Which one are you using so I can test it myself? (EDIT litecoin.org, it was in your post already, sorry), Not quite such an easy task as I'll need to port the serial code onto my DE0-Nano so as to use the python mining script rather than JTAG.

Requested an account at litecoinpool.org - I'll just test it with the TCL script for now, just to see if it gives the same behaviour as the python one.

Cool pool !! Variable difficulty, target started at 000007ff then dropped to 0000ffff. Getting a few rejects on share submission but seems to be working fine. NB the kH/sec reported by the mine.tcl script is garbage as it assumes diff=32. But the variable target code is working just fine! Just need to tweak the reported hashrate to take account of the actual target.

C:\altera\10.1\quartus\bin\quartus_stp -t mine.tcl

Looking for and preparing FPGAs...

Mining FPGA Found: USB-Blaster [USB-0] @1: EP3C25/EP4CE22 (0x020F30DD)

093b6e831316ee130146463a62af7d99318bee2022d0a5797a00c81e02000000 802ae3a43999092c2b2834191ea00f44086058ba8d63286e2be2354bdd88a8e5 000000000000000000000000800000006c6f6f700bf84c1b63610b52c3ac81a0 target 00000fff [08/14/2013 11:52:29] 1.86 kH/s (~0.00 kH/s) [Rej: 0/0 (0.00%)] n=6c6f7e0e [08/14/2013 11:52:31] 1.86 kH/s (~0.00 kH/s) [Rej: 0/0 (0.00%)] n=6c6f8c8d [08/14/2013 11:52:33] 1.86 kH/s (~0.00 kH/s) [Rej: 0/0 (0.00%)] n=6c6f9b14 [08/14/2013 11:52:35] 1.86 kH/s (~0.00 kH/s) [Rej: 0/0 (0.00%)] n=6c6fa99c [08/14/2013 11:52:37] 1.86 kH/s (~0.00 kH/s) [Rej: 0/0 (0.00%)] n=6c6fb826 [08/14/2013 11:52:39] 1.86 kH/s (~0.00 kH/s) [Rej: 0/0 (0.00%)] n=6c6fc6ae [08/14/2013 11:52:41] 1.86 kH/s (~0.00 kH/s) [Rej: 0/0 (0.00%)] n=6c6fd536 [08/14/2013 11:52:43] 1.86 kH/s (~0.00 kH/s) [Rej: 0/0 (0.00%)] n=6c6fe3c4 [08/14/2013 11:52:45] 1.86 kH/s (~0.00 kH/s) [Rej: 0/0 (0.00%)] n=6c6ff24f [08/14/2013 11:52:47] 1.86 kH/s (~0.00 kH/s) [Rej: 0/0 (0.00%)] n=6c7000d7 093b6e831316ee130146463a62af7d99318bee2022d0a5797a00c81e02000000 b82d53386208b018e1f643b24d3333e9a2450e4f1a3cd4b92729d7cfdd88a8e5 000000000000000000000000800000006c6f6f700bf84c1b77610b52f250ae97 [08/14/2013 11:52:49] 1.86 kH/s (~0.00 kH/s) [Rej: 0/0 (0.00%)] n=6c701010

snip

[08/14/2013 11:54:26] 1.86 kH/s (~0.00 kH/s) [Rej: 0/0 (0.00%)] n=6c72ccb2 [08/14/2013 11:54:28] 1.86 kH/s (~0.00 kH/s) [Rej: 0/0 (0.00%)] n=6c72db3d e1a9ab9187f38e4b4b83fb84c1ebda018e2accbf000cbf733ec1366602000000 4f39458b3ff6c08742ba370ac1afe933eb66111b8e05ddae47c336af767ab3f1 000000000000000000000000800000006c6f6f700bf84c1bdc610b52b7b9d5ae target 00007fff [08/14/2013 11:54:30] 1.86 kH/s (~0.00 kH/s) [Rej: 0/0 (0.00%)] n=6c72ea8a [08/14/2013 11:54:32] 1.86 kH/s (~0.00 kH/s) [Rej: 0/0 (0.00%)] n=6c72f919

snip

[08/14/2013 11:55:22] 1.86 kH/s (~11.99 kH/s) [Rej: 0/1 (0.00%)] n=6c7463f2 [08/14/2013 11:55:24] 1.86 kH/s (~11.86 kH/s) [Rej: 0/1 (0.00%)] n=6c74727d e1a9ab9187f38e4b4b83fb84c1ebda018e2accbf000cbf733ec1366602000000 7c5ace0cd68a424ed1bebaca82aedd658bf7f6a6cbc80e465f564ac1767ab3f1 000000000000000000000000800000006c6f6f700bf84c1b16620b52809b22a9 [08/14/2013 11:55:28] 1.86 kH/s (~11.60 kH/s) [Rej: 0/1 (0.00%)] n=6c748e6a [08/14/2013 11:55:30] 1.86 kH/s (~11.47 kH/s) [Rej: 0/1 (0.00%)] n=6c749cfe [08/14/2013 11:55:30] 6c74a132 accepted e1a9ab9187f38e4b4b83fb84c1ebda018e2accbf000cbf733ec1366602000000 c48abf5b114ccd31b3d9f70aaf9ddfdcc3561d6100f5b2780a502bea767ab3f1 000000000000000000000000800000006c6f6f700bf84c1b1a620b5240ad3e97 [08/14/2013 11:55:32] 1.86 kH/s (~22.69 kH/s) [Rej: 0/2 (0.00%)] n=6c74b0fe [08/14/2013 11:55:34] 1.86 kH/s (~22.45 kH/s) [Rej: 0/2 (0.00%)] n=6c74bf86

snip

[08/14/2013 11:56:10] 1.86 kH/s (~18.82 kH/s) [Rej: 0/2 (0.00%)] n=6c75c437 [08/14/2013 11:56:12] 1.86 kH/s (~18.66 kH/s) [Rej: 0/2 (0.00%)] n=6c75d2c4 dcbd49929b378f01126b534c196ad0ce6cd048073ed9293f6f5f847b02000000 b45343e81911b3d36c195655f798ad04ede14c710a9e49aea1202a40375407df 000000000000000000000000800000006c6f6f700bf84c1b44620b52eae3af51 [08/14/2013 11:56:14] 1.86 kH/s (~18.49 kH/s) [Rej: 0/2 (0.00%)] n=6c75e1f3 [08/14/2013 11:56:16] 1.86 kH/s (~18.33 kH/s) [Rej: 0/2 (0.00%)] n=6c75f07f [08/14/2013 11:56:18] 1.86 kH/s (~18.17 kH/s) [Rej: 0/2 (0.00%)] n=6c75ff09 [08/14/2013 11:56:20] 1.86 kH/s (~18.02 kH/s) [Rej: 0/2 (0.00%)] n=6c760d91 [08/14/2013 11:56:22] 1.86 kH/s (~17.86 kH/s) [Rej: 0/2 (0.00%)] n=6c761c1d [08/14/2013 11:56:28] ERROR: Unable to submit share. Reason: can't read "state(s tatus)": no such variable [08/14/2013 11:56:28] 6c7620e2 rejected wrong # args: should be "::error message ?errorInfo? ?errorCode?" while executing "::error" ("eval" body line 1) invoked from within "eval ::error $errorlist" (procedure "http::reset" line 11) invoked from within "http::reset ::http::16 timeout" ("after" script) dcbd49929b378f01126b534c196ad0ce6cd048073ed9293f6f5f847b02000000 d5bbb74412049aee9aa0518d7d61c57da23bb01103dc7dbc2901e860375407df 000000000000000000000000800000006c6f6f700bf84c1b54620b520e3e1953 [08/14/2013 11:56:30] 1.86 kH/s (~25.91 kH/s) [Rej: 1/3 (33.33%)] n=6c7654ea [08/14/2013 11:56:32] 1.86 kH/s (~25.70 kH/s) [Rej: 1/3 (33.33%)] n=6c766373

Username Password Speed Shares Stale shares Invalid shares Blocks Notify **** 1.53 kH/s 14 0 (0.00%) 0 (0.00%) 0
Last Time Difficulty PPS Rate Shares Rewards 2013-08-14 11:02 UTC 851.44759513 0.000000860208 14 0.000012042912 LTC

OK, I've run it for a while now and the reject rate is EXACTLY 50%

[08/14/2013 12:25:33] 1.86 kH/s (~38.16 kH/s) [Rej: 14/28 (50.00%)] n=6ca7c9cb

So there may be a problem. The pool reports 1.31 kH/s 34 shares (including a few from earlier runs). That's a bit more than I expected if it is actually rejecting 50% of the shares. Possibly its just getwork timeouts after all. I'll see if I can get slush's stratum proxy to work (I had some problems on mining-forman,org and abandoned it, but I'll have another go now). Oh, and now getwork isn't connecting at all! I never much liked these json libraries anyway, not easy to see exactly what is being reported. Perhaps I'll modify my raw C mining code and use the serial interface instead.

Problem solved. The pool is accepting shares at difficulty=2, so credits two shares for each one submitted (the target is dynamically adjusted, so it will depend on the mining speed). I gave up on getwork, just too many timeouts. Installed https://github.com/CryptoManiac/stratum-mining-proxy on my non-mining raspberry pi (I'm not going to install random binaries from a .ru domain on my windows PC, no way!), and it runs like a charm. You have to start it as per the instructions on litecoinpool.org vis:

./mining_proxy.py -nm -pa scrypt -o litecoinpool.org -p 3333

Then set your worker details in config.tcl (note the getwork port number)

set url "tvpi.lan:8332" set userpass "username.1:1"

The ltcminer.py should work in pretty much the same way.

PS For the altera, json_rpc.tcl needs to comment out the line

set work(midstate) [dict get $json_result midstate]

as the proxy does not send midstate when started with -nm

PPS This is the result of around three hours run using my 45MHz build.

[08/14/2013 16:50:01] 2.09 kH/s (~35.67 kH/s) [Rej: 11/131 (8.40%)] n=00f632c4

The (~35.67kH/s) is garbage of course, though divide by 16 would give the correct value. Note that the rejects are all due to new blocks found. The stratum log reports a clean_jobs=TRUE event, then the following share is rejected by stratum (it never gets sent to the pool, I guess this is how stratum reduces stales, lol). I've increased the getwork rate from 20 secs to every 2 secs to see if this will help (it should cause no harm since the work is generated locally by the stratum server), though ideally we'd use longpolling.

This is one hour later, the pool is reporting 2.84 kH/s 534 shares total ...

[08/14/2013 17:50:32] 2.10 kH/s (~44.03 kH/s) [Rej: 0/75 (0.00%)] n=016a26c1

... seems to have done the trick :-)

Interesting…. I'm only getting 1 or 2 stales on getwork.. but at least we now know why the hash rate was double.

Bit disappointed by the fact that you will not load russian code into your pc…..

wow… we are actually learning stuff and having fun ;-)

On Aug 14, 2013, at 8:53 PM, kramble notifications@github.com wrote:

Problem solved. The pool is accepting shares at difficulty=2, so credits two shares for each one submitted (the target is dynamically adjusted, so it will depend on the mining speed). I gave up on getwork, just too many timeouts. Installed https://github.com/CryptoManiac/stratum-mining-proxy on my non-mining raspberry pi (I'm not going to install random binaries from a .ru domain on my windows PC, no way!), and it runs like a charm. You have to start it as per the instructions on litecoinpool.org vis:

./mining_proxy.py -nm -pa scrypt -o litecoinpool.org -p 3333

Then set your worker details in config.tcl (note the getwork port number)

set url "tvpi.lan:8332" set userpass "username.1:1"

The ltcminer.py should work in pretty much the same way.

— Reply to this email directly or view it on GitHub.

kramble / FPGA-Litecoin-Miner

ltcminer.py from LX150 #4