Bitcoin Forum
December 06, 2016, 08:00:59 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 [669] 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4820092 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
xyzzy099
Legendary
*
Online Online

Activity: 939



View Profile
November 06, 2013, 11:30:05 AM
 #13361

@ckolivas

any answer on this question? https://bitcointalk.org/index.php?topic=28402.msg3489847#msg3489847

A simple "yes" or "no" will suffice for now so at least I know where I should be looking for a solution
No limit except the one imposed by your operating system. On windows that's ~127. I know of someone with 2TH of erupters (yes that's not a typo) with ~208 on each linux box running them (ARM devices too so not even full power PCs).

The limit is 127 per host controller, not 127 per machine - right?  And that is not a Windows-specific limit...  It's a USB spec limit.


Libertarians:  Diligently plotting to take over the world and leave you alone.
1481054459
Hero Member
*
Offline Offline

Posts: 1481054459

View Profile Personal Message (Offline)

Ignore
1481054459
Reply with quote  #2

1481054459
Report to moderator
1481054459
Hero Member
*
Offline Offline

Posts: 1481054459

View Profile Personal Message (Offline)

Ignore
1481054459
Reply with quote  #2

1481054459
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481054459
Hero Member
*
Offline Offline

Posts: 1481054459

View Profile Personal Message (Offline)

Ignore
1481054459
Reply with quote  #2

1481054459
Report to moderator
aigeezer
Legendary
*
Offline Offline

Activity: 1278


Cryptanalyst castrated by his government, 1952


View Profile
November 06, 2013, 12:54:00 PM
 #13362


Not sure if you meant that just for jmc1517 but I'm testing it anyway, replacing 3.7.2 which was going strong after 23 hours. "ymmv" is off to a good start, but only a few minutes in so far. I didn't try "allsync".

-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 06, 2013, 01:06:26 PM
 #13363


Right.  I'll get on the case!

Just for interest, the logfile from the evening/overnight run of 3.5.1 is here. No problems visible on screen and no zombies, but there are some different looking TIMEOUT messages in the log:
 https://dl.dropboxusercontent.com/u/44240170/logfile-3.5.1.txt

Just started "allsync" and I've got a zombie AMU 5 straight away, together with the usual timeouts from AMU 0.
Unplugged AMU 5 and left it out.  Now AMU 28 has gone zombie too.  I see different error messagaes in the log though (?)
I guess I'll move on to "ymmv" then...
Logfile here (without --debug):
  https://dl.dropboxusercontent.com/u/44240170/logfile-allsync.txt

Well that is very interesting (again) because as far as I can see, the well working 3.5.1 wasn't really working well anyway. It was clear a while back that your case was different to aigeezer's but I'm going to go out on a limb here and say that you actually have a hardware problem. The one that fails every single time first up is suspicious, and it seems to create a cascade of other problems.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Jeffrey
Full Member
***
Offline Offline

Activity: 182


View Profile
November 06, 2013, 01:23:18 PM
 #13364

...
Unless I misunderstand how you are wiring it up I would say maybe the Power supply doesn't like working at >100%.
I came to that number based on 60 erupters at .5 amp being 30A and I would have to guess the hub would waste some amount of power. I also have 0 idea how long your cables connecting to the power supply is but at 30A you should have a really short run and large cable.

But I can't figure out why one on the laptop port wouldn't work. I would have taken a shot at it earlier but I didn't see anything obvious unless you only use 1 power supply. Even then your laptop may not provide the full .5 amp without too much voltage sag. Laptops are usually not as powerful on the usb ports. But I know by spec it should work......

EDIT: by I misunderstand how you are wiring it up I mean that you say you have 2 hubs and one power supply. Possibly you wanted to convey a power supply per hub. I made the assumption that you had one power supply per hub the first time I read it as you would be woefully under powered otherwise.

Sorry maybe it was my writing. I have 2 hubs and 2 PSU's (both 30a @ 5v).
When I have 30 BE's in hub 1 and 29 BE's in hub 2, it works fine (still, both hubs on their own psu) but as soon as I add a 60th BE (be it in hub 1 or hub 2), it doesn't work anymore.

Anyway at least I know it's not a limitation by the miner, so I'll have to find a solution somewhere else.

Thanks to those who replied
jmc1517
Jr. Member
*
Offline Offline

Activity: 56


View Profile
November 06, 2013, 04:15:03 PM
 #13365


Well that is very interesting (again) because as far as I can see, the well working 3.5.1 wasn't really working well anyway. It was clear a while back that your case was different to aigeezer's but I'm going to go out on a limb here and say that you actually have a hardware problem. The one that fails every single time first up is suspicious, and it seems to create a cascade of other problems.

Hmmm, well I've been running "ymmv" for 5 hours now, and no zombies.... BUT ...

What I find interesting is that there are some TIMEOUTS in the log which look VERY similar to those appearing in the 3.5.1 log - which seems to me to be working well.  I don't get any spurious zombies with 3.5.1 and the hash rates all look to be OK, so I don't really "get" the suspected hardware problem.  If it keeps running, then surely that's the main criterion?  Anyway here's the (ongoing) log from "ymmv".  There have been a couple of broadband dropouts during this time which have not caused any ongoing problems, so, "ymmv" has been running very well indeed so far:
 https://dl.dropboxusercontent.com/u/44240170/logfile-ymmv-ongoing.txt

Of course I'm tempting fate again with this post.  But what the heck...

Edit:
I've noticed a small visual bug on some of these later builds.  You may be aware of it - it probably results from initial recognition of the devices when the table expands - at the end of the fixed-part of the display, the first line after the dashes is sometimes frozen as here, from 10:52 and doesn't scroll off, whereas the current lines are 16:39 and scrolling, if you see what I mean?  Very minor in the grand scheme of things, but you may want to fix it...:

 AMU 32:                | 335.6M/334.3Mh/s | A:1544 R: 8 HW:59 WU: 4.4/m
 AMU 33:                | 335.8M/333.9Mh/s | A:1623 R: 0 HW:21 WU: 4.6/m
--------------------------------------------------------------------------------
 [2013-11-06 10:52:20] Accepted 02506e24 Diff 111/3 AMU 12 pool 0
 [2013-11-06 16:39:08] Accepted 13f26331 Diff 13/8 AMU 1 pool 0
 [2013-11-06 16:39:08] Accepted 0a61a71f Diff 25/8 AMU 8 pool 0


Edit: Midnight update: 12 hours and still no zombies. Go ymmv!

 
os2sam
Legendary
*
Offline Offline

Activity: 1918


Think for yourself


View Profile
November 06, 2013, 06:05:45 PM
 #13366

OK, I was going to try 3.7.0 when it was released so I rebooted my rig to make sure the old .dll's were purged from memory.  Well what a fiasco that was with the new 49 port hub and 47 BE's in it.  I just now got the rig going again with the new neat and nifty hub, I'm not so impressed with it at the moment.  Well in the mean time there have been only two new versions released.

So I'm starting with 3.7.2 in two instances, one with 47 BE's and one with a Jalapeno.  Is there anything in particular I should be watching for?  I just want to make sure I put in a good report if the need arises.  There has been ALLOT of development since 3.4.3 and I haven't kept up with all of it.

On a side note, is there a thread for these ASICMiner hubs?  Rebooting a Windoze box shouldn't be a week long project.

Thanks,
Sam

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
jedimstr
Hero Member
*****
Offline Offline

Activity: 784



View Profile
November 06, 2013, 06:21:21 PM
 #13367

OK, I was going to try 3.7.0 when it was released so I rebooted my rig to make sure the old .dll's were purged from memory.  Well what a fiasco that was with the new 49 port hub and 47 BE's in it.  I just now got the rig going again with the new neat and nifty hub, I'm not so impressed with it at the moment.  Well in the mean time there have been only two new versions released.

