The TUI is really basic (as I wrote it from scratch), it has a few bugs I need to iron out before I can push the code.
Topic: [GUIDE] GridSeed 5-Chip USB, Blade & Black Miner Support/Tuning - page 40. (Read 308807 times)
April 27, 2014, 09:11:49 AM
The TUI is really basic (as I wrote it from scratch), it has a few bugs I need to iron out before I can push the code.
April 27, 2014, 09:01:25 AM
For about 2 weeks, my miners were running on 9600 baud. Ive since upped that to 115200. Made no difference, but Im still using an older cpuminer with one instance each, one worker each.
i'll figure out how to work the new cpuminer, and if not i'll let you guys know.
i'll figure out how to work the new cpuminer, and if not i'll let you guys know.
Please make sure you have FIFO buffers turned OFF in comm port 'advanced' settings.
Having them ON causes problems like drop outs, slows etc.
Good luck!
April 27, 2014, 08:58:18 AM
ok I finally giving up running CPUMiner on Windows 7 and switched to Raspberry pi for some testing. Let's see if it will stop sending shares after a few minutes. So far they're running for 120+ minutes and doing fine. However I noticed a little drop of mining performance reported from pool side. Anyone using Raspberry pi for mining now? It it normal?
When you were running on Win7 with cpuminer with latest or earliest version doesn't matter, did you turn OFF FIFO buffers for all comm ports? FIFO buffers ON will cause the problem you were having and may still be having if you are still using the STM virtual comm port drivers. It's stated in several places on this and other threads. Perhaps you missed it?
I understand your frustration. Been there, done that. Hopefully you simply accidentally overlooked something and that caused your problem. It happens.
Good luck!
W
April 27, 2014, 08:37:22 AM
ok I finally giving up running CPUMiner on Windows 7 and switched to Raspberry pi for some testing. Let's see if it will stop sending shares after a few minutes. So far they're running for 120+ minutes and doing fine. However I noticed a little drop of mining performance reported from pool side. Anyone using Raspberry pi for mining now? It it normal?
+1 to this. Been running a blade for a few days now with mixed results. Windows seems to top out at bursts over 4MH but averaging slightly under, nowhere near advertised clock speed. Put both halves on separate pools to test results to see if it is the unit in question or an individual blade side.
For RPi, are people using the ZH image, image from another vendor, etc.? Setting up the ZH image right now so I can test with that.
Out of curiosity, what freq are people finding most reliable? I've read through this thread a bit and want to try out the jmordica cgminer fork (see people mentioning 838 freq a few times), but all-in-all the hardware just appears to be underperforming right now and I can't quite crack why due to lacking software support.
838 does seem to be best from my experience so far. The auto tune works great on the 5 chips , but did not help me with the blades as much. These blades do not seem to like overclocking as much for some reason, but I do not think it has anything to do with cpuminer
April 27, 2014, 07:58:19 AM
If you're getting a lower hashrate then normal, try turning off autotune, you aren't supposed to run it too long anyway.
I'm using Rasperian with a web based management interface which use CPUMiner. It has been 3 hrs now and pool side reports a more stable but slightly lower hash rate (8.9Mh/s~11Mh/s). I'm running 10x gridseed USB Miner plus a G-blade (2 instance) with auto-tune mode ON, plus 5x GTX 750 Ti at default speed (Result in a total of around 1.3Mh/s). The hash rate is kind of low isn't it?
BTW, you can run USB + G-Blade on 1 instance.
Quote
I'm using Rasperian with a web based management interface which use CPUMiner. It has been 3 hrs now and pool side reports a more stable but slightly lower hash rate (8.9Mh/s~11Mh/s). I'm running 10x gridseed USB Miner plus a G-blade (2 instance) with auto-tune mode ON, plus 5x GTX 750 Ti at default speed (Result in a total of around 1.3Mh/s). The hash rate is kind of low isn't it?
BTW, you can run USB + G-Blade on 1 instance.
April 27, 2014, 07:55:54 AM
ok I finally giving up running CPUMiner on Windows 7 and switched to Raspberry pi for some testing. Let's see if it will stop sending shares after a few minutes. So far they're running for 120+ minutes and doing fine. However I noticed a little drop of mining performance reported from pool side. Anyone using Raspberry pi for mining now? It it normal?
+1 to this. Been running a blade for a few days now with mixed results. Windows seems to top out at bursts over 4MH but averaging slightly under, nowhere near advertised clock speed. Put both halves on separate pools to test results to see if it is the unit in question or an individual blade side.
For RPi, are people using the ZH image, image from another vendor, etc.? Setting up the ZH image right now so I can test with that.
Out of curiosity, what freq are people finding most reliable? I've read through this thread a bit and want to try out the jmordica cgminer fork (see people mentioning 838 freq a few times), but all-in-all the hardware just appears to be underperforming right now and I can't quite crack why due to lacking software support.
I'm using Rasperian with a web based management interface which use CPUMiner. It has been 3 hrs now and pool side reports a more stable but slightly lower hash rate (8.9Mh/s~11Mh/s). I'm running 10x gridseed USB Miner plus a G-blade (2 instance) with auto-tune mode ON, plus 5x GTX 750 Ti at default speed (Result in a total of around 1.3Mh/s). The hash rate is kind of low isn't it?
April 27, 2014, 07:26:58 AM
ok I finally giving up running CPUMiner on Windows 7 and switched to Raspberry pi for some testing. Let's see if it will stop sending shares after a few minutes. So far they're running for 120+ minutes and doing fine. However I noticed a little drop of mining performance reported from pool side. Anyone using Raspberry pi for mining now? It it normal?
+1 to this. Been running a blade for a few days now with mixed results. Windows seems to top out at bursts over 4MH but averaging slightly under, nowhere near advertised clock speed. Put both halves on separate pools to test results to see if it is the unit in question or an individual blade side.
For RPi, are people using the ZH image, image from another vendor, etc.? Setting up the ZH image right now so I can test with that.
Out of curiosity, what freq are people finding most reliable? I've read through this thread a bit and want to try out the jmordica cgminer fork (see people mentioning 838 freq a few times), but all-in-all the hardware just appears to be underperforming right now and I can't quite crack why due to lacking software support.
April 27, 2014, 06:50:09 AM
ok I finally giving up running CPUMiner on Windows 7 and switched to Raspberry pi for some testing. Let's see if it will stop sending shares after a few minutes. So far they're running for 120+ minutes and doing fine. However I noticed a little drop of mining performance reported from pool side. Anyone using Raspberry pi for mining now? It it normal?
April 27, 2014, 02:00:05 AM
10 hours of running new cpuminer now.
27 miners @ 950mhz gives average of 9300khs on poolside. Its less than it should be. 27x400= 10800.
Is this only my cpuminer problem or it should be that low?
Im out of ideas how to increase perfomance of miners which report 300-360khs with that cpuminer.
With cgminer, all miners reported 400-415.
27 miners @ 950mhz gives average of 9300khs on poolside. Its less than it should be. 27x400= 10800.
Is this only my cpuminer problem or it should be that low?
Im out of ideas how to increase perfomance of miners which report 300-360khs with that cpuminer.
With cgminer, all miners reported 400-415.
April 27, 2014, 01:52:08 AM
Switched to bfgminer .. more stable than cgminer
April 26, 2014, 06:18:30 PM
For about 2 weeks, my miners were running on 9600 baud. Ive since upped that to 115200. Made no difference, but Im still using an older cpuminer with one instance each, one worker each.
i'll figure out how to work the new cpuminer, and if not i'll let you guys know.
i'll figure out how to work the new cpuminer, and if not i'll let you guys know.
April 26, 2014, 05:00:07 PM
No difference long term, better to stick to one miner process.
Thanks for answer.
Got it working now with a single minerd for all gridseeds. Hash rate looks to be almost same as with cgminer. Hopefully later it grows even bigger, since many miners will likely clock higher than 950mhz.
I tried running without powered hubs. Looks like unpowered hubs will result with more errors in shares and lower hash rate on average.
Some miners still reporting around 330khs in minerd after couple of hours running. Any idea why it is so? They all should do around 400-415.
It's better to turn off autotune now that you can set the chip frequency, this will lead to a more consistent hashrate.
I quess autotune itself shouldnt decrease perfomance?
Also, do i need to adjust in STM virtual port settings to get more consistant perfomance?
April 26, 2014, 04:26:10 PM
No difference long term, better to stick to one miner process.
Thanks for answer.
Got it working now with a single minerd for all gridseeds. Hash rate looks to be almost same as with cgminer. Hopefully later it grows even bigger, since many miners will likely clock higher than 950mhz.
I tried running without powered hubs. Looks like unpowered hubs will result with more errors in shares and lower hash rate on average.
Some miners still reporting around 330khs in minerd after couple of hours running. Any idea why it is so? They all should do around 400-415.
It's better to turn off autotune now that you can set the chip frequency, this will lead to a more consistent hashrate.
April 26, 2014, 10:49:35 AM
No difference long term, better to stick to one miner process.
Thanks for answer.
Got it working now with a single minerd for all gridseeds. Hash rate looks to be almost same as with cgminer. Hopefully later it grows even bigger, since many miners will likely clock higher than 950mhz.
I tried running without powered hubs. Looks like unpowered hubs will result with more errors in shares and lower hash rate on average.
Some miners still reporting around 330khs in minerd after couple of hours running. Any idea why it is so? They all should do around 400-415.
April 26, 2014, 07:00:52 AM
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.
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.
You should reset your comm port speed back down to 115200... That is the maximum port speed allowed on our GS3355 USB miners. There's no point trying to run higher speeds. It's impossible.
April 26, 2014, 06:32:47 AM
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.
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.
April 26, 2014, 02:09:36 AM
OK, looks like im going to stay on Sandor cpu miner with my 80 miners.
I wonder how is the most efficent way to run them. Perhaps 10 per miner and worker? Or is there any difference at all running 10 per worker/miner or 20 per worker/miner?
Perhaps someone has more experience to share regarding this?
I wonder how is the most efficent way to run them. Perhaps 10 per miner and worker? Or is there any difference at all running 10 per worker/miner or 20 per worker/miner?
Perhaps someone has more experience to share regarding this?
No difference long term, better to stick to one miner process.
Thanks for answer.
Another question. It seems that minerd is perfoming a lot worse that cgminer did, despite of minerd having higher clocks on my gridseeds. Testing with 12 units, cgminer and pool reported around 4.7mhs after few hours. Now with minerd, pool is only reporting around 4.0mhs and minerd reports around 4050/3800khs after 8 hours.
Is this false reading or not? im confused because looks like on every accepted, theres sinlge reading around 402khs for each miner. That should be 12 x 402 = 4824khs or so as a total.
Can usb2 hub become bottleneck with 20+ miners on single usb port?
Thanks again for your good work on this miner. When i finally get all my miners running, im going to donate MINT/DOGE/BTC to you. Please PM me your MINT, DOGE or BTC address.
April 25, 2014, 07:12:22 PM
Works for me! I just wanted confirmation of the question. Thanks 
April 25, 2014, 07:03:10 PM
OK, looks like im going to stay on Sandor cpu miner with my 80 miners.
I wonder how is the most efficent way to run them. Perhaps 10 per miner and worker? Or is there any difference at all running 10 per worker/miner or 20 per worker/miner?
Perhaps someone has more experience to share regarding this?
I wonder how is the most efficent way to run them. Perhaps 10 per miner and worker? Or is there any difference at all running 10 per worker/miner or 20 per worker/miner?
Perhaps someone has more experience to share regarding this?
No difference long term, better to stick to one miner process.
I haven't seen this anywhere but is there a benefit to raising the 'baud rate' of the gridseed port above 115200?
Gridseed spec says it only supports up to 115200, so going above that is pointless.
April 25, 2014, 07:00:05 PM
I haven't seen this anywhere but is there a benefit to raising the 'baud rate' of the gridseed port above 115200?
As I recall, Gridseed spec's the comm port speed to be run at a default speed of 115200 baud.
I am sure this is way more speed than the seed needs. At least a 5 chip seed.
Now, a 40 or 80 chip seed may benefit from it but I don't have it's specs' in front of me so I don't know for sure. Just guessing here.
The benefit of having all comm port FIFO buffers turned OFF is becoming well established! Especially with Sandor111's recent cpuminer upgrades that just flat don't use FIFO buffers in the first place. Just wide open free flowing two way data!
Cool! Jump to: