[GUIDE] GridSeed 5-Chip USB, Blade & Black Miner Support/Tuning - page 34.

wolfey2014

sr. member

Activity: 378

Merit: 250

Quote from: sandor111 on April 30, 2014, 08:51:55 PM

Quote from: csmflynt3 on April 30, 2014, 08:17:27 PM

I have been running for 10 +hrs with no issues on my 10 Gridseed (5 chip). Still have problems with the 40 chips Blades so just curious if anyone is successfully running this new cpuminer with blades on windows 7 .

It appears that all 80 chips initially begin hashing , but after about 10 minutes 40 stop hashing. The other 40 may keep hashing for 30 minutes or so. CPUminer is still trying to send out work so the program is not locking up etc. I thought it may be a usb issue so I switched out the cables with the 5 chips to rule that out. Com port settings have FIFO disabled etc. I also tested this out with bfgminer-3-99-0-windows-clean and my blades seem to work fine with that so far, but I would rather use this cpuminer version.

I tried the most basic script to rule out as much as possible. Frequency can be anywhere from 600-900 with same result so not sure what my problem is

minerd-gc3355 --freq=600 --gc3355=\\.\COM11,\\.\COM12 --url=stratum+tcp://us-east.multipool.us:7777 --userpass=X.XXXX:x

Thanks

Quote

Upload the full miner log (including debug output), maybe I can find something.
I haven't thoroughly tested on G-Blades, because I don't own one.

Quick! Somebody send a blade to Sandor!
That could only benefit all of us!
Maybe we could all chip in on certain miners we want updates/upgraded programs for to send 1 of to Sandor which would also be an excellent exchange for his dedication and innovation. This too would benefit everyone. A very pro-survival action! A true win win.
Love your work Sandor. You know it! Cool

sandor111

hero member

Activity: 616

Merit: 500

Quote from: csmflynt3 on April 30, 2014, 08:17:27 PM

I have been running for 10 +hrs with no issues on my 10 Gridseed (5 chip). Still have problems with the 40 chips Blades so just curious if anyone is successfully running this new cpuminer with blades on windows 7 .

It appears that all 80 chips initially begin hashing , but after about 10 minutes 40 stop hashing. The other 40 may keep hashing for 30 minutes or so. CPUminer is still trying to send out work so the program is not locking up etc. I thought it may be a usb issue so I switched out the cables with the 5 chips to rule that out. Com port settings have FIFO disabled etc. I also tested this out with bfgminer-3-99-0-windows-clean and my blades seem to work fine with that so far, but I would rather use this cpuminer version.

I tried the most basic script to rule out as much as possible. Frequency can be anywhere from 600-900 with same result so not sure what my problem is

minerd-gc3355 --freq=600 --gc3355=\\.\COM11,\\.\COM12 --url=stratum+tcp://us-east.multipool.us:7777 --userpass=X.XXXX:x

Thanks

Quote

Upload the full miner log (including debug output), maybe I can find something.
I haven't thoroughly tested on G-Blades, because I don't own one.

csmflynt3

member

Activity: 86

Merit: 10

I have been running for 10 +hrs with no issues on my 10 Gridseed (5 chip). Still have problems with the 40 chips Blades so just curious if anyone is successfully running this new cpuminer with blades on windows 7 .

It appears that all 80 chips initially begin hashing , but after about 10 minutes 40 stop hashing. The other 40 may keep hashing for 30 minutes or so. CPUminer is still trying to send out work so the program is not locking up etc. I thought it may be a usb issue so I switched out the cables with the 5 chips to rule that out. Com port settings have FIFO disabled etc. I also tested this out with bfgminer-3-99-0-windows-clean and my blades seem to work fine with that so far, but I would rather use this cpuminer version.

I tried the most basic script to rule out as much as possible. Frequency can be anywhere from 600-900 with same result so not sure what my problem is

minerd-gc3355 --freq=600 --gc3355=\\.\COM11,\\.\COM12 --url=stratum+tcp://us-east.multipool.us:7777 --userpass=X.XXXX:x

Thanks

wolfey2014

sr. member

Activity: 378

Merit: 250

Quote from: sandor111 on April 30, 2014, 08:38:27 AM

Quote from: nst6563 on April 30, 2014, 08:31:28 AM

It's a work in progress, people shouldn't expect perfection with every release.

Unless you are called Wolfey2014. Roll Eyes

fivejonnyfive

sr. member

Activity: 294

Merit: 250

Quote from: ?? on ??

Whats the best OS and miner? Need to be able to remote control over internet (either web control panel or RDP)

There's lots of guides in forums but failed to find any guide which has all the info needed.

For Scrypt-only on GridSeed, sandor's CPU miner is the best in my opinion right now.

I run it on a raspberry pi and while there's not a web interface, I do remotely monitor the miner via SSH and can reboot and change pools if I need to.

sandor111

hero member

Activity: 616

Merit: 500

Quote from: surgexvb on April 30, 2014, 05:08:27 PM

Quote from: sandor111 on April 30, 2014, 01:31:38 PM

Quote from: surgexvb on April 30, 2014, 01:29:21 PM

The freezing problem seems to have something to do.with the autotune feature. When enabled, it freezes every 2 hours or so everytime. When I disable it, now it has been running fine for 12 hours.

That's because the the autotune features prints a line immediately after another, so it's more likely to deadlock (tui_lock).
Do you still experience freezing even with v0.9a? It should be a thing of the past now.

Quote from: Kergekoin on April 30, 2014, 09:31:16 AM

Looks like "--freq=950" overrides the "--gc3355-freq=\\.\COM42:700"
How could i set one device lower/higher than all the rest without typing each individually?

Edit: OK. I got it. I needed to write individual freq before the overall.

I'm pretty sure it's not the case. The most specific frequency is always applied.

Thanks for your reply Sandor. One thing I have always wondered about is when I have multiple gridseeds, or any other ASIC for that matter, do the ASICS actually work together to solve the work that the pool gives, or is each ASIC on its own trying to solve the work.

The reason I ask is I used to run individual cpuminer instances per ASIC, with each ASIC connected with its own worker name to the pool. With that method, each worker had a low difficulty appropriate for its hashrate. My hashrate was pretty consistent around 14,500 KH. Never went much below or.above that.

Now, using your cpuminer, I have 21 gridseeds under one worker name, and since the hashrate is high, the pool gives them high difficulty. This results in my hashrate fluctuating anywhere from 9,500 KH to 17,000 KH.

If each gridseed is indeed operating on its own, I would think the difficulty would be too high for a 340kh device and would be discarding work because it cannot solve it in time before the work becomes stale.

Any insight into this would be much appreciated.

It's pretty technical, but in cpuminer-gc3355, the pool sends work to cpuminer (consists of coinbase, previous hash, merkle tree), cpuminer assembles the block header and adjusts a value called extranonce2, which can be changed freely. This results in a different merkle root hash, thus different 'work'. The work has to be generated for each Gridseed miner to prevent the miners from solving the same work.
The unique work data is sent to the Gridseed miner, where it will be divided between the 5 or 40 chips, this is done by changing the the starting and ending nonce value.

Pool difficulty does not matter long term I think, you'll just get more consistent results on low diff short term. The process of detecting new work and sending it to the Gridseed miner takes less than 1s, atleast on cpuminer. It's fine to discard old work, here is why: there are multiple solutions (nonces) to the work, the probability of finding a nonce with current work doesn't change during trying to solve it, it's not that it 'wasted' time trying to solve work when that work goes stale if you know what I mean.
Hope this helps.

Edit: Thanks Kergecoin.

Kergekoin

hero member

Activity: 546

Merit: 500

Reporting for latest windows minerd. Works perfectly for 6-7 hours now.
Award outgoing to the guy whos responsible. Cheesy

50K DOGEs sprinting towards you!

surgexvb

full member

Activity: 445

Merit: 100

Quote from: sandor111 on April 30, 2014, 01:31:38 PM

Quote from: surgexvb on April 30, 2014, 01:29:21 PM

The freezing problem seems to have something to do.with the autotune feature. When enabled, it freezes every 2 hours or so everytime. When I disable it, now it has been running fine for 12 hours.

That's because the the autotune features prints a line immediately after another, so it's more likely to deadlock (tui_lock).
Do you still experience freezing even with v0.9a? It should be a thing of the past now.

Quote from: Kergekoin on April 30, 2014, 09:31:16 AM

Looks like "--freq=950" overrides the "--gc3355-freq=\\.\COM42:700"
How could i set one device lower/higher than all the rest without typing each individually?

Edit: OK. I got it. I needed to write individual freq before the overall.

I'm pretty sure it's not the case. The most specific frequency is always applied.

Thanks for your reply Sandor. One thing I have always wondered about is when I have multiple gridseeds, or any other ASIC for that matter, do the ASICS actually work together to solve the work that the pool gives, or is each ASIC on its own trying to solve the work.

The reason I ask is I used to run individual cpuminer instances per ASIC, with each ASIC connected with its own worker name to the pool. With that method, each worker had a low difficulty appropriate for its hashrate. My hashrate was pretty consistent around 14,500 KH. Never went much below or.above that.

Now, using your cpuminer, I have 21 gridseeds under one worker name, and since the hashrate is high, the pool gives them high difficulty. This results in my hashrate fluctuating anywhere from 9,500 KH to 17,000 KH.

If each gridseed is indeed operating on its own, I would think the difficulty would be too high for a 340kh device and would be discarding work because it cannot solve it in time before the work becomes stale.

Any insight into this would be much appreciated.

sandor111

hero member

Activity: 616

Merit: 500

Quote from: ManeBjorn on April 30, 2014, 04:41:13 PM

I have been reading through the thread here and I have a couple problems I cannot seem to solve with the blades.
It starts out at over 12 mh/s but after and hour or two goes all the way down to 3.8 and stays there. This is on clevermining, LTCRabbit and ScryptGuild.
This is with two Blades using CPUMiner. I am not sure what to do.

Here is my argument.

Quote

minerd.exe --freq=800 --gc3355=\\.\COM6,\\.\COM7,\\.\COM9,\\.\COM10 --gc3355-chips=40 --url=stratum+tcp://us.clevermining.com:3333 --userpass=1EV2wjbEkLyXBPzr7hTXyhNjsaNpyuTram:123

pause

I had tried with one Blade and autotune and got the same results.

I am not sure what I need to do to keep them running at full speed.

Any help would be appreciated.

Upload the full miner log (including debug output), maybe I can find something.
I haven't thoroughly tested on G-Blades, because I don't own one.

ManeBjorn

legendary

Activity: 1288

Merit: 1004

I have been reading through the thread here and I have a couple problems I cannot seem to solve with the blades.
It starts out at over 12 mh/s but after and hour or two goes all the way down to 3.8 and stays there. This is on clevermining, LTCRabbit and ScryptGuild.
This is with two Blades using CPUMiner. I am not sure what to do.

Here is my argument.

Quote

minerd.exe --freq=800 --gc3355=\\.\COM6,\\.\COM7,\\.\COM9,\\.\COM10 --gc3355-chips=40 --url=stratum+tcp://us.clevermining.com:3333 --userpass=1EV2wjbEkLyXBPzr7hTXyhNjsaNpyuTram:123

pause

I had tried with one Blade and autotune and got the same results.

I am not sure what I need to do to keep them running at full speed.

Any help would be appreciated.

almond

sr. member

Activity: 407

Merit: 254

"...so allowing the autotune to save it's conclusions regarding config - this would be appealing to many."

yes, that's exactly why I use autotune all the time.

my GSD's run well at 1175 mhz with a few differences up and down for a couple of the chips, so 1175 is not bad for me either.
but it would be a neat trick to be able to take advantage of the autotune's conclusions on the next start...via config or whatever.

fivejonnyfive

sr. member

Activity: 294

Merit: 250

Quote from: almond on April 30, 2014, 02:21:23 PM

Is there any reason not to use autotune all the time ?

recently I've been starting cpuminer close to where I want the GSDs to go and let autotune fine tune each chip.

In my opinion the benefit to not using autotune every time you startup the miner is that while autotune is finding the sweet spot you're going to have a slightly reduced hashrate and/or a higher HW error rate (which functionally reduces the hashrate).

In theory - one run of the autotune on a given unit should produce the optimal "profile" of the sweet-spot frequency for each chip. If you could reload that profile you would have the autotuned-frequencies per-chip without the several-hours of slightly reduced hashrate.

Now, whether there is any noticeable difference is another matter entirely. But, I'd imagine that all but the most casual of casual miners is trying to squeeze every drop of efficiency out of their hardware - so allowing the autotune to save it's conclusions regarding config - this would be appealing to many.

Just my two cents.

almond

sr. member

Activity: 407

Merit: 254

Is there any reason not to use autotune all the time ?

recently I've been starting cpuminer close to where I want the GSDs to go and let autotune fine tune each chip.

fivejonnyfive

sr. member

Activity: 294

Merit: 250

Quote from: sandor111 on April 30, 2014, 07:17:27 AM

For now, the best way is to turn on logging (--log), and CTRL+F "0@0: autotune stopped", "0@1: autotune stopped", ... Pretty tedious if you have lots of miners or G-Blades.
I'm going add a config generator to the autotune feature.

I literally logged on here specifically to request adding a feature where the autotune results could be saved for future boots and I'm f'ing delighted that you're already working on this. Again, infinite gratitude for your work and skills.

sandor111

hero member

Activity: 616

Merit: 500

Quote from: surgexvb on April 30, 2014, 01:29:21 PM

The freezing problem seems to have something to do.with the autotune feature. When enabled, it freezes every 2 hours or so everytime. When I disable it, now it has been running fine for 12 hours.

That's because the the autotune features prints a line immediately after another, so it's more likely to deadlock (tui_lock).
Do you still experience freezing even with v0.9a? It should be a thing of the past now.