So I'm starting with 3.7.2 in two instances, one with 47 BE's and one with a Jalapeno.  Is there anything in particular I should be watching for?  I just want to make sure I put in a good report if the need arises.  There has been ALLOT of development since 3.4.3 and I haven't kept up with all of it.

On a side note, is there a thread for these ASICMiner hubs?  Rebooting a Windoze box shouldn't be a week long project.

Thanks,
Sam


It may be a good idea to unplug the ASICMiner hub from your computer when rebooting and plugging it back in after Windows startup chug chug chugging is done.  Once replugged and after detection from Windows, you should be good to go.  I find I have to do this with any of my hubs connected to miners.

os2sam
Legendary
*
Offline Offline

Activity: 1918


Think for yourself


View Profile
November 06, 2013, 06:26:08 PM
 #13368

On a side note, is there a thread for these ASICMiner hubs?  Rebooting a Windoze box shouldn't be a week long project.


It may be a good idea to unplug the ASICMiner hub from your computer when rebooting and plugging it back in after Windows startup chug chug chugging is done.  Once replugged and after detection from Windows, you should be good to go.  I find I have to do this with any of my hubs connected to miners.

Yep that does speed up the shutdown/reboot.  But when I plugged it back in Windoze only detected 4 out of the 8 generic hubs and none of the BE's in it.  If I tried to scan for new hardware or delete one the device manager just hangs, for days if I let it.

Same behavior on three different machines with Win7 32 and 64 bit.
Thanks,
Sam

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
os2sam
Legendary
*
Offline Offline

Activity: 1918


Think for yourself


View Profile
November 06, 2013, 06:47:44 PM
 #13369

I have an instance of CGminer 3.7.2 with a Jalapeno.  I'm getting a WU: 0.3.  It is definitely submitting more shares than that per minute.  My BE instance seems OK.
Sam

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
jedimstr
Hero Member
*****
Offline Offline

Activity: 784



View Profile
November 06, 2013, 07:57:37 PM
 #13370

On a side note, is there a thread for these ASICMiner hubs?  Rebooting a Windoze box shouldn't be a week long project.


It may be a good idea to unplug the ASICMiner hub from your computer when rebooting and plugging it back in after Windows startup chug chug chugging is done.  Once replugged and after detection from Windows, you should be good to go.  I find I have to do this with any of my hubs connected to miners.

Yep that does speed up the shutdown/reboot.  But when I plugged it back in Windoze only detected 4 out of the 8 generic hubs and none of the BE's in it.  If I tried to scan for new hardware or delete one the device manager just hangs, for days if I let it.

Same behavior on three different machines with Win7 32 and 64 bit.
Thanks,
Sam

hmmm... at that point, can't help much... my miners are either Linux or Mac based.  They have the same issues with reboots (especially macs who like to look for any bootable device on USB and would take awhile pinging each and every hub and BE) but once reconnected after boot, everything lights up nice and solid.  I only startup the mining software (depending on the worker, its either running cgminer or another software that will go un-named in this thread Wink ) once everything is lit and ready to go.

ThinkFast
Member
**
Offline Offline

Activity: 69


View Profile
November 07, 2013, 04:26:14 AM
 #13371

Trying to mine litecoins with cgminer.
W2KSP3
GPU 0 HD4850

LTC.bat:
set term=
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
cgminer.exe -d 0 --scrypt -o http://ltc.give-me-coins.com:3333 -u user.worker -p pass --failover-only --shaders=800 -I 10 -Q 2

Log:
[2013-11-06 23:18:41] Started cgminer 3.7.2
Just seems to hang. I can CTRL-C to cmd prompt.

I've looked at just about every site's config for cgminer. They are all the same.

Question: What's the most likely reason I can't connect to their server?
Should I be using an older version of cgminer (2.6.1)?

Thanks!
os2sam
Legendary
*
Offline Offline

Activity: 1918


Think for yourself


View Profile
November 07, 2013, 05:14:51 AM
 #13372

