|
reactor
|
 |
May 05, 2014, 06:04:50 PM |
|
I think I may add another command line parameter: --gc3355-timeout=X
This will kill the cpuminer process when one of the miners hasn't produced a hash in X seconds.
So it will be possible to run a script that loops forever and doesn't require constant babysitting.
That would be great! I think you are onto something, friend.  While I prefer to keep all devices within one process for viewing purposes, I'd happily have 9 instances of cpuminer running wild with restart-ability enabled based on a timeout if it meant I didn't have to have a ssh window open all day.  |
|
|
|
|
|
sandor111
|
|
May 05, 2014, 06:52:07 PM
Last edit: May 05, 2014, 07:07:11 PM by sandor111 |
|
BTW, I think I may have found the reason why Blades are so unstable on cpuminer (hint: frequency).
Does anyone want to lend me SSH access to a Blade to test on so I can confirm and fix this?
Edit: Still need access.
|
|
|
|
|
surgexvb
|
|
May 05, 2014, 06:59:40 PM |
|
Just got my Pi in the mail this morning. I managed to install RASPBIAN and am able to work in it and SSH to it, so I am part way there. Can anyone point me in the direction for instructions on loading the latest CPUminer onto the Pi and getting it to run.
If you want to compile it yourself on a Pi use this: apt-get install -y build-essential libtool libcurl4-openssl-dev libncurses5-dev libudev-dev autoconf automake screen
git clone https://github.com/siklon/cpuminer-gc3355
cd cpuminer-gc3355
sh ./autogen.sh
./configure CFLAGS="-march=armv6 -mfpu=vfp -mfloat-abi=hard"
make Thanks Mr. Jinx! Can you explain these config commands? Where did you see that this is correct for the Pi. Sandor, can you chime in on this?? |
|
|
|
|
surgexvb
|
|
May 05, 2014, 07:03:55 PM |
|
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"
Rowan, I had the same issue, except mine was about 25% rejected. I was running on a Raspberry Pi. I updated to the latest firmware and made sure everything else was up to date, recompiled newest cpuminer with the config commands Mr Jinx suggested, and now it seems to be back to normal. |
|
|
|
RowanX
Member
 Offline
