Topic: [GUIDE] GridSeed 5-Chip USB, Blade & Black Miner Support/Tuning - page 23. (Read 308807 times)
Is there a way to have cpuminer automatically find all of the Gridseed 5-chip devices rather than specify each one via the --gc3355=/dev option?
Weird, on 0.9e just noticed this message before the screen shutdown, spelling may be off:
SIGSEGV Received
Cleanup
then the screen shut down. Reboot and everything is fine, but what's that about?
SIGSEGV Received
Cleanup
then the screen shut down. Reboot and everything is fine, but what's that about?
I've updated the binaries once again (still v0.9e), this should fix the crash.
Does anybody has sandors miner running on a windows server ? i´m getting an erro massage as soon as i start the minred.exe does anybody had the same problem / a solution for it
Weird, on 0.9e just noticed this message before the screen shutdown, spelling may be off:
SIGSEGV Received
Cleanup
then the screen shut down. Reboot and everything is fine, but what's that about?
SIGSEGV Received
Cleanup
then the screen shut down. Reboot and everything is fine, but what's that about?
0.9e ran just fine overnight. Notice that the 5-chips are quirkier than the blades in terms of performance, but it could also be that I'm on a pool with a fixed [higher] difficulty. Otherwise performance is consistent across all devices and hashrate has been the highest sustained ever on these things.
Now I just gotta figure out what ZoomHash is doing about the insane price drop while my order was in processing and we'll be in business.
Now I just gotta figure out what ZoomHash is doing about the insane price drop while my order was in processing and we'll be in business.
Great work sandor111 with 0.9e version.
Blade on Win7 laptop running since last night at 11:30pm no issues or resets.
Is there any way or chance to get a backup pool config setting in the bat file?
I know you have the reset for the Blades if not hashing but after X resets then
go to a backup pool? If you need a unit to test on you can use mine and I can
setup TeamViewer for access?
You sound like me, been trying to re-learn all the good linux stuff to create a script that is solid for restarts and the like. Got a single shutdown on .9e earlier but no rhyme or reason why (wasn't recording logs anymore), otherwise it's beautiful. My two new blades will be very happy there.
0.9e ran just fine overnight. Notice that the 5-chips are quirkier than the blades in terms of performance, but it could also be that I'm on a pool with a fixed [higher] difficulty. Otherwise performance is consistent across all devices and hashrate has been the highest sustained ever on these things.
Now I just gotta figure out what ZoomHash is doing about the insane price drop while my order was in processing and we'll be in business.
Now I just gotta figure out what ZoomHash is doing about the insane price drop while my order was in processing and we'll be in business.
Great work sandor111 with 0.9e version.
Blade on Win7 laptop running since last night at 11:30pm no issues or resets.
Is there any way or chance to get a backup pool config setting in the bat file?
I know you have the reset for the Blades if not hashing but after X resets then
go to a backup pool? If you need a unit to test on you can use mine and I can
setup TeamViewer for access?
Testing the new version... The old one seemed to quit every now and then. Didn't have logs enabled, so I didn't know why. Also, I had a chip who simply didn't step up to the frequency I had programmed for it. Just installed the new version, testing right now.
Nice update Sandor - RE v0.9e - I see blades more stable now, but after time it still falls into the path of not posting work..the 5chips remain good though when that happens.
Trying with the new timeout flag to see if that keeps them going after 1-2 hrs. Will report back if they don't recycle with the flag.
Trying with the new timeout flag to see if that keeps them going after 1-2 hrs. Will report back if they don't recycle with the flag.
I used ./configure CFLAGS="-march=armv6 -mfpu=vfp -mfloat-abi=hard -lncurses" for 0.9e and it's been running for 9hour now on blade.
Thanks to Sandor for fixing those stability errors (he tortured my blade for about 7 hours
with his testing)
Thanks to Sandor for fixing those stability errors (he tortured my blade for about 7 hours
with his testing)Thanks again friend.
Thanks for your work Sandor, going to give the new version a try when I get home.
I tried this to start the good miner on a higher frequency, but when I loaded the TUI they all still showed 850mhz
Im thinking that the --freq flag overrides the -gc3355-freq flag? I thought the more specific one wins in that fight but should I try this instead?
EDIT: This one just defaults them all to 600mhz...
Code:
sudo screen -dmS 0 ./minerd-gc3355 --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2 --gc3355-freq=/dev/ttyACM0:1000 --gc3355-autotune --freq=850 --url=stratum+tcp://useast.wafflepool.com:3333 --userpass=redacted:pass
Im thinking that the --freq flag overrides the -gc3355-freq flag? I thought the more specific one wins in that fight but should I try this instead?
EDIT: This one just defaults them all to 600mhz...
Code:
sudo screen -dmS 0 ./minerd-gc3355 --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2 --gc3355-freq=/dev/ttyACM0:1000,/dev/ttyACM1:845,/dev/ttyACM2:855 --gc3355-autotune
On which version is that? It always picks the most specific frequency, works fine here.
Raspberry Pi, 0.9d.
I guess I should probably update to 0.9e and retest but I thought the only update there was for blades.
Edit: Same behavior on 0.9e.
I used ./configure CFLAGS="-march=armv6 -mfpu=vfp -mfloat-abi=hard -lncurses" for 0.9e and it's been running for 9hour now on blade.
Thanks to Sandor for fixing those stability errors (he tortured my blade for about 7 hours with his testing)
Thanks to Sandor for fixing those stability errors (he tortured my blade for about 7 hours
with his testing)
Sandor, how do I pull an old version from github? I need to revert to an older version. Ever since about 0.9c I get super high rejects, but cpuminer actually only reports a small portion of them, my pool reports a much higher amount. I never had this problem with the original gridseed cpuminer and not with your early versioning. I believe ever since you updated the stratum code to fix a bug, those versions and on give problems.
I get the "debug: job not found" error all the time.
Also what is your advice on compiling for the Pi. Should I.use the cfflags ="03" option or the "March=armv6....." options that Mr Jinx suggested?
I get the "debug: job not found" error all the time.
Also what is your advice on compiling for the Pi. Should I.use the cfflags ="03" option or the "March=armv6....." options that Mr Jinx suggested?
I've been testing the .9e build and it's been crashing multiple times since yesterday. I've been testing various settings and whatnot, and have now switched pools to see if it's a pool issue. What I've found in the debug log was an error encountered: [2014-05-06 09:11:38] stratum_recv_line failed. It happens randomly as well. I've seen it happen in as little as 10 minutes, and as long as a couple hours.
cpuminer log for .9e (I noticed at the bottom there is a stratum error)
https://www.dropbox.com/s/94b7clr695f77up/cpuminer-gc3355-Manicminer.log
Windows Crash report details
https://www.dropbox.com/s/m0puqwsy1e1c35s/crash.txt
Anyone else see something like this?
.9d runs fine, .9e fails with that error - same pool.
cpuminer log for .9e (I noticed at the bottom there is a stratum error)
https://www.dropbox.com/s/94b7clr695f77up/cpuminer-gc3355-Manicminer.log
Windows Crash report details
https://www.dropbox.com/s/m0puqwsy1e1c35s/crash.txt
Anyone else see something like this?
.9d runs fine, .9e fails with that error - same pool.
I tried this to start the good miner on a higher frequency, but when I loaded the TUI they all still showed 850mhz
Im thinking that the --freq flag overrides the -gc3355-freq flag? I thought the more specific one wins in that fight but should I try this instead?
EDIT: This one just defaults them all to 600mhz...
Code:
sudo screen -dmS 0 ./minerd-gc3355 --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2 --gc3355-freq=/dev/ttyACM0:1000 --gc3355-autotune --freq=850 --url=stratum+tcp://useast.wafflepool.com:3333 --userpass=redacted:pass
Im thinking that the --freq flag overrides the -gc3355-freq flag? I thought the more specific one wins in that fight but should I try this instead?
EDIT: This one just defaults them all to 600mhz...
Code:
sudo screen -dmS 0 ./minerd-gc3355 --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2 --gc3355-freq=/dev/ttyACM0:1000,/dev/ttyACM1:845,/dev/ttyACM2:855 --gc3355-autotune
On which version is that? It always picks the most specific frequency, works fine here.
Looks like both version work fine (at least for me).
Is this the RPi or Windows build you were testing? Windows here, with my problems..
For Blade users, I'm quoting this bit of important tuning info again
So you can only set chip_id 0-7
For example, a Blade at ttyACM0/ttyACM1, set chip 3, 11, 19, 27, 35 of one board to 825 MHz:
I forgot that the chip_id can only be half a byte long (0-7) when sending commands to the GC3355 chip, but the chip_id we are seeing from the nonces ranges from 0-39 (= # of chips)
You cannot set the frequency of chip 39, it will overflow the 4 bits. BUT... chip_id 0 is actually referencing chip 0, 8, 16, 24, 32. chip_id 1 is actually referencing chip 1, 9, 17, 25, 33... and so on, they are clusters of 8 chips.
To get the chip_id (to be used in frequency setting), simply do chip_id = chip_id_cpuminer % 8.
So if you set the frequency of chip 0, you will also set it for chip 8, 16 and 32, there is no way around that. This is why I will disable autotune for Blades in the next update.
You cannot set the frequency of chip 39, it will overflow the 4 bits. BUT... chip_id 0 is actually referencing chip 0, 8, 16, 24, 32. chip_id 1 is actually referencing chip 1, 9, 17, 25, 33... and so on, they are clusters of 8 chips.
To get the chip_id (to be used in frequency setting), simply do chip_id = chip_id_cpuminer % 8.
So if you set the frequency of chip 0, you will also set it for chip 8, 16 and 32, there is no way around that. This is why I will disable autotune for Blades in the next update.
So you can only set chip_id 0-7
For example, a Blade at ttyACM0/ttyACM1, set chip 3, 11, 19, 27, 35 of one board to 825 MHz:
Code:
--gc3355-frequency=/dev/ttyACM0:825:3
A gridseed mini I just bought is either overvolted or very lucky.
it's GSD0 on here:
With regard to what you asked earlier it is indeed cold to the touch - but I can't confirm it's overvolted or by how much.
I do have a kind of dumb question for you by the way: what's the code to specify the chip frequency for just the fast unit? Here's the script I have starting the miner now:
I tried this to start the good miner on a higher frequency, but when I loaded the TUI they all still showed 850mhz
Im thinking that the --freq flag overrides the -gc3355-freq flag? I thought the more specific one wins in that fight but should I try this instead?
EDIT: This one just defaults them all to 600mhz...
anyway, thanks again for this great software.
it's GSD0 on here:
With regard to what you asked earlier it is indeed cold to the touch - but I can't confirm it's overvolted or by how much.
I do have a kind of dumb question for you by the way: what's the code to specify the chip frequency for just the fast unit? Here's the script I have starting the miner now:
Code:
sudo screen -dmS 0 ./minerd-gc3355 --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2 --gc3355-autotune --freq=850 --url=stratum+tcp://useast.wafflepool.com:3333 --userpass=redacted:pass
I tried this to start the good miner on a higher frequency, but when I loaded the TUI they all still showed 850mhz
Code:
sudo screen -dmS 0 ./minerd-gc3355 --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2 --gc3355-freq=/dev/ttyACM0:1000 --gc3355-autotune --freq=850 --url=stratum+tcp://useast.wafflepool.com:3333 --userpass=redacted:pass
Im thinking that the --freq flag overrides the -gc3355-freq flag? I thought the more specific one wins in that fight but should I try this instead?
EDIT: This one just defaults them all to 600mhz...
Code:
sudo screen -dmS 0 ./minerd-gc3355 --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2 --gc3355-freq=/dev/ttyACM0:1000,/dev/ttyACM1:845,/dev/ttyACM2:855 --gc3355-autotune
anyway, thanks again for this great software.
Hi sandor,
I don't know if anyone else has this issue but on this version, when checked the miners this morning
they were like super super hot! something that never happened before at same frequency settings
I don't know if anyone else has this issue but on this version, when checked the miners this morning
they were like super super hot! something that never happened before at same frequency settings
I just checked the power meter, and it is still at ~7W/unit, cool to the touch. Probably the effect of overvolting?
well they have always been overvolted.
simple test I did run them on the real old cpuminer single instances at 1200mh and they are cold to the touch,
with latest cpuminer they get more than warm, too hot for it to be good imo
Can anyone with an overvolted Gridseed confirm that this is the case?
Hi sandor,
I don't know if anyone else has this issue but on this version, when checked the miners this morning
they were like super super hot! something that never happened before at same frequency settings
I don't know if anyone else has this issue but on this version, when checked the miners this morning
they were like super super hot! something that never happened before at same frequency settings
I just checked the power meter, and it is still at ~7W/unit, cool to the touch. Probably the effect of overvolting?
well they have always been overvolted.
simple test I did run them on the real old cpuminer single instances at 1200mh and they are cold to the touch,
with latest cpuminer they get more than warm, too hot for it to be good imo
Jump to: