ROCKMINER ASIC miner official thread

[rockxie]

Dear All,

Thanks for all your words to ROCKMINER about T1.
1. We said that T1 is based on the solution by FC in lots of days ago, that's why someone doubt its not our product.
2. For the interview by ManeBjorn, its just the prototype one without cage.

[rockxie]

Two good news coming

1. Gift NEW RBOX to you!
People who has platform to show our product, tech guys, online shop, medias etc,can apply our new product NEW RBOX for free.
We'll gift one NEW RBOX to everyone who can prove his ability to show that miner.
If you are interested in the showing, pls PM me or email sales@rockminer.com, we'll ship out NEW RBOX this month.

2. Good news for NEW RBOX and RBOX by mining MED
People who is interested in the new crypto currency, MED, can get ROI by using RBOX or NEW RBOX to get coins!!!!
MED team contacted us, after long term researched, they found only ROCKMINER RBOX is the Bitcoin miner which can mine MED!!!!
People who wanna learn more about mining MED can contact the official service of MED or ROCKMINER.
BTW, NEW RBOX can also do this by tech setting.

[ManeBjorn]

Thanks for getting me the T1 so quickly so I could get the word out about them.
It is a nice running miner.

Dear All,

Thanks for all your words to ROCKMINER about T1.
1. We said that T1 is based on the solution by FC in lots of days ago, that's why someone doubt its not our product.
2. For the interview by ManeBjorn, its just the prototype one without cage.

[rockxie]

Dogie's comprehensive setup guide in super HD!

 

Thank you, Dogie, you did so many amazing works for ROCKMINER.

[AllInBit]

   Was wondering what the schedule for financial reports and divs were moving forward?

Update:

1. ROCKMINER Operational Progress and Financial Report
https://drive.google.com/file/d/0BwVxGR-76wFeeVplZ3YyeGFxWkU/edit?usp=sharing

2. Dividend
Receiver: ROCKMINER public IPO shareholders.
Amount: 18.75BTC
Date: July 29, 2014 (Beijing Time, GMT+8)

ROCKMINER IPO

Dividend:
Initial dividend: depends on the chips delivery date of ASCMINER ,in May around.
Total Amount of Dividend: the profit after deducting the profits retained within ROCKMINER.
Time and Frequency for Dividend: Dividends will be paid out on Wednesday every two weeks.


 

 

   
 

[R-T-B]

