Sandor I can't see that the debug/log is being stored anywhere just printed to the screen? Rejects still seem high for me in your Windows build from today of 0.9e (A:306 R:36 H:0 over 60mins). Here is an excerpt from the log when some errors occured. Does this shed any light?

[2014-05-06 10:55:11] 1: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "55555581", "5368b16b", "a098f0cc"], "id":4016}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4016}
[2014-05-06 10:55:11] Rejected ccf098a0 GSD 1@4
[2014-05-06 10:55:11] DEBUG: reject reason: unknown-work
[2014-05-06 10:55:11] 0@0 875MHz: Got nonce 002ede29, Hash <= Htarget! (0xb1547f34) 74.1 KH /s
[2014-05-06 10:55:11] 0: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "8000002b", "5368b16b", "29de2e00"], "id":4017}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4017}
[2014-05-06 10:55:12] Rejected 002ede29 GSD 0@0
[2014-05-06 10:55:12] DEBUG: reject reason: unknown-work

Sure thing. Just add --debug and --protocol-dump to my bat file? I assume it will output the debug dump into a file in the same directory. How long should I run it for to produce something useful. An hour? I'll do it tomorrow its 3am here and I need to collapse.

I've only been running it for a little while but 0.9e seems to be giving the same problems as 0.9d, for me (Windows version). i.e. too many rejects with message "DEBUG: reject reason: unknown-work". Who here on Windows is or is not having the same issue? I've gone back to using 0.9c, again - its working fantastic. Sandor do you think this issue is likely to be specific to my setup? You are the magic jesus of mining and I look forward to your reply.

Simply put, 0.9d gives me high rejects 0.9c does not. Same pool, same auto adjusting difficulty, and the discrepancy is reproducible just by switching between the two builds. Nothing to do with pool. And its not just me, someone else mentioned it a few posts ago, albeit on RPi),

Its now been another 5 hours since the stats I posted above (9+ hours in total) and the number of rejects is still no where near the numbers that were produced in 0.9d in just 4 hours.

FIFO buffers are still off.

This is not a problem for me, I just use 0.9c, works fine.

I imagine mine was 25% ish rejects too, from the amount of locally shown errors, but it takes my pool stats ages to update, so I just saw it getting worse and worse. I'm using windows 8.0 but thanks for the suggestion. I've gone back to 0.9c for the time being.

I don't think its my imagination - I've done a little test with my 2 gridseeds; approx 4 hours mining on 0.9d then approx 4 hours mining on 0.9c. The results show more rejects in the newer version:

cpuminer 0.9c:
GSD0 (870Mhz): A:542  R:10  H:0
GSD1 (850Mhz): A:524  R:12  H:0

cpuminer 0.9d:
GSD0 (870Mhz): A:542  R:48  H:0
GSD1 (850Mhz): A:524  R:54  H:1

I'm getting a lot of rejects with cpuminer 0.9d. Didn't have this problem with 0.9c, I'm certain. Just me?

e.g. with 0.9c I was pleasantly surprised to see the poolside reject rate fall to a new all-time low of 0.38%. After switching to 0.9d, its gone up to 5.27% and climbing, and I can see reports of rejects locally a few times every minute. So I've gone back to 0.9c for now. Rejects such as:

"DEBUG: reject reason: unknown-work"
"DEBUG: reject reason: high hash"

No big deal but the stats seem to have got a bit tripped up in v0.9c:

Hey you didn't update the version number. #justsayin'

According to dropbox this was uploaded 20 hours ago.. but the latest commit on github is from 15 hours ago ("Optimize locks, handle invalid ltc responses"). Am I confused or are we waiting for a newer compile?

Not sure thats true? I specify --freq first and my chips all seem to report the desired frequencies.


this gives the expected speeds:


I'm guessing I could actually remove --freq=850 from my bat file, as it is not needed, because I specify all my chip speeds individually thereafter.

I had no problems overnight running the first version compiled today (30 Apr) - windows version, that is. Now using the 3rd compile of today, v0.9a. Top stats are working.   Thanks as ever for your work.

Sandor, the topline stats are not updating in the new version? My screenshot:

http://snag.gy/D6aPH.jpg

They still show A:0 and 0 MH/s speed even after some time when shares have been accepted and mining is in progress.

Sandor would you add the coin difficulty to the TUI in the next update? CGminer shows it. Loving your work.

Thanks Sandor.   Working like a charm with my two gridseeds.

Last night one of my two gridseeds just stopped. Lights still flashing but CPUminer not talking to it anymore.

In over a month of mining, that never happened  to me with CGMiner.. just saying. I've only been using CPUMiner since yesterday.

Sandog is there any way to debug this e.g. save CGMiners output to a text file or something (minerd.exe > log.txt?). I can see from the pool it died around 2:30am but obviously I can only see that last minute or so of work in CPUMiner's console window.

FWIW I have FIFO buffers disabled and baud rate of the COM ports set to max (128000 baud).

Anyway, I power cycled it and restarted CPUminer this morning and that has brought it back to life.

Trouble switching from CGminer to CPUminer?

I think I figured it out.. thanks to some advice from Pete @ Zadig.

Problem: After running Zadig to get CGMiner working... I couldn't get my Virtual COM ports back to a "virgin state", i.e. to appear under "Ports" section in Device Manager, show a COM number, and allow changing COM number and disabling FIFO buffers etc....

Removing the COM ports from Device Manager and even ticking "delete driver software" when doing so wasn't having the desired effect.

Solution: If like me you'd had the gridseeds (via USB hub or not) plugged into more than 1 USB port at any one time.. then you need to uninstall the STM32 driver (Add/Remove Programs), then plug the gridseed back into every USB port of your PC you ever used them in, systematically, and go to Device Manager each time to uninstall the COM ports that appear (usually under "USB Devices", if you had used Zadig to set WinUSB as the driver). After you've done them all, plug the gridseed(s) back in (I think they still appear under USB devices at this point..) then install the STM32 driver... and voila... back to normal, and CPUminer works.

p.s. with both CGminer and CPUminer I find that I sometimes have to unplug other USB devices from my system (mouse and keyboard lol) before they will find the gridseeds and start mining. Only sometimes however. I can plug them back in after mining starts, without problems.

p.p.s. it would be really great if CPUminer could be improved to show stats at the top like CGMiner does. Also.. as it takes ages to fine tune the chips.. is there any way to store that info or does it have to restart the whole tuning process every time you restart the software? Sandor?

Yep the syntax in my BAT file is fine in respect to that.


I can't find a straight forward way of doing that.. any suggestions?

I seem to have found the COM port numbers for my gridseeds using "USBDeview" (http://www.nirsoft.net/utils/usb_devices_view.html) program (COM11 & 12), but still cpuminer isn't finding them. Is this how things look for you guys?

http://pasteboard.co/2m01Cdgj.gif

I did check "delete driver software" when I removed them, but they still seem to get detected the same when I replug the USB, with no port numbers.