Quote from: Kergekoin on April 30, 2014, 09:31:16 AM

Looks like "--freq=950" overrides the "--gc3355-freq=\\.\COM42:700"
How could i set one device lower/higher than all the rest without typing each individually?

Edit: OK. I got it. I needed to write individual freq before the overall.

I'm pretty sure it's not the case. The most specific frequency is always applied.

surgexvb

full member

Activity: 445

Merit: 100

The freezing problem seems to have something to do.with the autotune feature. When enabled, it freezes every 2 hours or so everytime. When I disable it, now it has been running fine for 12 hours.

Kergekoin

hero member

Activity: 546

Merit: 500

Quote from: RowanX on April 30, 2014, 11:27:03 AM

Quote from: Kergekoin on April 30, 2014, 09:31:16 AM

Looks like "--freq=950" overrides the "--gc3355-freq=\\.\COM42:700"
How could i set one device lower/higher than all the rest without typing each individually?

Edit: OK. I got it. I needed to write individual freq before the overall.

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

Quote

minerd-gc3355.exe --freq=850 --gc3355=\\.\COM1,\\.\COM2 --url=stratum+tcp://whatever.com:3333 --userpass=xxx.1:password --gc3355-freq=\\.\COM1:875,\\.\COM1:850:2,\\.\COM2:850:0,\\.\COM2:850:1,\\.\COM2:825:2,\\.\COM2:875:3,\\.\COM2:850:4,
pause

this gives the expected speeds:

Quote

[2014-04-30 17:28:03] 0@0: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:03] 0@1: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:03] 0@2: Set GC3355 core frequency to 850Mhz
[2014-04-30 17:28:03] 0@3: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:03] 0@4: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:03] 1@0: Set GC3355 core frequency to 850Mhz
[2014-04-30 17:28:03] 1@1: Set GC3355 core frequency to 850Mhz
[2014-04-30 17:28:04] 1@2: Set GC3355 core frequency to 825Mhz
[2014-04-30 17:28:04] 1@3: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:04] 1@4: Set GC3355 core frequency to 850Mhz

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.

Well, its holds true at least on my win8.1 mining rig. If i put individual freq after the overall, then individual freq does not work.

Mr. Jinx

member

Activity: 112

Merit: 10

For those compiling CPUMiner on a Raspberry Pi:

It is not recommended to use the -O3 optimization parameter.
O3 is used for some high level optimization that may cause problems on RPi's.
My cpuminer would freeze very soon when compiled with -O3 parameter!

For Raspberry Pi's the recommended optimizations are -march=armv6 -mfpu=vfp -mfloat-abi=hard
After using these, my RPi is running for 24 hours without freezing.

Compiling CPUMiner on a Raspberry Pi:

Code:

git clone https://github.com/siklon/cpuminer-gc3355
cd cpuminer-gc3355
sh ./autogen.sh
./configure CFLAGS="-march=armv6 -mfpu=vfp -mfloat-abi=hard"
make

RowanX

member

Activity: 86

Merit: 10

Quote from: Kergekoin on April 30, 2014, 09:31:16 AM

Looks like "--freq=950" overrides the "--gc3355-freq=\\.\COM42:700"
How could i set one device lower/higher than all the rest without typing each individually?

Edit: OK. I got it. I needed to write individual freq before the overall.

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

Quote

minerd-gc3355.exe --freq=850 --gc3355=\\.\COM1,\\.\COM2 --url=stratum+tcp://whatever.com:3333 --userpass=xxx.1:password --gc3355-freq=\\.\COM1:875,\\.\COM1:850:2,\\.\COM2:850:0,\\.\COM2:850:1,\\.\COM2:825:2,\\.\COM2:875:3,\\.\COM2:850:4,
pause

this gives the expected speeds:

Quote

[2014-04-30 17:28:03] 0@0: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:03] 0@1: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:03] 0@2: Set GC3355 core frequency to 850Mhz
[2014-04-30 17:28:03] 0@3: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:03] 0@4: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:03] 1@0: Set GC3355 core frequency to 850Mhz
[2014-04-30 17:28:03] 1@1: Set GC3355 core frequency to 850Mhz
[2014-04-30 17:28:04] 1@2: Set GC3355 core frequency to 825Mhz
[2014-04-30 17:28:04] 1@3: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:04] 1@4: Set GC3355 core frequency to 850Mhz

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.

Kergekoin

hero member

Activity: 546

Merit: 500

Just delete retries flag and it loops indefinately.

I would be interested of checking back the main pool from time to time. And switching over to it when it comes back online.

Topic: [GUIDE] GridSeed 5-Chip USB, Blade & Black Miner Support/Tuning - page 34. (Read 308847 times)