Bitcoin Forum
July 11, 2024, 02:07:24 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: First mining setup, two major issues. Assistance please  (Read 1098 times)
Squeeky4711 (OP)
Newbie
*
Offline Offline

Activity: 25
Merit: 0


View Profile
September 14, 2013, 05:12:35 AM
 #1

I received my first Erupters and USB hubs today, and running off Minepeon.  Hub and Wifi connected directly to Pi.  I have the other two hubs bridging off the MCM powered hub.

Cgminer will boot fine, grab an IP, and start hashing with only 10 miners.  However if I plug the single units directly they are picked up.

Here is where it's crazy the 10 will hash away for about 2 minutes then stop reading 0.0 mh/s.  Meanwhile Minepeon only shows 10 devices, with no activity.

I am a newbie so this could be something simple, but if someone could assist it would be great.

Squeeky4711
RicRock
Sr. Member
****
Offline Offline

Activity: 290
Merit: 250



View Profile
September 14, 2013, 05:14:18 AM
 #2


What are the other 2 hubs?

How many do you have total?
Squeeky4711 (OP)
Newbie
*
Offline Offline

Activity: 25
Merit: 0


View Profile
September 14, 2013, 05:22:12 AM
 #3

3x MCM 7 port hubs total, each plugged in to their own 3.5a adapter. 

Then second and third hub are plugged into ports 6-7 of first hub.
Artic fan in port 1 of the fisrt hub as well.

Erupters in ports 2-5 on Hub1
Erupters on ports 1-5 on Hub2 & 3

Ports 4-5 of Hub 2 & 3 are not detected and LEDs stay solid.

The hashing stopping after 2 minute is even worse, I'm all excited to sit and wait  Smiley  but I'm not even hashing.

Squeeky4711 (OP)
Newbie
*
Offline Offline

Activity: 25
Merit: 0


View Profile
September 14, 2013, 05:28:44 AM
Last edit: September 14, 2013, 05:47:08 AM by Squeeky4711
 #4

https://docs.google.com/file/d/0Bw1XF4HYW9I6QXFCd1F1cWRqU1E/edit?usp=sharing
https://docs.google.com/file/d/0Bw1XF4HYW9I6Qjg1YWM3Zjd0TUk/edit?usp=sharing

Update*  After about 15 minutes all the Erupters LEDs went solid and not response from LCD input  

Played around with moving fan position, got it read upto 13, but hash rate was still only 3.2-3.3 rate ( 10x Erupters).  It then crapped out after a little over a minute. 

The following is my USB tree:

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
        |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 4                   80M
        |__ Port 2: Dev 4, If 0, Class=Vendor Specific Class, Driver=rtl8192cu,                    480M
        |__ Port 3: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 1: Dev 6, If 0, Class=Vendor Specific Class, Driver=usbfs,                    12M
            |__ Port 2: Dev 7, If 0, Class=Vendor Specific Class, Driver=usbfs,                    12M
            |__ Port 3: Dev 8, If 0, Class=Vendor Specific Class, Driver=usbfs,                    12M
            |__ Port 4: Dev 9, If 0, Class=Hub, Driver=hub/4p, 480M
                |__ Port 1: Dev 10, If 0, Class=Vendor Specific Class, Driver=us                   bfs, 12M
                |__ Port 2: Dev 11, If 0, Class=Vendor Specific Class, Driver=us                   bfs, 12M
                |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 480M
                    |__ Port 2: Dev 14, If 0, Class=Vendor Specific Class, Drive                   r=usbfs, 12M
                    |__ Port 3: Dev 15, If 0, Class=Vendor Specific Class, Drive                   r=usbfs, 12M
                |__ Port 4: Dev 13, If 0, Class=Hub, Driver=hub/4p, 480M
                    |__ Port 1: Dev 17, If 0, Class=Vendor Specific Class, Drive                   r=usbfs, 12M
                    |__ Port 2: Dev 18, If 0, Class=Vendor Specific Class, Drive                   r=usbfs, 12M
                    |__ Port 3: Dev 19, If 0, Class=Vendor Specific Class, Drive                   r=usbfs, 12M
                    |__ Port 4: Dev 20, If 0, Class=Hub, Driver=hub/4p, 480M
                        |__ Port 1: Dev 22, If 0, Class=Vendor Specific Class, D                   river=cp210x, 12M
RicRock
Sr. Member
****
Offline Offline

Activity: 290
Merit: 250



View Profile
September 14, 2013, 06:17:55 AM
 #5


Unclear what is going on.

I do try to avoid hubs not on this list:

http://elinux.org/RPi_Powered_USB_Hubs

What is the power supply to the hubs?
Squeeky4711 (OP)
Newbie
*
Offline Offline

Activity: 25
Merit: 0


View Profile
September 14, 2013, 06:36:20 AM
 #6

I chose them based on this thread https://bitcointalk.org/index.php?topic=253749.0

_________Device_Name_________|   ___Ports Total___|   ___Ports Usable___|   __Power from AC__|   ___Price USD___|   __Price / Usable Port__|   
7-port Hub from MCM                                7                                7                          5V @ 3.5A                   13.99                        1.99

I was duplicating this setup but smaller.

https://bitcointalk.org/index.php?topic=253749.msg2996430#msg2996430
Squeeky4711 (OP)
Newbie
*
Offline Offline

Activity: 25
Merit: 0


View Profile
September 14, 2013, 06:52:19 AM
 #7

I just tested again this time I left the lcd on the time.  I powered on with only two hubs connect (10 erupters). 1-5 on hub1 showed, and 1-3 on hub2. 

Refreshed the Minepeon page a few times, when rates and temps went to zero, the time on LCD was amazingly high like as though it had been on for decades.
Squeeky4711 (OP)
Newbie
*
Offline Offline

Activity: 25
Merit: 0


View Profile
September 14, 2013, 06:58:53 AM
 #8

Same results with only 4 Erupters, stop hashing after a few minutes then later locks up completely.
Beastlymac
Hero Member
*****
Offline Offline

Activity: 630
Merit: 501


Miner Setup And Reviews. WASP Rep.


View Profile
September 14, 2013, 08:20:32 AM
 #9

Type sudo ntpd -s
Then systemctl stop cgminer.service
Then systemctl start cgminer.service

This problem is caused by the raspi not having a on board clock.

Message me if you have any problems
Squeeky4711 (OP)
Newbie
*
Offline Offline

Activity: 25
Merit: 0


View Profile
September 14, 2013, 02:37:29 PM
 #10

Type sudo ntpd -s
Then systemctl stop cgminer.service
Then systemctl start cgminer.service

This problem is caused by the raspi not having a on board clock.


minepeon@minepeon ~ $ sudo ntpd -s
minepeon@minepeon ~ $ systemctl stop cgminer.service
Failed to issue method call: Access denied


attempted and received the following results.
Squeeky4711 (OP)
Newbie
*
Offline Offline

Activity: 25
Merit: 0


View Profile
September 15, 2013, 04:39:14 AM
 #11

Well I've got all my miners being recognized now.  It was all about port placement.  Ended up having to play with which port took what, all in all Minepeon is seeing all 14 Erupters.  The bad part is I'm still loosing date/time somehow as randomly the Miner uptime with goto 23XX days.  If I reboot the everything it will work again for awhile, then do the same. 

I am using a wifi dongle, picks up just fine.  I can't understand why it's dropping off like that.
Squeeky4711 (OP)
Newbie
*
Offline Offline

Activity: 25
Merit: 0


View Profile
September 15, 2013, 04:45:32 PM
 #12

Figured out my clock issue thanks to the Minpeon thread.  I've been mining for just about 10 hours and a little over 2% error.   Not horrible for my first time mining.  Thanks to the gratification of BTCguild, I've already pulling in .01 BTC.  Granted diff will rise but I'd be happy to bring in .15-.20 my first week.
Squeeky4711 (OP)
Newbie
*
Offline Offline

Activity: 25
Merit: 0


View Profile
September 17, 2013, 12:38:48 AM
 #13

I thought I figured it out but I guess not.  Minepeon has rebooted twice and listing a huge uptime.  Is there a way to reference why it lost time and date?
KyrosKrane
Sr. Member
****
Offline Offline

Activity: 295
Merit: 250


View Profile WWW
September 17, 2013, 11:15:43 AM
 #14

I've mentioned this a couple of times on different threads.  The core reason is that the RPi doesn't have a real-time clock.  So, every time you power up the RPi, it resets its date to Jan. 1, 1970.  After a few minutes of running, there's a background process in Minepeon that updates the date/time to the current date and time.  However, in that interval, cgminer has kicked off.  So cgminer thinks that it started on Jan. 1, 1970, and has been running continuously for over 43 years.  It's also the reason your average hash rate drops to near zero - it's not your hash rate divided by the runtime over the last few minutes/hours, it's that hash rate over the last 43 years.  So yeah, it will drop. Smiley

Tips and donations: 1KyrosREGDkNLp1rMd9wfVwfkXYHTd6j5U  |  BTC P2Pool node: p2pool.kyros.info:9332
xsfgsdrwe
Newbie
*
Offline Offline

Activity: 56
Merit: 0



View Profile
September 17, 2013, 08:12:06 PM
 #15

I've mentioned this a couple of times on different threads.  The core reason is that the RPi doesn't have a real-time clock.  So, every time you power up the RPi, it resets its date to Jan. 1, 1970.  After a few minutes of running, there's a background process in Minepeon that updates the date/time to the current date and time.  However, in that interval, cgminer has kicked off.  So cgminer thinks that it started on Jan. 1, 1970, and has been running continuously for over 43 years.  It's also the reason your average hash rate drops to near zero - it's not your hash rate divided by the runtime over the last few minutes/hours, it's that hash rate over the last 43 years.  So yeah, it will drop. Smiley
   
Thanks
Zeek_W
Sr. Member
****
Offline Offline

Activity: 336
Merit: 250



View Profile
September 18, 2013, 12:47:08 AM
 #16

This link might help you and others if you want to add a RTC:

http://learn.adafruit.com/adding-a-real-time-clock-to-raspberry-pi/overview


I cannot remember the exact commands I punched into via SSH to get my minepeon from displaying 1970, but it did involve adding extra ntp (example: 1.au.pool.ntp.org or similar) addresses into ntp.conf.

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!