I wish I could say I liked the controller that comes with this, but I don't.  It's a piece of junk for any pool but BTCGUILD...  Heck, I even had trouble getting it to work with BTCGUILD.  I had to use the default ip that came with it (50.31.149.57).  (BTC-Guild for reference doesn't even list that ip...)  Attempts to connect to ANY other ip OR dns name are failing, showing all boards hashing at 0.  Don't know what the story with that is.  At least it's working for my BTCguild account and not the default worker that's inputted, lol.

I'm going to be trying hooking this thing up to a USB->SERIAL CP2102 adapter this weekend, and using generic BFGminer.  Anyone interested in this possibility may want to watch this space for a full status report.  I suspect the existing rockminer driver will need some hacking, but I think it can be done.

Here is the part I bought to try this, for reference:

http://www.ebay.com/itm/181088668352

My miner however, I am quite happy with.  Just get a raspi controller and get rid of that block erupter thing, I can't stand it.

[R-T-B]

I got my USB-UART converter, wired it up, programmed it as a "Rockminer T1" device, added that product info as an identifying factor in BFGMiners drive-rockminer.c, upped ,the chipcount_max to 128, and...



What would cause a "short read?"  That seems to be where it errors out.  That part of the code is nebulous.  Anyone who knows more about bfgminer/cgminer source willing to help?  I'd really like to get this working with a third party controller.

Rockxie, if you could provide the source code you used for your cgminer/bfgminer build incorperated into the Block Erupter controller, this would be very helpful in my efforts!

Thanks in advance!  You might not be able to tell from my comments above, but this is constructive criticism.  I really do like your product!

This seems to be the segment of code that fails, for reference:

Code:

static
bool rockminer_detect_one(const char * const devpath)
{
	int fd, chips;
	uint8_t buf[ROCKMINER_WORK_REQ_SIZE], reply[ROCKMINER_REPLY_SIZE];
	ssize_t rsz;
	
	fd = rockminer_open(devpath);
	if (fd < 0)
		return_via_applog(err, , LOG_DEBUG, "%s: %s %s", rockminer_drv.dname, "Failed to open", devpath);
	
	applog(LOG_DEBUG, "%s: %s %s", rockminer_drv.dname, "Successfully opened", devpath);
	
	rockminer_job_buf_init(buf, 0);
	rockminer_job_buf_set_freq(buf, ROCKMINER_MIN_FREQ_MHZ);
	memcpy(&buf[   0], golden_midstate, 0x20);
	memcpy(&buf[0x34], golden_datatail,  0xc);
	
	if (rockminer_write(fd, buf, sizeof(buf)) != sizeof(buf))
		return_via_applog(err, , LOG_DEBUG, "%s: %s %s", rockminer_drv.dname, "Error sending request to ", devpath);
	
	while (true)
	{
		rsz = rockminer_read(fd, reply, sizeof(reply));
		if (rsz != sizeof(reply))
			return_via_applog(err, , LOG_DEBUG, "%s: Short read from %s (%d)", rockminer_drv.dname, devpath, rsz);
		if ((!memcmp(reply, golden_result, sizeof(golden_result))) && (reply[4] & 0xf) == ROCKMINER_REPLY_NONCE_FOUND)
			break;
	}
	
	applog(LOG_DEBUG, "%s: Found chip 0 on %s, probing for total chip count", rockminer_drv.dname, devpath);
	chips = rockminer_bisect_chips(fd, buf);
	applog(LOG_DEBUG, "%s: Identified %d chips on %s", rockminer_drv.dname, chips, devpath);
	
	if (serial_claim_v(devpath, &rockminer_drv))
		goto err;
	
	serial_close(fd);
	
	struct cgpu_info * const cgpu = malloc(sizeof(*cgpu));
	*cgpu = (struct cgpu_info){
		.drv = &rockminer_drv,
		.set_device_funcs = rockminer_set_device_funcs,
		.device_path = strdup(devpath),
		.deven = DEV_ENABLED,
		.procs = chips,
		.threads = 1,
	};
	// NOTE: Xcode's clang has a bug where it cannot find fields inside anonymous unions (more details in fpgautils)
	cgpu->device_fd = -1;
	
	return add_cgpu(cgpu);

err:
	if (fd >= 0)
		serial_close(fd);
	return false;
}

[mstrongbow]

^^^ Nice work so far bro! Keep on rockin!

[R-T-B]

^^^ Nice work so far bro! Keep on rockin!

Thanks...  though I am not rockin' so much as stumbling through the dark.  

Anyhow, I'm switching to cgminer to see if maybe the codebase there is more flexible or even understandable...  We'll see...

EDIT:  I am starting to wonder if I have the UART pins hooked up wrong.  It's just ground and TX+RX right?

EDIT EDIT:  Giving up for now and switching back to my control (which still won't resolve DNS queries at all for some reason)...

I'd really like to get this working, but it seems beyond my skillset, at least on my own.

[bbxx]

Two good news coming

1. Gift NEW RBOX to you!
People who has platform to show our product, tech guys, online shop, medias etc,can apply our new product NEW RBOX for free.
We'll gift one NEW RBOX to everyone who can prove his ability to show that miner.
If you are interested in the showing, pls PM me or email sales@rockminer.com, we'll ship out NEW RBOX this month.

2. Good news for NEW RBOX and RBOX by mining MED
People who is interested in the new crypto currency, MED, can get ROI by using RBOX or NEW RBOX to get coins!!!!
MED team contacted us, after long term researched, they found only ROCKMINER RBOX is the Bitcoin miner which can mine MED!!!!
People who wanna learn more about mining MED can contact the official service of MED or ROCKMINER.
BTW, NEW RBOX can also do this by tech setting.

Hi
Any updates for Rockhash.com and their participants?
I emailed 2 weeks ago about new stuff and still no answer.
When project will be terminated or expanded?

thanks

[mstrongbow]

Two good news coming

1. Gift NEW RBOX to you!
People who has platform to show our product, tech guys, online shop, medias etc,can apply our new product NEW RBOX for free.
We'll gift one NEW RBOX to everyone who can prove his ability to show that miner.
If you are interested in the showing, pls PM me or email sales@rockminer.com, we'll ship out NEW RBOX this month.

2. Good news for NEW RBOX and RBOX by mining MED
People who is interested in the new crypto currency, MED, can get ROI by using RBOX or NEW RBOX to get coins!!!!
MED team contacted us, after long term researched, they found only ROCKMINER RBOX is the Bitcoin miner which can mine MED!!!!
People who wanna learn more about mining MED can contact the official service of MED or ROCKMINER.
BTW, NEW RBOX can also do this by tech setting.

Hi
Any updates for Rockhash.com and their participants?
I emailed 2 weeks ago about new stuff and still no answer.
When project will be terminated or expanded?

thanks

Dang, I forgot about Rockhash.com...need to get my RK-Box on there, even if just in shifts depending on how it works.

[R-T-B]

Rockminer, is there any chance to getting answers about my requests for input on developing a cgminer driver? 

[novak@gekkoscience]

I got my USB-UART converter, wired it up, programmed it as a "Rockminer T1" device, added that product info as an identifying factor in BFGMiners drive-rockminer.c, upped ,the chipcount_max to 128, and...



What would cause a "short read?"  That seems to be where it errors out.  That part of the code is nebulous.  Anyone who knows more about bfgminer/cgminer source willing to help?  I'd really like to get this working with a third party controller.

Rockxie, if you could provide the source code you used for your cgminer/bfgminer build incorperated into the Block Erupter controller, this would be very helpful in my efforts!

Thanks in advance!  You might not be able to tell from my comments above, but this is constructive criticism.  I really do like your product!

This seems to be the segment of code that fails, for reference:

Code:

static
bool rockminer_detect_one(const char * const devpath)
{
	int fd, chips;
	uint8_t buf[ROCKMINER_WORK_REQ_SIZE], reply[ROCKMINER_REPLY_SIZE];
	ssize_t rsz;
	
	fd = rockminer_open(devpath);
	if (fd < 0)
		return_via_applog(err, , LOG_DEBUG, "%s: %s %s", rockminer_drv.dname, "Failed to open", devpath);
	
	applog(LOG_DEBUG, "%s: %s %s", rockminer_drv.dname, "Successfully opened", devpath);
	
	rockminer_job_buf_init(buf, 0);
	rockminer_job_buf_set_freq(buf, ROCKMINER_MIN_FREQ_MHZ);
	memcpy(&buf[   0], golden_midstate, 0x20);
	memcpy(&buf[0x34], golden_datatail,  0xc);
	
	if (rockminer_write(fd, buf, sizeof(buf)) != sizeof(buf))
		return_via_applog(err, , LOG_DEBUG, "%s: %s %s", rockminer_drv.dname, "Error sending request to ", devpath);
	
	while (true)
	{
		rsz = rockminer_read(fd, reply, sizeof(reply));
		if (rsz != sizeof(reply))
			return_via_applog(err, , LOG_DEBUG, "%s: Short read from %s (%d)", rockminer_drv.dname, devpath, rsz);
		if ((!memcmp(reply, golden_result, sizeof(golden_result))) && (reply[4] & 0xf) == ROCKMINER_REPLY_NONCE_FOUND)
			break;
	}
	
	applog(LOG_DEBUG, "%s: Found chip 0 on %s, probing for total chip count", rockminer_drv.dname, devpath);
	chips = rockminer_bisect_chips(fd, buf);
	applog(LOG_DEBUG, "%s: Identified %d chips on %s", rockminer_drv.dname, chips, devpath);
	
	if (serial_claim_v(devpath, &rockminer_drv))
		goto err;
	
	serial_close(fd);
	
	struct cgpu_info * const cgpu = malloc(sizeof(*cgpu));
	*cgpu = (struct cgpu_info){
		.drv = &rockminer_drv,
		.set_device_funcs = rockminer_set_device_funcs,
		.device_path = strdup(devpath),
		.deven = DEV_ENABLED,
		.procs = chips,
		.threads = 1,
	};
	// NOTE: Xcode's clang has a bug where it cannot find fields inside anonymous unions (more details in fpgautils)
	cgpu->device_fd = -1;
	
	return add_cgpu(cgpu);

err:
	if (fd >= 0)
		serial_close(fd);
	return false;
}

I don't have rockminer gear but we have some of the ASICminer tubes, so I've been poking around in this.  I don't have your USB->UART connector either or I'd probably fire it up but I can see some stuff to look at immediately.  Here's what I would check though.

1.  Check rsz versus sizeof(reply)

Code:

rsz = rockminer_read(fd, reply, sizeof(reply));

All you know is that those are not equal.  What should sizeof(reply) be?

2.  I'm pretty sure you've got no communication between USB and your chips.  Check out how it checks successful opening:

Code:

fd = rockminer_open(devpath);
	if (fd < 0)
		return_via_applog(err, , LOG_DEBUG, "%s: %s %s", rockminer_drv.dname, "Failed to open", devpath);

All you know is that it was able to get a file lock on the device file, you have no idea if it can communicate or not.  Judging by the error message, I'd say not.

Code:

return_via_applog(err, , LOG_DEBUG, "%s: Short read from %s (%d)", rockminer_drv.dname, devpath, rsz);

Note how it prints "devpath (rsz)", and in your picture rsz is zero.  Makes it seem like you've got nothing, and none of the other code that it goes through seems to do any serial comm either.  Why would this error happen?  The most likely answer is differing serial parameters, either different baud rate, or parity bits, or something along those lines. 

Since this is based off the open source X24 design then I would check https://github.com/blockerupter/avr_hbc for UART parameters.  Once you confirm that data is transfered, the next step is to see if the serial protocol is similar enough based on the commands in the X24 AVR design spec or if we need a totally custom driver.  Based on the issues we've seen thus far, it would not surprise me if they had totally unrelated communication methods.

Just for completeness, here's what "rockminer_open" calls- I don't see any serial comm, just getting a file lock.

Code:

int rockminer_open(const char *devpath)
{
return serial_open(devpath, ROCKMINER_IO_SPEED, ROCKMINER_READ_TIMEOUT, true);
}

And that calls:

Code:

int serial_open(const char *devpath, unsigned long baud, uint8_t timeout, bool purge)
{
#ifdef WIN32
HANDLE hSerial = CreateFile(devpath, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
if (unlikely(hSerial == INVALID_HANDLE_VALUE))
{
DWORD e = GetLastError();
switch (e) {
case ERROR_ACCESS_DENIED:
applog(LOG_ERR, "Do not have user privileges required to open %s", devpath);
break;
case ERROR_SHARING_VIOLATION:
applog(LOG_ERR, "%s is already in use by another process", devpath);
break;
default:
applog(LOG_DEBUG, "Open %s failed, GetLastError:%u", devpath, (unsigned)e);
break;
}
return -1;
}
if (baud)
{
COMMCONFIG comCfg = {0};
comCfg.dwSize = sizeof(COMMCONFIG);
comCfg.wVersion = 1;
comCfg.dcb.DCBlength = sizeof(DCB);
comCfg.dcb.BaudRate = baud;
comCfg.dcb.fBinary = 1;
comCfg.dcb.fDtrControl = DTR_CONTROL_ENABLE;
comCfg.dcb.fRtsControl = RTS_CONTROL_ENABLE;
comCfg.dcb.ByteSize = 8;
SetCommConfig(hSerial, &comCfg, sizeof(comCfg));
}
// Code must specify a valid timeout value (0 means don't timeout)
const DWORD ctoms = ((DWORD)timeout * 100);
COMMTIMEOUTS cto = {ctoms, 0, ctoms, 0, ctoms};
SetCommTimeouts(hSerial, &cto);
if (purge) {
PurgeComm(hSerial, PURGE_RXABORT);
PurgeComm(hSerial, PURGE_TXABORT);
PurgeComm(hSerial, PURGE_RXCLEAR);
PurgeComm(hSerial, PURGE_TXCLEAR);
}
return _open_osfhandle((intptr_t)hSerial, 0);
#else
int fdDev = open(devpath, O_RDWR | O_CLOEXEC | O_NOCTTY);
if (unlikely(fdDev == -1))
{
if (errno == EACCES)
applog(LOG_ERR, "Do not have user privileges required to open %s", devpath);
else
applog(LOG_DEBUG, "Open %s failed: %s", devpath, bfg_strerror(errno, BST_ERRNO));
return -1;
}
#if defined(LOCK_EX) && defined(LOCK_NB)
if (likely(!flock(fdDev, LOCK_EX | LOCK_NB)))
applog(LOG_DEBUG, "Acquired exclusive advisory lock on %s", devpath);
else
if (errno == EWOULDBLOCK)
{
applog(LOG_ERR, "%s is already in use by another process", devpath);
close(fdDev);
return -1;
}
else
applog(LOG_WARNING, "Failed to acquire exclusive lock on %s: %s (ignoring)", devpath, bfg_strerror(errno, BST_ERRNO));
#endif
struct termios my_termios;
tcgetattr(fdDev, &my_termios);
#ifdef TERMIOS_DEBUG
termios_debug(devpath, &my_termios, "before");
#endif
if (baud)
{
speed_t speed = tiospeed_t(baud);
if (speed == B0)
applog(LOG_WARNING, "Unrecognized baud rate: %lu", baud);
else
{
cfsetispeed(&my_termios, speed);
cfsetospeed(&my_termios, speed);
}
}
my_termios.c_cflag &= ~(CSIZE | PARENB);
my_termios.c_cflag |= CS8;
my_termios.c_cflag |= CREAD;
#ifdef USE_AVALON
// my_termios.c_cflag |= CRTSCTS;
#endif
my_termios.c_cflag |= CLOCAL;
my_termios.c_iflag &= ~(IGNBRK | BRKINT | PARMRK |
ISTRIP | INLCR | IGNCR | ICRNL | IXON);
my_termios.c_oflag &= ~OPOST;
my_termios.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN);
// Code must specify a valid timeout value (0 means don't timeout)
my_termios.c_cc[VTIME] = (cc_t)timeout;
my_termios.c_cc[VMIN] = 0;
#ifdef TERMIOS_DEBUG
termios_debug(devpath, &my_termios, "settings");
#endif
tcsetattr(fdDev, TCSANOW, &my_termios);
#ifdef TERMIOS_DEBUG
tcgetattr(fdDev, &my_termios);
termios_debug(devpath, &my_termios, "after");
#endif
if (purge)
tcflush(fdDev, TCIOFLUSH);
return fdDev;
#endif
}

--
novak

[Chris_Sabian]

Any financial updates or updates on new miners?

[R-T-B]

Note how it prints "devpath (rsz)", and in your picture rsz is zero.  Makes it seem like you've got nothing, and none of the other code that it goes through seems to do any serial comm either.  Why would this error happen?  The most likely answer is differing serial parameters, either different baud rate, or parity bits, or something along those lines.  

Since this is based off the open source X24 design then I would check https://github.com/blockerupter/avr_hbc for UART parameters.  Once you confirm that data is transfered, the next step is to see if the serial protocol is similar enough based on the commands in the X24 AVR design spec or if we need a totally custom driver.  Based on the issues we've seen thus far, it would not surprise me if they had totally unrelated communication methods.

From some hacking around in cgminer, I think I've determined I am getting no serial comm whatsoever.  I guess hooking up the tx/rx/GND lines aren't enough.

I only have a rudimentary knowledge of the hardware part.  Any idea how one would wire up the adapter I linked earlier?

[bbxx]

i have noticed that one of my r4/r3 boards are dropping constantly.
reboot solve issue for while.
is it sign that one of boards is dying?

thanks.

[novak@gekkoscience]

Note how it prints "devpath (rsz)", and in your picture rsz is zero.  Makes it seem like you've got nothing, and none of the other code that it goes through seems to do any serial comm either.  Why would this error happen?  The most likely answer is differing serial parameters, either different baud rate, or parity bits, or something along those lines.  

Since this is based off the open source X24 design then I would check https://github.com/blockerupter/avr_hbc for UART parameters.  Once you confirm that data is transfered, the next step is to see if the serial protocol is similar enough based on the commands in the X24 AVR design spec or if we need a totally custom driver.  Based on the issues we've seen thus far, it would not surprise me if they had totally unrelated communication methods.

From some hacking around in cgminer, I think I've determined I am getting no serial comm whatsoever.  I guess hooking up the tx/rx/GND lines aren't enough.

I only have a rudimentary knowledge of the hardware part.  Any idea how one would wire up the adapter I linked earlier?

I think you have it wired correctly, those should be the only lines you need.  I've checked tubes and it is a UART connection, using those wires.  The thing is that UART is simpler and older than USB, just plugging in the wire doesn't necessarily mean you can talk.  On the ASICminer tubes I've seen a 11.0592 MHz crystal, which is apparently used as the AVR clock and divided, (from here https://github.com/blockerupter/avr_hbc/blob/master/BE200S.c#L232) to get serial baud rate.  It looks like, according to the same data source that a 9 bit mode is used, which according to here: (www.atmel.com/images/doc8025.pdf) is a single stop bit.  Looks like baud should be 11059200/(8*(UBRRn+1), and based off a UBRRn of 2, should be equal to 460800.  You should be able to use those serial parameters to at least get the chip to say hello, even if your reply is based on the wrong drivers (the more I look, the more I would say rockminer drivers have nothing to do with X24 drivers, though that is not necessarily the case.)

So try this for your serial port:
baud rate: 460800
data bits: 8
stop bits: 1

See if you can at least get a single read- that would imply that your serial port is correctly configured, even if the drivers are wrong.


--
novak

[sidehack]

Novak is our resident tech wizard, case anyone's wondering. We were already looking into this issue and have no problem helping someone else out that's already farther down the path.

[R-T-B]

Thanks again Novak, I will try those settings in a couple of hours and report back.

by the way, cgminer source code has this set of lines in the drive-icarus.c, which I find VERY interesting:

#define MAX_TRIES 4
#define RM_CMD_MASK 0x0F
#define RM_STATUS_MASK 0xF0
#define RM_CHIP_MASK 0x3F
#define RM_PRODUCT_MASK 0xC0
#define RM_PRODUCT_RBOX 0x00
#define RM_PRODUCT_T1 0x40
#define RM_PRODUCT_T2 0x80
#define RM_PRODUCT_TEST 0xC0

Note the bold.

The Rockminer "T1" is electrically identically to the ASICMiner Tube.  Is there any chance it actually supports the T1 in it's source code, and thus the ASICMiner tube as well?

When I find out, I will let you know...

[R-T-B]

Now this is interesting:

Output log of cgminer --debug, using a baud as indicated (--icarus-options 406800:1:1?)

Code:

[?1049h(B[?7h [2014-09-04 13:35:56] Started cgminer 4.5.0

 [2014-09-04 13:35:56] ICA looking for and found AMU 10c4:ea60
 [2014-09-04 13:35:56] USB lock Icarus 7-2
 [2014-09-04 13:35:56] RES: Icarus (7:2) lock=1
 [2014-09-04 13:35:56] USB res lock Icarus 7-2
 [2014-09-04 13:35:56] RES: Icarus (7:2) lock ok=1
 [2014-09-04 13:35:56] USB init, kernel attached ... - AMU device 7:2
 [2014-09-04 13:35:56] USB init, kernel detached ifinfo 0 interface 0 successfully - AMU device 7:2
 [2014-09-04 13:35:56] USB init found (0,0) == false - AMU device 7:2
 [2014-09-04 13:35:56] USB free AMU
//NOTE THIS LINE IS LIKELY OTHER USB DEVICES IN MY NETBOOK
 [2014-09-04 13:35:56] Icarus detect (7:2) failed to initialise (incorrect device?)[2014-09-04 13:35:56] ICA looking for LIN 10c4:ea60 but found 1d6b:0001 insteadICA looking for ANU 10c4:ea60 but found 1d6b:0001 insteadICA looking for BLT 0403:6001 but found 1d6b:0001 insteadICA looking for LLT 0403:6001 but found 1d6b:0001 instead
[2014-09-04 13:35:56] ICA looking for CMR 0403:6014 but found 1d6b:0001 insteadICA looking for CMR 0403:8350 but found 1d6b:0001 instead
 [2014-09-04 13:35:56] No devices detected!
 [2014-09-04 13:35:56] Waiting for USB hotplug devices or press q to quit
 [2014-09-04 13:35:56] No devices detected!
 [2014-09-04 13:35:56] Waiting for USB hotplug devices or press q to quitProbing for an alive pool
 [2014-09-04 13:35:56] RES: Icarus (7:2) lock=0USB res unlock Icarus 7-2
 [2014-09-04 13:35:56] Testing pool stratum+tcp://stratum.btcguild.com7] Select timeout/failed connect
 [2014-09-04 13:35:57] Failed to connect to stratum on stratum.btcguild.com:807] Initiate stratum failed
 [2014-09-04 13:36:02] Testing pool stratum+tcp://stratum.btcguild.com6:02] Select timeout/failed connect
 [2014-09-04 13:36:02] Failed to connect to stratum on stratum.btcguild.com:806:02] Initiate stratum failed6:04] Shutdown signal received.[?1049l
[?1l>