 Show Posts
|
|
Pages: [1] 2 3 »
|
Alrighty, try the rc I posted next please then.
"rc" has been running for 7 hours now and has auto-replugged 5 of my devices, so I have 0-33 (with gaps) and 34-38, but no zombies. Pool hash rate seems OK. I am seeing regular solid LEDs coming on and then going off again after a few seconds, sometimes in batches, which presumably indicates something "not-quite right", but at least any errors that do happen are being recovered from :-) I forgot to log this run. I can stop and restart if necessary. Do you think you might need the log? |
|
|
|
Started latest trial version of cgminer, renamed as cgminer-2013-12-08. The AMU LEDs initially all go off, then come back on again and it seems to take ages for all AMU LEDs to go out, then hash rates initially all show 150/ for a while, then 252/ ... afterwards increasing to the normal 335/ - see screenshots in logfile. I haven't seen this behaviour before! Test was left running overnight. When I came back this morning there were 6 zombies and a couple with zero hash rates, please see 2nd screenshot in logfile. Test stopped  Logfile here: https://dl.dropboxusercontent.com/u/44240170/logfile-2013-12-08.txt |
|
|
|
The first one (w1d10) got one zombie during an unattended 12-hour run. It replugged with no problem. I'll try w2d10 now. "w1d10" has been mining for 3 hours now and no actual zombies yet, but it is behaving rather strangely. I am regularly getting "rafts" of LEDs coming on - perhaps 15 or more, then another 1,2,3.... 7,8 or so, making 17-25 all on at once, then they all go out and everything looks normal again. Nothing abnormal in the log file and my hash rate is ok at the pool. I would say this looks very promising - if it were not for the disconcerting appearance of seeing all those LEDs going on and off...!! Edit: Of course it could be my wonderful (not!) broadband playing up - but that typically results in *all* LEDs coming on for 5 seconds or so and then going off en-masse. What I'm seeing here happens perhaps once every 10, 15 or 30 minutes, and no "pool unavailable" messages. Thanks very much for that. I'm pretty sure this is the right track since kano confirms it fixes his 3 AMUs mining on a USB3 hub on his RPi which previously wouldn't work at all unless he daisy chained it via a USB2 one. I don't think the -rw* versions will need to be tested and it will be a matter of whether it's 1d10 or whether I need 2d10 to roll a double 0 ftw. Finally got an error - AMIU 27 LED full on but no zombie reported. The hash rate is sitting at zero. Screenshot in logfile. I enabled debug for a while then tried manual re-plugging. Device appeared as zombie when removed, then when re-plugged it appeared as AMU 34. 2nd screenshot also in file. Test then ended. I'll try w2d10 next. Logfile here: https://dl.dropboxusercontent.com/u/44240170/logfile-w1d10.txtNote: Just started w2d10 and it does the same strange thing as w1d10 at startup - all AMU LEDs go off as normal, then they all come back on again. It takes a second or so for a few to go out, then it works a while with just those few, then the rest go out and mining continues with all devices. Note 2: I have a zombie AMU 10 already after only a a few minutes... Manually re-plugged as AMU 34. Test continuing. |
|
|
|
The first one (w1d10) got one zombie during an unattended 12-hour run. It replugged with no problem. I'll try w2d10 now. "w1d10" has been mining for 3 hours now and no actual zombies yet, but it is behaving rather strangely. I am regularly getting "rafts" of LEDs coming on - perhaps 15 or more, then another 1,2,3.... 7,8 or so, making 17-25 all on at once, then they all go out and everything looks normal again. Nothing abnormal in the log file and my hash rate is ok at the pool. I would say this looks very promising - if it were not for the disconcerting appearance of seeing all those LEDs going on and off...!! Edit: Of course it could be my wonderful (not!) broadband playing up - but that typically results in *all* LEDs coming on for 5 seconds or so and then going off en-masse. What I'm seeing here happens perhaps once every 10, 15 or 30 minutes, and no "pool unavailable" messages. |
|
|
|
My most recent normal 3.8.4 test ran about 12 hours without incident - no zombies at all. I've just run the "sw" test and it has one zombie after about an hour, AMU5. Edit: another zombie with the "sw" test, about 5 hours into the run. Curiously, this one was also reported as AMU5 although it wasn't the same physical device as above. Unplugging it did not change its status to AMU0, unlike many of the earlier versions. On replug it was reallocated to AMU14 and the numbering overall suggests it had actually been AMU7 that went zombie this time. Present numbering is AMU0-4, 6, 8-14 so I think the first zombie, AMU5, was reallocated to AMU13 on replug. The "sw" run continues. I found an Amazon (Canada) listing for the hubs I'm using, fwiw: http://www.amazon.ca/gp/product/B009Z9M3DYI just noticed this phrase in the blurb for them "Smart chip power management allows devices to communicate idle states and latency tolerance for progressively lower power states and subsequently increased performance and power efficiency". Don't know if it's relevant. I am running 3 10-port Anker hubs and an old 4-port hub, all individually powered and plugged directly into the PC. No daisy-chaining. Interestingly I don't remember ever seeing one of the 4-port devices going zombie... So... On an initial test of "sw" without logging, I noticed some LEDs come on for several seconds then go out, and mining continued OK. Another time a zombie was reported but it re-plugged automatically. Then several zombies came up which did not re-plug automatically and I noticed "icarus detect - incorrect device" warnings. I don't know if these are new with this build or not, but when they came up I did examine the whole table in Zadig to check if AMUs had been re-assigned to slots with incorrect driver software - but they all looked OK. Powered the hubs off/on to reset everything as usual. On this run (with logging), a zombie (AMU 22) appeared after about a minute, which did not re-plug automatically. Manual re-plugging worked OK, but I stopped the test because I was going out and wanted to be sure the miner would keep running. It seems that this version tries hard to keep things going, but I seem to be seeing more initial disturbances (LEDs on for a second or more then disappearing, then maybe a zombie which replugs automatically etc.) I don't see any of that with 3.5.1, and as I'm normally sitting right next to the Erupters working away at the PC, any unusual flashing immediately catches the eye. Logfile here, for what it's worth: https://dl.dropboxusercontent.com/u/44240170/logfile-sw.txt |
|
|
|
Similar results here - 2 Win7 machines, each got zombies from time to time. In fact, each got a cluster of them at different times - haven't seen that behavior in a while. Both machines are fine with 3.8.4 at the moment.
Thanks. Yes that's the typical windows fail I've been trying to work around: When there's some kind of usb communication lag it affects everything on the bus. To be clear, when you get zombies, do they eventually re-hotplug for you? They do not for JMC Yes that's correct with the later versions (zombies stay as zombies), although sorry to labour the point, but they usually do re-plug automatically with 3.5.1 and earlier. Usually but not always! I do get the occasional permanent failure with 3.5.1, but it is quite rare. Also in 3.5.1, very occasionally an AMU just falls behind and/or just stops handling traffic (Accepted shares stops increasing and/or WU slowly decreases). Just to clarify  |
|
|
|
Stopped cgminer 35.1. after about 23 hours. No faults again Tried cgminer-900t but it doesn't detect my devices. I get the following: [2013-11-29 17:13:30] Started cgminer 3.8.3 [2013-11-29 17:13:30] Loaded configuration file cgminer.conf [2013-11-29 17:13:35] No devices detected! [2013-11-29 17:13:35] Waiting for USB hotplug devices or press q to quit [2013-11-29 17:13:35] Too many values passed to set temp cutoff I did try it (I think) also with 3.5.1 already running and it gives me some messages "devices already in use." So Something seems slightly confused. I am loading my original 3.5.1 config file. Is there something in that which would confuse it? Sorry don't have time to investigate further now, but I'll come back and check it out a bit more thoroughly later if you think it may be my setup which needs tweeking for this build -- but then again, why should it? |
|
|
|
OK, tests done. Usual aside: Previous run of 3.5.1 stopped after 18 hours. No faults. Test of cgminer-w00t started at 12:50. After about 5 minutes one LED (AMU 16) came on solid but no zombie was reported in the screen display. I turned on debug and let it run for a few minutes, then I intended to re-plug the offending AMU and continue, but unfortunately I accidentally hit the power button on the hub and turned the whole thing off. D'oh! Test stopped at that point. I'll run it again if you need more information. Test of cgminer-9001 started at 13:01. It ran for over 5 hours before a zombie (AMU27) appeared. Turned on debug and let it run a bit more, then stopped the test at 18:45. This one was looking quite promising until the fault popped up. Pity. Logfiles are here: https://dl.dropboxusercontent.com/u/44240170/logfile-w00t.txt https://dl.dropboxusercontent.com/u/44240170/logfile-9001.txtAnd.... Back to 3.5.1 |
|
|
|
OK, tested! Aside [again] The previous run of 3.5.1 lasted 25 hours without problems, although I do remember seeing a few AMU LEDs come on yesterday for a couple of seconds and I noticed some messages which were something like the following (completely from memory, as no logging enabled, can't remember the exact mS timings): [2013-11-xx xx:xx:xx] TIMEOUT AMUx something took xxx mS, was xxx mS [2013-11-xx xx:xx:xx] TIMEOUT AMUy something took xxx mS, was xxx mS The above disturbances didn't cause any problems, so it may just be normal network problems, but I haven't noticed them before, so perhaps it's important, perhaps not. Anyway, the test of cgminer-ffs ran for almost 2 hours, then a zombie appeared. I turned on debug from the display and let run for a further 5 minutes, then stopped it. Logfile is here: https://dl.dropboxusercontent.com/u/44240170/logfile-ffs.txtAnd.... back to 3.5.1 for the evening! |
|
|
|
Can you try fff again and this time when it gets into the loop of errors, enable debug in the display menu and continue logging for a bit please? OK, done. Aside: The previous overnight run of 3.5.1 went for 14 hours, no faults. Started cgminer-fff again. After about 3 hours I got several LEDs full on for a few seconds. Two of them went out and resumed mining but the 3rd appeared in the display as a zombie. I was sitting next to the PC at the time, so turned on debug straight away. I left it running for a further 5 minutes then stopped it. Logfile here, but I suspect it's not going to help: https://dl.dropboxusercontent.com/u/44240170/logfile-fff2.txtAnd...... Back to 3.5.1 again :/ |
|
|
|
So, having returned from holiday leaving "ymmv" running unattended for 2 weeks, I found 1 reported zombie and another 4 or 5 AMUs which had a very low WU, and had obviously been doing nothing for a while. While I was away I was monitoring my pool hash rate and noticed that it slowly dropped from an expected 11 Gh/s to around 9.x over the two weeks which ties in with the above findings.
I restarted "ymmv" but got several random LEDs coming full on for a few seconds at a time then going off again. Obviously not happy, so I then reverted to running 3.5.1 which ran perfectly and has been doing so all night with no zombies and all WU's between 4.6 - 4.8. This build is so stable!
I guess I will try 3.8.3 next unless there are other suggestions?
3.8.3 is the next one to test... Started the test of cgminer-3.8.3 at 13:57. First zombie (AMU20) appeared briefly at 14:05 but it auto-started working again as AMU34. Two more zombies appeared at 14:12 and 14:24 (AMU10 and AMU13) and they did not recover. I stopped the test at 14:49 as there didn't seem to be much point in continuing. The previous run of 3.5.1 was rock-solid for 13 hours, and I've included a screenshot of it at the top of logfile-3.8.3. All looks well with that run to me - no anomalies. Unfortunately I didn't manage to produce a screenshot of 3.8.3 before stopping it as the CMD window seemed to be continually refreshing and it wouldn't "hold" a selection to enable copying. Logfile is here (without --debug): https://dl.dropboxusercontent.com/u/44240170/logfile-3.8.3.txtBack to 3.5.1 for the time being then... |
|
|
|
|
Trying to start with Fastcoin. Is this still valid, if so please send here: ffGR42Sagm27EEYx49rQUpMs5qYYmMbCkC
thanks....
|
|
|
|
|
So, having returned from holiday leaving "ymmv" running unattended for 2 weeks, I found 1 reported zombie and another 4 or 5 AMUs which had a very low WU, and had obviously been doing nothing for a while. While I was away I was monitoring my pool hash rate and noticed that it slowly dropped from an expected 11 Gh/s to around 9.x over the two weeks which ties in with the above findings.
I restarted "ymmv" but got several random LEDs coming full on for a few seconds at a time then going off again. Obviously not happy, so I then reverted to running 3.5.1 which ran perfectly and has been doing so all night with no zombies and all WU's between 4.6 - 4.8. This build is so stable!
I guess I will try 3.8.3 next unless there are other suggestions?
|
|
|
|
Well I'm still on holiday for another week yet, but having just caught up with the last week's messages, I'm itching to do some more testing! My ongoing run with "ymmv" seems to be down from 11Gh/s to 9.xGh/s - so it looks like several AMUs have stopped working (I can't access the machine to check directly - I'm just looking at my pool stats.) Laterz... |
|
|
|
cgminer-ymmv still going strong. I will be away for 1-2 weeks so no more testing from me during that time, but I will leave this test version running while I'm away. Hope to see the fixes present in ymmv make it to the next release Oh, and keep up the good work. It's all very much appreciated. |
|
|
|
New wrinkle? My ymmv run is 24 hours old, but some time during it AMU7 went zombie. I'll swap it now if possible and keep the run going.
Edit: Weirdness - the hot swap had no effect. A "Q" and restart seemed to work, all LEDs went off on restart and flicker normally but the display shows one AMU missing. The physical AMUs look normal, including the former zombie, but the display shows 0-11 rather than 0-12 - total physical AMUs are 13 for this machine. I'll disconnect them all and/or try another Q and restart next.
Edit: The Q and restart changed nothing. Even after restart the display showed AMUs 0-11 rather than 0-12. I then disconnected the main USB line from the (daisy-chained) hubs. All (12, not 13) AMUs reported zombie status, as expected. When I reconnected the hubs the AMUs were reallocated as 12-24, thirteen of them now as there should be. Bug gone, but cause unknown.
Re: New wrinkle: I've experienced the same, but would assume that it's normal for a zombie not to be recoverable simply by stopping/starting cgminer(?). Whenever I've had zombies I got into the habit of powering off/on all the hubs and therefore cold-starting all the AMUs. I think it was past experience with older versions of cgminer that taught me that I needed to do that otherwise I would have AMUs missing. Of course it may have changed with newer versions, but having got into the habit, I always stop cgminer, then power off/on, then restart cgminer to fix the problem. YMMV ! |
|
|
|
Sync transfers. Except for regular gross timeout overflows. [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? |
|
|
|
|