Activity: 86
Merit: 10
|
|
May 05, 2014, 07:12:49 PM |
|
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"
Rowan, I had the same issue, except mine was about 25% rejected. I was running on a Raspberry Pi. I updated to the latest firmware and made sure everything else was up to date, recompiled newest cpuminer with the config commands Mr Jinx suggested, and now it seems to be back to normal. 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. |
|
|
|
|
|
reactor
|
|
May 05, 2014, 07:24:41 PM |
|
BTW, I think I may have found the reason why Blades are so unstable on cpuminer (hint: frequency).
Does anyone want to lend me SSH access to a Blade to test on so I can confirm and fix this?
Edit: Still need access.
Sorry, could give access if I were at home but can't get through the wall to access that from offsite. Also, just noticed the point one of the 5-chips cut out my output read: 0: UART write error 0: Terminating GC3355 chip mining thread After this it was no longer in the new block work dispatch a few minutes later. Now hashrate is slowly dwindling but the device "looks" alive, although I know the UART error is the kiss of death I was seeing yesterday. Here's some of the output after the restart: [2014-05-05 19:26:31] 1@3: Work_id differs (e59bbc40 != e59bbf04) [2014-05-05 19:26:41] 4@2: Work_id differs (e59bbc40 != e59bbf04) [2014-05-05 19:26:46] 3@1: Work_id differs (e59bbc40 != e59bbf04) [2014-05-05 19:26:48] 6@12: Work_id differs (e59bbc40 != e59bbf04) [2014-05-05 19:26:55] 6@23: Work_id differs (e59bbc40 != e59bbf04) [2014-05-05 19:27:01] 6@4: Work_id differs (e59bbc40 != e59bbf04) [2014-05-05 19:27:04] 4@1: Work_id differs (e59bbc40 != e59bbf04) [2014-05-05 19:27:15] Stratum connection timed out [2014-05-05 19:27:15] Stratum connection interrupted [2014-05-05 19:27:16] Failed to get Stratum session id [2014-05-05 19:27:16] Stratum difficulty set to 800 [2014-05-05 19:27:16] New job_id: 1454 Diff: 800 [2014-05-05 19:27:16] Stratum detected new block [2014-05-05 19:27:16] 4: Dispatching new work to GC3355 cores (0xe614d2e1) [2014-05-05 19:27:16] 1: Dispatching new work to GC3355 cores (0xe614d2e1) [2014-05-05 19:27:16] 0: Dispatching new work to GC3355 cores (0xe614d2e1) [2014-05-05 19:27:16] 0: UART write error [2014-05-05 19:27:16] 3: Dispatching new work to GC3355 cores (0xe614d2e1) [2014-05-05 19:27:16] 0: Terminating GC3355 chip mining thread [2014-05-05 19:27:16] 6: Dispatching new work to GC3355 cores (0xe614d2e1) [2014-05-05 19:27:16] 2: Dispatching new work to GC3355 cores (0xe614d2e1) [2014-05-05 19:27:16] 5: Dispatching new work to GC3355 cores (0xe614d2e1) Going to throw a full reboot to see if all seven come back again. |
|
|
|
|
|
surgexvb
|
|
May 05, 2014, 07:25:49 PM |
|
Looks like I spoke too soon. After about 15 minutes of hashing I start getting massive rejects. Pool shows 15% rejected right now.
These are the rejects I get:
DEBUG: reject reason: Job 'c907' not found
|
|
|
|
|
|
|
wolfey2014
|
|
May 05, 2014, 07:51:44 PM |
|
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"
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 have to ask. Have you tried some simple solutions first? Like, running at a higher difficulty rating? Does your pool offer one? If not, I'd try another pool that does. Also, depending on your platform, comm port FIFO buffers might need to be turned OFF.... Just a couple thoughts. I don't see reports of others having the same problem you are the last couple days so..... Good luck! |
I Modify Miners Professionally! PM me for details!
|
|
|
|
wolfey2014
|
|
May 05, 2014, 08:14:26 PM |
|
There is a brand new firmware upgrade for the Blade and all other Gridseed models.
You can find it at the Hashra support link on the main site.
They're saying that they now offer multiple speed settings for your hardware and that the magic clock is 838 when using their latest firmware on your blade.
This may very well cure what ails your hardware.
Just thought you guys would like to know.
They're also stating that the release date of their Lunar Lander has been moved up to the 31st of this month!
Hope this helps!
|
I Modify Miners Professionally! PM me for details!
|
|
|
|
tc61
|
|
May 05, 2014, 08:32:12 PM |
|
Wolfey I think that firmware is only for the RasPI right? I'm using windows still the same issue.
TC
|
|
|
|
|
RowanX
Member
Offline
Activity: 86
Merit: 10
|
|
May 05, 2014, 09:02:30 PM |
|
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"
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 have to ask. Have you tried some simple solutions first? Like, running at a higher difficulty rating? Does your pool offer one? If not, I'd try another pool that does. Also, depending on your platform, comm port FIFO buffers might need to be turned OFF.... Just a couple thoughts. I don't see reports of others having the same problem you are the last couple days so..... Good luck! 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. |
|
|
|
|
|
sandor111
|
|
May 05, 2014, 09:33:59 PM |
|
BTW, I think I may have found the reason why Blades are so unstable on cpuminer (hint: frequency).
Does anyone want to lend me SSH access to a Blade to test on so I can confirm and fix this?
Edit: Still need access.
Sorry, could give access if I were at home but can't get through the wall to access that from offsite. Also, just noticed the point one of the 5-chips cut out my output read: 0: UART write error 0: Terminating GC3355 chip mining thread After this it was no longer in the new block work dispatch a few minutes later. Now hashrate is slowly dwindling but the device "looks" alive, although I know the UART error is the kiss of death I was seeing yesterday. Here's some of the output after the restart: [2014-05-05 19:26:31] 1@3: Work_id differs (e59bbc40 != e59bbf04) [2014-05-05 19:26:41] 4@2: Work_id differs (e59bbc40 != e59bbf04) [2014-05-05 19:26:46] 3@1: Work_id differs (e59bbc40 != e59bbf04) [2014-05-05 19:26:48] 6@12: Work_id differs (e59bbc40 != e59bbf04) [2014-05-05 19:26:55] 6@23: Work_id differs (e59bbc40 != e59bbf04) [2014-05-05 19:27:01] 6@4: Work_id differs (e59bbc40 != e59bbf04) [2014-05-05 19:27:04] 4@1: Work_id differs (e59bbc40 != e59bbf04) [2014-05-05 19:27:15] Stratum connection timed out [2014-05-05 19:27:15] Stratum connection interrupted [2014-05-05 19:27:16] Failed to get Stratum session id [2014-05-05 19:27:16] Stratum difficulty set to 800 [2014-05-05 19:27:16] New job_id: 1454 Diff: 800 [2014-05-05 19:27:16] Stratum detected new block [2014-05-05 19:27:16] 4: Dispatching new work to GC3355 cores (0xe614d2e1) [2014-05-05 19:27:16] 1: Dispatching new work to GC3355 cores (0xe614d2e1) [2014-05-05 19:27:16] 0: Dispatching new work to GC3355 cores (0xe614d2e1) [2014-05-05 19:27:16] 0: UART write error [2014-05-05 19:27:16] 3: Dispatching new work to GC3355 cores (0xe614d2e1) [2014-05-05 19:27:16] 0: Terminating GC3355 chip mining thread [2014-05-05 19:27:16] 6: Dispatching new work to GC3355 cores (0xe614d2e1) [2014-05-05 19:27:16] 2: Dispatching new work to GC3355 cores (0xe614d2e1) [2014-05-05 19:27:16] 5: Dispatching new work to GC3355 cores (0xe614d2e1) Going to throw a full reboot to see if all seven come back again. UART write error = faulty or loose USB cable/connection/hub. |
|
|
|
|
wolfey2014
|
|
May 05, 2014, 10:20:42 PM |
|
Wolfey I think that firmware is only for the RasPI right? I'm using windows still the same issue.
TC
Sorry. I'm not a Raspi user. But I believe that's what it says at the support page on Hashra's website. Have a looksee....  |
I Modify Miners Professionally! PM me for details!
|
|
|
|
wolfey2014
|
|
May 05, 2014, 10:29:32 PM |
|
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"
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 have to ask. Have you tried some simple solutions first? Like, running at a higher difficulty rating? Does your pool offer one? If not, I'd try another pool that does. Also, depending on your platform, comm port FIFO buffers might need to be turned OFF.... Just a couple thoughts. I don't see reports of others having the same problem you are the last couple days so..... Good luck! 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. Gotcha! I'm not a Blade user nor will I probably ever be given what's coming down the pipe in a few weeks. I'm also not using the latest cpuminer yet! Glad I'm waiting to see what else shakes lose before I dive in. I'm still using Ver 2.3.2 which is working rock steady. One thing I just changed today was I removed the autotune command and just put all my miners at 1175 which seems to have helped in a few different ways i.e. increased and or improved pool side stats. It's using less overhead now to run the show so.... maybe this will help. Who knows? Good luck and God speed to a solution for your wasted hashes! Wolfey2014 |
I Modify Miners Professionally! PM me for details!
|
|
|
|
reactor
|
|
May 05, 2014, 10:59:05 PM |
|
BTW, I think I may have found the reason why Blades are so unstable on cpuminer (hint: frequency).
Does anyone want to lend me SSH access to a Blade to test on so I can confirm and fix this?
Edit: Still need access.
Sorry, could give access if I were at home but can't get through the wall to access that from offsite. Also, just noticed the point one of the 5-chips cut out my output read: 0: UART write error 0: Terminating GC3355 chip mining thread After this it was no longer in the new block work dispatch a few minutes later. Now hashrate is slowly dwindling but the device "looks" alive, although I know the UART error is the kiss of death I was seeing yesterday. Here's some of the output after the restart: [blah] Going to throw a full reboot to see if all seven come back again. UART write error = faulty or loose USB cable/connection/hub. Thanks for confirming this. Now since the 5-chips look the same running vs. not running I get to play the game of which port/plug/unit is it. BTW - Since reconfiguration and on .9d the blades have been steady. There is still a bit of a variance in hashrate: GSD 3 | 850 MHz | 2766.8/2806.6 KH/s | A: 663 R: 3 H: 10 GSD 4 | 850 MHz | 2604.8/2528.4 KH/s | A: 626 R: 1 H: 90 GSD 5 | 850 MHz | 3024.4/2863.0 KH/s | A: 726 R: 2 H: 2 GSD 6 | 850 MHz | 2579.9/2740.2 KH/s | A: 619 R: 2 H: 26 But this has been my experience with all the Gridseed stuff, no two units are exactly the same. |
|
|
|
|
|
sandor111
|
|
May 05, 2014, 11:18:59 PM |
|
Do no use autotune on the Blades.
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, 32. chip_id 1 is actually referencing chip 1, 9, 17, 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.
Instead of killing cpuminer when a Blade is not submitting shares, it will send the reset command to the Blade, which is effectively the same as restarting cpuminer. I will push the code soon, still testing it.
Thanks a lot to Icemoment for lending his Blade to test, I wouldn't have concluded this without him.
|
|
|
|
|
reactor
|
|
May 05, 2014, 11:57:12 PM |
|
Do no use autotune on the Blades.
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, 32. chip_id 1 is actually referencing chip 1, 9, 17, 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.
Instead of killing cpuminer when a Blade is not submitting shares, it will send the reset command to the Blade, which is effectively the same as restarting cpuminer. I will push the code soon, still testing it.
Thanks a lot to Icemoment for lending his Blade to test, I wouldn't have concluded this without him.
Sorry to ask the stupid question, but you mentioned "send the reset command to the Blade", would this method/command work for the 5-chips too? |
|
|
|
|
|
sandor111
|
|
May 06, 2014, 01:18:09 AM |
|
Do no use autotune on the Blades.
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, 32. chip_id 1 is actually referencing chip 1, 9, 17, 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.
Instead of killing cpuminer when a Blade is not submitting shares, it will send the reset command to the Blade, which is effectively the same as restarting cpuminer. I will push the code soon, still testing it.
Thanks a lot to Icemoment for lending his Blade to test, I wouldn't have concluded this without him.
Sorry to ask the stupid question, but you mentioned "send the reset command to the Blade", would this method/command work for the 5-chips too? It would. |
|
|
|
|
|
|
