Please check your PM. Below is the topology I suggested for your 20 DMs. The Inside Orico P10-U2 diagram partly explained why leave one bottom port empty.
Thanks dmsp. After reconfiguring my DMs across the hubs, my rig has been stable for 48 hours. I'm happy. Just to be clear to everyone, if you fill an Orico hub with 9 DMs, it is critical that you leave the correct port depopulated, as per CruzCoins' and dmsp's diagrams. If you depopulate the wrong port (which I did) you will see stability problems. Thanks again for the great support! |
|
|
|
|
I have a quick set up question. I noticed that in your pictures, you have 8 units in a column on its side with a single fan at the top. Several of these modules are mounted in a framework.
I plan to deploy my 10 unit kit in a rack in an air conditioned server closet. I'm thinking of a similar layout, but with two columns of 5 units each with a fan on the end of each column. I can deploy these such that the two intake fans will have cold air blowing at them from the AC units.
Will that set up provide enough cooling for these units? I suspect that since your pictures show 8 units that the answer is yes, but I just want to be sure.
Thanks in advance for your help.
|
|
|
|
My Pi will come preloaded with cgminer and a Scripta interface. I will be posting this image on the web so any one can use it. If you can get your own pi then load this image on to it. If you need a PI with this image preloaded just PM me.  Thanks for getting back to me Atari. I'll probably set up my Pi by myself. But if I run into problems, I'll ask for the image. |
|
|
|
In the last few days, I see sporadic failures where one or more DM 2s get disabled...
Two more just failed: [2014-03-18 09:40:44] DM3: Comms error (rerr=-1 amt=0)
[2014-03-18 09:40:44] DM 3 failure, disabling!
[2014-03-18 09:40:44] Thread 3 being disabled
--
[2014-03-18 09:41:03] DM1: Comms error (rerr=-1 amt=0)U:40.5/m
[2014-03-18 09:41:03] DM 1 failure, disabling!
[2014-03-18 09:41:03] Thread 1 being disabled
--
Failed devices:
[2014-03-18 07:11:28] DM1: Found at 1:28-i0
[2014-03-18 07:11:28] DM3: Found at 1:26-i0
This time I used "lsusb -t" to list the devices before the failure and after. Here's the list from before: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=vend., Driver=smsc95xx, 480M
|__ Port 3: Dev 4, If 0, Class=hub, Driver=hub/4p, 480M
|__ Port 4: Dev 5, If 0, Class=hub, Driver=hub/7p, 480M
|__ Port 2: Dev 6, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 2: Dev 6, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 3: Dev 7, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 3: Dev 7, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 5: Dev 8, If 0, Class=hub, Driver=hub/4p, 480M
|__ Port 2: Dev 10, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 2: Dev 10, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 3: Dev 11, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 3: Dev 11, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 4: Dev 12, If 0, Class=hub, Driver=hub/7p, 480M
|__ Port 1: Dev 16, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 1: Dev 16, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 2: Dev 17, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 2: Dev 17, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 3: Dev 18, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 3: Dev 18, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 4: Dev 19, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 4: Dev 19, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 5: Dev 20, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 5: Dev 20, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 6: Dev 21, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 6: Dev 21, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 7: Dev 22, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 7: Dev 22, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 6: Dev 9, If 0, Class=hub, Driver=hub/4p, 480M
|__ Port 2: Dev 13, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 2: Dev 13, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 4: Dev 15, If 0, Class=hub, Driver=hub/7p, 480M
|__ Port 1: Dev 23, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 1: Dev 23, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 2: Dev 24, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 2: Dev 24, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 3: Dev 25, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 3: Dev 25, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 4: Dev 26, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 4: Dev 26, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 5: Dev 27, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 5: Dev 27, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 6: Dev 28, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 6: Dev 28, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 7: Dev 29, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 7: Dev 29, If 1, Class=vend., Driver=usbfs, 480M
And here's after the failure: 1-1.3.4.6.4.4:1.0: No such file or directory
1-1.3.4.6.4.4:1.1: No such file or directory
1-1.3.4.6.4.6:1.0: No such file or directory
1-1.3.4.6.4.6:1.1: No such file or directory
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=vend., Driver=smsc95xx, 480M
|__ Port 3: Dev 4, If 0, Class=hub, Driver=hub/4p, 480M
|__ Port 4: Dev 5, If 0, Class=hub, Driver=hub/7p, 480M
|__ Port 2: Dev 6, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 2: Dev 6, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 3: Dev 7, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 3: Dev 7, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 5: Dev 8, If 0, Class=hub, Driver=hub/4p, 480M
|__ Port 2: Dev 10, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 2: Dev 10, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 3: Dev 11, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 3: Dev 11, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 4: Dev 12, If 0, Class=hub, Driver=hub/7p, 480M
|__ Port 1: Dev 16, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 1: Dev 16, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 2: Dev 17, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 2: Dev 17, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 3: Dev 18, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 3: Dev 18, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 4: Dev 19, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 4: Dev 19, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 5: Dev 20, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 5: Dev 20, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 6: Dev 21, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 6: Dev 21, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 7: Dev 22, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 7: Dev 22, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 6: Dev 9, If 0, Class=hub, Driver=hub/4p, 480M
|__ Port 2: Dev 13, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 2: Dev 13, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 4: Dev 15, If 0, Class=hub, Driver=hub/7p, 480M
|__ Port 1: Dev 23, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 1: Dev 23, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 2: Dev 24, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 2: Dev 24, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 3: Dev 25, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 3: Dev 25, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 4: Dev 26, If 0, Class=vend., Driver=, 480M
|__ Port 4: Dev 26, If 1, Class=vend., Driver=, 480M
|__ Port 5: Dev 27, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 5: Dev 27, If 1, Class=vend., Driver=usbfs, 480M
|__ Port 6: Dev 28, If 0, Class=vend., Driver=, 480M
|__ Port 6: Dev 28, If 1, Class=vend., Driver=, 480M
|__ Port 7: Dev 29, If 0, Class=vend., Driver=usbfs, 480M
|__ Port 7: Dev 29, If 1, Class=vend., Driver=usbfs, 480M
Basically device 26 and 28 have fallen over. I'm not entirely sure how to correlate the devices that have been disabled to the physical units. However it sure seems like the failed devices are always on the same hub, and with high dev numbers. Another oddity is how the DMs are assigned in the tree above. My physical layout is such that there's one "master" that's hooked to the Pi. The other two hubs are hooked to the master. I've got 2 DMs in the master, and 9 on each sub-hub. So why is it that some of the DM devices (which I think are identified by "Class=vend., Driver=usbfs") appear directly on a sub-hub, and some appear to be in a hub within the hub? Maybe the ports on the Orico hub are all the same? Some are sub-divided internally, apparently. Not sure if that's relevant or not. I'm starting to think that maybe I should pull a DM or two from each sub-hub and plug them into the main one. But I'm just guessing here. If anyone has any suggestions, I'd appreciate it. |
|
|
|
In the last few days, I see sporadic failures where one or more DM 2s get disabled. I saw three disabled yesterday. The latest one just got disabled this morning: [2014-03-17 06:41:28] DM0: Comms error (rerr=-1 amt=0)
(5s):919.5K (avg):1.362Mh/s | A:1443792 R:2288 HW:107 WU:22.2/m
[2014-03-17 06:41:28] DM 0 failure, disabling!
[2014-03-17 06:41:28] Thread 0 being disabled
[2014-03-17 06:41:33] Submitting share a84cc765 to pool 0
[2014-03-17 06:41:28] DM 0 failure, disabling!
[2014-03-17 06:41:28] Thread 0 being disabled
I'm running the DM cgminer under Raspberry Pi on Orico hubs, with no more than 9 per hub. The rack is in a server closet that's kept cool. I have two USB fans (connected to a separate hub that's not connected to the Raspberry Pi) to move air through the units. Any ideas as to how I can diagnose and fix this? Maybe there's an update to the cgminer software? Once this happens, is there anything that I can do other than just rebooting? When I just bounce cgminer, the DMs don't necessarily come back. In fact, I just bounced cgminer and lost 6 devices. When I woke up this morning, I found that three more DM 2s had failed. Here's the log entries (including the discovery of the USB devices, in case that helps): [2014-03-17 07:14:02] [1;32mdualminer Detect: Test Success at 1:28-i0: get 00050cdd, should: 00050cdd[0m
[2014-03-17 07:14:02] DM1: Found at 1:28-i0
[2014-03-17 07:14:02] [1;32mdualminer Detect: Test Success at 1:27-i0: get 00050cdd, should: 00050cdd[0m
[2014-03-17 07:14:02] DM2: Found at 1:27-i0
[2014-03-17 07:14:02] [1;32mdualminer Detect: Test Success at 1:26-i0: get 00050cdd, should: 00050cdd[0m
[2014-03-17 07:14:02] DM3: Found at 1:26-i0
[2014-03-17 22:57:48] DM2: Comms error (rerr=-1 amt=0)
[2014-03-17 22:57:49] DM 2 failure, disabling!
[2014-03-17 22:57:49] Thread 2 being disabled
[2014-03-17 23:10:23] DM1: Comms error (rerr=-1 amt=0)
[2014-03-17 23:10:23] DM 1 failure, disabling!
[2014-03-17 23:10:23] Thread 1 being disabled
[2014-03-17 23:10:24] DM3: Comms error (rerr=-1 amt=0)
[2014-03-17 23:10:24] DM 3 failure, disabling!
[2014-03-17 23:10:24] Thread 3 being disabled
If no one has any suggestions, I'll contact DualMiner support. |
|
|
|
Are there still Sunday payouts for balances of >= .001 BTC? Just wondering since I didn't seem to get one yesterday. Thanks!
Yes, there are. If you expected it on Sun/Mon night, then remember that it's on Sunday at 01:35am, so it's Sat/Sun night. If you still think you should get one but didn't get, then please let me know your username and I'll check. I'm in the same boat. I had a "Ready For Payout" balance of over 0.001 on Saturday and was expecting the payout sometime Sunday. But I also have less than a week of mining with you. Maybe the algorithm is at least a week and over 0.001 is paid out on Sunday? Note that I'm planning on coming back to CleverMining when the promo from you-know-who is over anyway, so this is no big deal. But if you're not aware of a general problem with the Sunday payout and you want to investigate, let me know and I'll PM you my user name. It seems really unlikely. 4287 users were paid their < 0.01 balances at March 16, 2014 1:35am - 1:37am (as an addition to a regular >= 0.01 payout to 2013 users five minutes earlier). I already checked juanbond account and he simply didn't have 0.001 BTC on Sat/Sun night as his entire balance was paid out 24h before on a regular payout and he didn't accumulate 0.001 since then. We had some higher than usual unexchanged balance over on Sat/Sun night and it is probably the reason why some of your balances were unexchanged, so not ready for payouts. I remember looking at my account numbers and there was still some play in the Immature and Unexchanged piles some time on Saturday. There's still a very small amount in Unexchanged. It's possible that I wasn't quite over the 0.001 at the exact payout moment. I don't think this is work investigating in my case. It's not a lot of money (obviously) and like I said, I plan to come back. Thanks anyway for your response. Keep up the good work, and profitability  |
|
|
|
Are there still Sunday payouts for balances of >= .001 BTC? Just wondering since I didn't seem to get one yesterday. Thanks!
Yes, there are. If you expected it on Sun/Mon night, then remember that it's on Sunday at 01:35am, so it's Sat/Sun night. If you still think you should get one but didn't get, then please let me know your username and I'll check. I'm in the same boat. I had a "Ready For Payout" balance of over 0.001 on Saturday and was expecting the payout sometime Sunday. But I also have less than a week of mining with you. Maybe the algorithm is at least a week and over 0.001 is paid out on Sunday? Note that I'm planning on coming back to CleverMining when the promo from you-know-who is over anyway, so this is no big deal. But if you're not aware of a general problem with the Sunday payout and you want to investigate, let me know and I'll PM you my user name. |
|
|
|
wooooo 127%
Yeah, I noticed that too. Slightly better than the ghash.io deal. Keep it coming CleverMining and I might switch back before the ghash.io promotion is over. |
|
|
|
./configure –enable-dualminer –enable-scrypt –disable-opencl –prefix=$DIR_PATH/
The issue is that $DIR_PATH is not defined. velvethammer2 , I assume you were following the instructions on the DM support web site? I think that the $DIR_PATH in those instructions are a typo. CruzCoins' instructions on this thread are correct though. Also, you could consider dropping the –prefix option altogether if you want to install the cgminer in the default location (which is what I did; you can see my post on the subject if you're interested). HTH... |
|
|
|
|
Hi Atari,
I placed my order without a controller because I prefer to use a Raspberry Pi. But that was a little before you started offering Raspberry Pi as an option.
When you ship with a Raspberry Pi now, is it preconfigured to just work out of the box? Or do you point us at instructions for configuring it?
Note that I'm perfectly comfortable buying my own Raspberry Pi and configuring it. In fact, I kind of prefer to do that because there are specific ways that I like to set things up.
I know there's a thread about setting up Gridseed rigs. Should I just follow those instructions, or do you have specific instructions? Maybe you've got a preferred version of cgminer and a web frontend that you can recommend?
I'd like to preconfigure my the Raspberry Pi so that it's ready before I receive the shipment.
Thanks in advance for some direction.
|
|
|
|
In the last few days, I see sporadic failures where one or more DM 2s get disabled. I saw three disabled yesterday. The latest one just got disabled this morning: [2014-03-17 06:41:28] DM0: Comms error (rerr=-1 amt=0)
(5s):919.5K (avg):1.362Mh/s | A:1443792 R:2288 HW:107 WU:22.2/m
[2014-03-17 06:41:28] DM 0 failure, disabling!
[2014-03-17 06:41:28] Thread 0 being disabled
[2014-03-17 06:41:33] Submitting share a84cc765 to pool 0
[2014-03-17 06:41:28] DM 0 failure, disabling!
[2014-03-17 06:41:28] Thread 0 being disabled
I'm running the DM cgminer under Raspberry Pi on Orico hubs, with no more than 9 per hub. The rack is in a server closet that's kept cool. I have two USB fans (connected to a separate hub that's not connected to the Raspberry Pi) to move air through the units. Any ideas as to how I can diagnose and fix this? Maybe there's an update to the cgminer software? Once this happens, is there anything that I can do other than just rebooting? When I just bounce cgminer, the DMs don't necessarily come back. In fact, I just bounced cgminer and lost 6 devices. |
|
|
|
I'm a newcomer to ghash.io. And probably a short timer too, after the promo ends One limitation I'm running into is that they only support automatic payouts for BTC. But like everyone else looking for the promo reward, I'm mining LTC. I asked their support about this and they said that I should make a feature request. So I did. Who knows if it will be up voted or not. So how are people moving their coin off the cex.io exchange? Are you just withdrawing LTC manually and paying their 0.001 LTC fee? That's pretty cheap. Or maybe you can configure BTC auto payout, then exchange LTC for BTC? I don't know if that works, or if auto payout only affects BTC that has been actually mined. Any suggestions for moving coin off of cex.io? FYI, I know that I have to wait 48 hours from setting up my account before withdrawing. No biggie. |
|
|
|
....because they are mining using all that hashpower for themselves to cover their losses  LOL! What a nasty thought... which pool should we move for a while?
I was using clevermining and going to return there as soon as this promotion is over Yeah, I was on clevermining too. When their profitability tanked the other day I went looking for alternatives and happened to see the ghash.io promotion. So I switched. Now ghash.io has crapped out too. It's like going from one burning building to another  So now I'm back at clevermining, because they worked around their hardware problem and are back above LTC profitability (although not by that much). When ghash.io gets their act together, I'll probably come back, but only till the promotion ends. I'm new to this hobby, so my experience is very limited now. But it sure seems like these pool operators could stand to grow up and implement some services best practices, like reasonable notification, hardware failover, etc. |
|
|
|
I'm out of this pool till this stuck block nonsense gets figured out.
FYI, I wrote to their support about this. They know about it and they're working on it, but they couldn't provide an ETA on a fix. |
|
|
|
|
I'm out of this pool till this stuck block nonsense gets figured out.
|
|
|
|
|
Something weird is going on either with their stats or the pool itself. I keep seeing the same block 531801 being worked on with no rewards. Also, I'm seeing a bunch of these entries in my local cgminer log:
[2014-03-15 10:27:54] Rejected 77fcba88 Diff 32/32 DM 12 pool 0 (Job not found)
[2014-03-15 10:27:54] Rejected 3114dcb7 Diff 85/32 DM 0 pool 0 (Job not found)
[2014-03-15 10:27:54] Rejected c6e41520 Diff 62/32 DM 18 pool 0 (Job not found)
[2014-03-15 10:27:54] Rejected b935be65 Diff 119/32 DM 0 pool 0 (Job not found)
[2014-03-15 10:27:54] Rejected 0a0aa602 Diff 54/32 DM 0 pool 0 (Job not found)
Now it looks like block 531801 finally finished up, so maybe the problem is resolved. But I've never seen this kind of thing before. Of course I'm new to both mining and ghash.io so maybe I'm just missing something.
|
|
|
|
|
Quick question. Do the power supplies in the kit (both for the 5 chip units and the USB hub) support higher line voltages? I'm considering deploying at a colocation site where the AC line voltage is 208.
Thanks in advance.
|
|
|
|
|
I already have some Dual Miners running under a Raspberry Pi using their version of cgminer and mineninja.
Would it be possible for me to use the same Raspberry Pi to control the 10 piece grid seed kit?
If so, can you tell me what's involved? Maybe I'd have to run two different cgminers on the same system.
|
|
|
|
From my experience as long as your error are spread about, it seems to be a reasonable/expected rate currently. If you have a spare hub it may not be a bad idea to separate your DMs from fans that may pull lots of energy/create lots of vibration.
Thanks CruzCoins. I think I'll move the fans anyway, mainly because I want to be able to more easily turn them on and off. If that also happens to reduce the error rate, then that's icing on the cake. Otherwise I'll just keep an eye out on the error rate to make sure it's uniform and not rising dramatically. |
|
|
|
The HW error is expected, especially, when DM works above 850Mhz.
The HW error means a returned nonce result does NOT meet the mining target requirement (if you know some mining theory) . This could happen in some cases:
1. The chip could do a wrong calculation. If it is overclocked, the chip could generate more error. That's why 850MHz will give more errors than 800Mhz.
2. Some errors could happen in the communication between DM device and cgminer. Something like uart buffer overflow.
Since higher clock frequency could introduce instability of the electronic signal, most of HW error is caused by the first reason.
HW error is different to the reject error. Reject error is caused by mining pool. If a new block had been generated and DM was still working on previous job, some nonces of previous job maybe still queued in a buffer of cgminer. If cgminer submit these old result to pool, the pool will reject them.
Thanks for getting back to me dualminer_3. I realize that rejects are different than hardware errors. And I also realize that some number of hardware errors is expected with Dual Miners. I'm just interested in whether I'm seeing an expected hardware error rate. I've been running cgminer for 20 hours without the "--dualminer-pll 850" command line and have had a total of 53 errors across 20 units. If I assume that this rate is fairly consistent, then I can estimate that I would see an average of 3 hardware errors per unit per day. Is that a reasonable and expected rate? If it isn't, then what can I do to diagnose and fix this? Remember that I mentioned that I have two fans plugged into the same USB hubs where I have Dual Miners. Could these be making electrical noise or cause power fluctuations? If so, I can move them to a dedicated hub. Thanks in advance for any further advice you might have. |
|
|
|
|
Show Posts