Trying to mine litecoins with cgminer.
W2KSP3
GPU 0 HD4850

Should I be using an older version of cgminer (2.6.1)?

I don't know squat about alt coin mining.  But, doesn't scrypt require newer Catalyst versions than are supported by that old GPU and OS?  Pretty sure you need Catalyst in the 13.x version range.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
ThinkFast
Member
**
Offline Offline

Activity: 69


View Profile
November 07, 2013, 05:25:25 AM
 #13373

Yeah...You might be right.
I will try it on my HD5570 to confirm.
loshia
Legendary
*
Offline Offline

Activity: 1372


View Profile
November 07, 2013, 08:48:11 AM
 #13374

Kon,
 I discovered flowing nasty bug which is present on MIPS TP-link only

/* This is the central place all work that is about to be retired should be
 * cleaned to remove any dynamically allocated arrays within the struct */
void clean_work(struct work *work)
{
  if (work->job_id) free(work->job_id);

For some reason work->job_id is not set always - do not ask why Wink and tp-link breaks badly - debugged and fixed with gdb server/client

Best

PS:

 [2013-11-07 10:38:34] Accepted fbc145d6 Diff 260/128 HEXa 3 pool 0
 [2013-11-07 10:38:54] Accepted f6a0cfde Diff 266/256 HEXa 0 pool 0
 [2013-11-07 10:39:30] Pool 0 difficulty changed to 128
 [2013-11-07 10:39:51] Rejected 017a21de Diff 173/128 HEXa 3 pool 0 (Below difficulty)



On tp-link MIPS  from times to time some good shares seemed to be rejected. Probably there is some issue in checking work if it matches pool difficulty?

Please comment
10X





Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 07, 2013, 08:50:49 AM
 #13375

Con,
 I discovered flowing nasty bug which is present on MIPS TP-link only

/* This is the central place all work that is about to be retired should be
 * cleaned to remove any dynamically allocated arrays within the struct */
void clean_work(struct work *work)
{
  if (work->job_id) free(work->job_id);

For some reason work->job_id is not set always - do not ask why Wink and tp-link breaks badly - debugged and fixed with gdb server/client
Ioshia. Thanks , that's very interesting, however calling free on NULL is a valid thing to do so I don't understand how this helps? If work->job_id == NULL then free(work->job_id) equates to free(NULL);

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
loshia
Legendary
*
Offline Offline

Activity: 1372


View Profile
November 07, 2013, 08:52:00 AM
 #13376

Con,
 I discovered flowing nasty bug which is present on MIPS TP-link only

/* This is the central place all work that is about to be retired should be
 * cleaned to remove any dynamically allocated arrays within the struct */
void clean_work(struct work *work)
{
  if (work->job_id) free(work->job_id);

For some reason work->job_id is not set always - do not ask why Wink and tp-link breaks badly - debugged and fixed with gdb server/client
Ioshia. Thanks , that's very interesting, however calling free on NULL is a valid thing to do so I don't understand how this helps? If work->job_id == NULL then free(work->job_id) equates to free(NULL);

I know...
but life sucks Smiley
Can you comment the diff issue also?
PS: I can revert back my change and post gdb output if you want ?

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 07, 2013, 08:56:38 AM
 #13377

PS:

 [2013-11-07 10:38:34] Accepted fbc145d6 Diff 260/128 HEXa 3 pool 0
 [2013-11-07 10:38:54] Accepted f6a0cfde Diff 266/256 HEXa 0 pool 0
 [2013-11-07 10:39:30] Pool 0 difficulty changed to 128
 [2013-11-07 10:39:51] Rejected 017a21de Diff 173/128 HEXa 3 pool 0 (Below difficulty)

I'll investigate.... no wait a minute, HEXa is not a driver that I maintain or support in cgminer so I can point the finger at that.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
jmc1517
Jr. Member
*
Offline Offline

Activity: 56


View Profile
November 07, 2013, 09:58:20 AM
 #13378

Update: The test of cgminer-ymmv is still going strong. Almost 24 hours now and no zombies. Whatever is in this build seems to have done the trick Smiley

Ongoing logfile here (without --debug), although nothing new in it except accepted shares Smiley
 https://dl.dropboxusercontent.com/u/44240170/logfile-ymmv-ongoing.txt

Edit:  OK, the only problem I can see is with AMU6 which has a much lower accepted share rate than all the rest (others are all up in 6000's).  Suppose this might be something to worry about (?):

 AMU  2:                | 335.3M/333.5Mh/s | A:6322 R:12 HW: 67 WU: 4.6/m
 AMU  3:                | 335.8M/333.6Mh/s | A:6276 R: 8 HW: 57 WU: 4.6/m
 AMU  4:                | 335.5M/333.4Mh/s | A:6169 R: 3 HW:207 WU: 4.5/m
 AMU  5:                | 335.3M/333.3Mh/s | A:6300 R: 8 HW:191 WU: 4.6/m
 AMU  6:                | 335.8M/333.4Mh/s | A:2245 R:19 HW: 83 WU: 1.6/m     <---- low ??
 AMU  7:                | 335.5M/333.5Mh/s | A:6149 R:16 HW: 50 WU: 4.6/m
 AMU  8:                | 335.6M/333.6Mh/s | A:5795 R: 8 HW: 67 WU: 4.6/m

-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 07, 2013, 10:03:01 AM
 #13379

Update: The test of cgminer-ymmv is still going strong. Almost 24 hours now and no zombies. Whatever is in this build seems to have done the trick Smiley

Ongoing logfile here (without --debug), although nothing new in it except accepted shares Smiley
 https://dl.dropboxusercontent.com/u/44240170/logfile-ymmv-ongoing.txt

Sync transfers.

Except for regular gross timeout overflows.

Code:
[2013-11-06 15:41:15] AMU11: TIMEOUT GetResults took 822ms but was 100ms
 [2013-11-06 15:41:15] AMU3: TIMEOUT GetResults took 813ms but was 100ms
 [2013-11-06 15:41:15] AMU6: TIMEOUT GetResults took 803ms but was 100ms
 [2013-11-06 15:41:15] AMU27: TIMEOUT GetResults took 803ms but was 100ms
 [2013-11-06 15:41:15] AMU19: TIMEOUT GetResults took 797ms but was 100ms
 [2013-11-06 15:41:15] AMU7: TIMEOUT GetResults took 795ms but was 100ms
 [2013-11-06 15:41:15] AMU12: TIMEOUT GetResults took 785ms but was 100ms
 [2013-11-06 15:41:15] AMU20: TIMEOUT GetResults took 785ms but was 100ms
 [2013-11-06 15:41:15] AMU5: TIMEOUT GetResults took 784ms but was 100ms
 [2013-11-06 15:41:15] AMU1: TIMEOUT GetResults took 784ms but was 100ms
 [2013-11-06 15:41:15] AMU26: TIMEOUT GetResults took 785ms but was 100ms
 [2013-11-06 15:41:15] AMU4: TIMEOUT GetResults took 783ms but was 100ms
 [2013-11-06 15:41:15] AMU25: TIMEOUT GetResults took 770ms but was 100ms
 [2013-11-06 15:41:15] AMU21: TIMEOUT GetResults took 770ms but was 100ms
 [2013-11-06 15:41:15] AMU29: TIMEOUT GetResults took 769ms but was 100ms
 [2013-11-06 15:41:15] AMU32: TIMEOUT GetResults took 760ms but was 100ms
 [2013-11-06 15:41:15] AMU31: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU0: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU18: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU33: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU30: TIMEOUT GetResults took 736ms but was 100ms
 [2013-11-06 15:41:15] AMU9: TIMEOUT GetResults took 736ms but was 100ms
 [2013-11-06 15:41:15] AMU22: TIMEOUT GetResults took 736ms but was 100ms
 [2013-11-06 15:41:15] AMU23: TIMEOUT GetResults took 736ms but was 100ms
 [2013-11-06 15:41:15] AMU24: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU16: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU8: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU17: TIMEOUT GetResults took 735ms but was 100ms
Note they all happen at the same time. So whatever is causing communication issues is happening across the board which is why it looks hardware related to me.

Still not sure what to make about all this and whether it's even pursuing it any further. Perhaps offering a sync option or a binary for troublesome setups or something...

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
jmc1517
Jr. Member
*
Offline Offline

Activity: 56


View Profile
November 07, 2013, 10:09:14 AM
 #13380

Update: The test of cgminer-ymmv is still going strong. Almost 24 hours now and no zombies. Whatever is in this build seems to have done the trick Smiley

Ongoing logfile here (without --debug), although nothing new in it except accepted shares Smiley
 https://dl.dropboxusercontent.com/u/44240170/logfile-ymmv-ongoing.txt

Sync transfers.

Except for regular gross timeout overflows.

Code:
[2013-11-06 15:41:15] AMU11: TIMEOUT GetResults took 822ms but was 100ms
 [2013-11-06 15:41:15] AMU3: TIMEOUT GetResults took 813ms but was 100ms
 [2013-11-06 15:41:15] AMU6: TIMEOUT GetResults took 803ms but was 100ms
 [2013-11-06 15:41:15] AMU27: TIMEOUT GetResults took 803ms but was 100ms
 [2013-11-06 15:41:15] AMU19: TIMEOUT GetResults took 797ms but was 100ms
 [2013-11-06 15:41:15] AMU7: TIMEOUT GetResults took 795ms but was 100ms
 [2013-11-06 15:41:15] AMU12: TIMEOUT GetResults took 785ms but was 100ms
 [2013-11-06 15:41:15] AMU20: TIMEOUT GetResults took 785ms but was 100ms
 [2013-11-06 15:41:15] AMU5: TIMEOUT GetResults took 784ms but was 100ms
 [2013-11-06 15:41:15] AMU1: TIMEOUT GetResults took 784ms but was 100ms
 [2013-11-06 15:41:15] AMU26: TIMEOUT GetResults took 785ms but was 100ms
 [2013-11-06 15:41:15] AMU4: TIMEOUT GetResults took 783ms but was 100ms
 [2013-11-06 15:41:15] AMU25: TIMEOUT GetResults took 770ms but was 100ms
 [2013-11-06 15:41:15] AMU21: TIMEOUT GetResults took 770ms but was 100ms
 [2013-11-06 15:41:15] AMU29: TIMEOUT GetResults took 769ms but was 100ms
 [2013-11-06 15:41:15] AMU32: TIMEOUT GetResults took 760ms but was 100ms
 [2013-11-06 15:41:15] AMU31: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU0: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU18: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU33: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU30: TIMEOUT GetResults took 736ms but was 100ms
 [2013-11-06 15:41:15] AMU9: TIMEOUT GetResults took 736ms but was 100ms
 [2013-11-06 15:41:15] AMU22: TIMEOUT GetResults took 736ms but was 100ms
 [2013-11-06 15:41:15] AMU23: TIMEOUT GetResults took 736ms but was 100ms
 [2013-11-06 15:41:15] AMU24: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU16: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU8: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU17: TIMEOUT GetResults took 735ms but was 100ms
Note they all happen at the same time. So whatever is causing communication issues is happening across the board which is why it looks hardware related to me.

Still not sure what to make about all this and whether it's even pursuing it any further. Perhaps offering a sync option or a binary for troublesome setups or something...

True, but...
a)  It hasn't happened since yesterday.
b) These look like the same "errors" which 3.5.1 reports
c) It doesn't result in the setting of a zombie, so mining continues (?)

I would happily run this build as it doesn't cause me - the end-user - any problems!!

Edit: Please see edited previous post - One AMU has low accepted share rate. Ah, it hasn't done any work since 19:00 last night.  Perhaps this one "should" have been a zombie after all then? Sad


Pages: « 1 ... 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 [669] 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!