|
Catastrophic usb communication failure will make the operating system reset the device and put it on another usb minor number. When this happens, cgminer will hotplug it as a new device - i.e. AVA1 and AVA0 will remain as a zombie device. The web GUI and Avalon operating system environment is not smart enough and may not know that it's still mining at a new location and would just kill off the cgminer whereas mining via USB you'll see that in all its glory.
|
|
|
|
though this is in no way able of effecting the performance of the VRMs, right?
Not directly, but by disabling as many cores reliably as you "need" to have disabled, the power delivery will need to fluctuate far less so... who knows? |
|
|
|
Updated that binary again. It delays re-enabling them progressively more every time they're disabled. The delay between disables is back and there is now a message saying that the cores are being enabled and have finished enabling at startup. It takes ~20 seconds on my saturn! Followup. This binary has had the most consistent (and highest) hashrates and lowest hardware errors for my Saturn. The average hashrate is ever so slightly creeping up even after 24 hours. The difference is not profound mind you... [ASC0] =>
(
[ASC] => 0
[Name] => KnC
[ID] => 0
[Enabled] => Y
[Status] => Alive
[Temperature] => 0.00
[MHS av] => 278152.70
[MHS 5s] => 263840.40
[Accepted] => 25751
[Rejected] => 89
[Hardware Errors] => 73402
[Utility] => 16.82
[Last Share Pool] => 0
[Last Share Time] => 1385349716
[Total MH] => 25555768375.7636
[Diff1 Work] => 5950171
[Difficulty Accepted] => 5935217.00000000
[Difficulty Rejected] => 20456.00000000
[Last Share Difficulty] => 231.00000000
[Last Valid Work] => 1385349718
[Device Hardware%] => 1.2186
[Device Rejected%] => 0.3438
[Device Elapsed] => 91877
)
|
|
|
|
I've been running mine off USB cable to my PC for months. Even tried it on windows just to be sure and it works fine, but linux is always better for this. Plug the usb cable from you pc into the printer type connector on the board, unplugging the usb cable that's going from the little tp-link router to it. You can pull out the pin next to it that gives power to the tplink router but even that step's not essential. If you're on windows, wait for windows to try and install a driver for it - it will be the wrong thing for cgminer. After it's finished proudly telling you it has installed a driver, run zadig as an administrator and look for the ftdi device and switch it to WinUSB. Then you can run cgminer as per any other device (make sure to use 3.8.3 to get the stable avalon code). If you give cgminer no command line options it should still work with the avalon, but of course you'll have to start adding commands to make the most of it. It should look something like this: AVA 0: 25C/ 48C 2400R | 86.99G/83.45Gh/s | A:70143 R:695 HW:1281 WU:1165.8/m
I only have this in my configuration file for a batch 2 3 module unit: "avalon-options" : "115200:24:10:d:353" |
|
|
|
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... Thanks for that. Here is your next test please http://ck.kolivas.org/apps/cgminer/temp/cgminer-rst.exe |
|
|
|
Thank you for the update. Do you think this version should help with my USB device in use issue? I use Raspberry PI and ASIC Butterfly 30 GHs.
I have configured auto start of cgminer 3.8.2, which works perfectly.
But it always reports "USB device in use" type of message, if I remove power cord and put it back in this case. (My test of auto recovery.)
I need to manually delete /tmp/cgminer-usb-1-4 file then to cgminer be able to access the ASIC USB device.
Could you advice how to automate process the way that the cgminer will always have access to USB device? It's supposed to be automated... Seems to be that the restart never works on these devices. Only quit followed by starting cgminer again does. Are you using the restart command or doing quit followed by starting it again? EDIT: Are you SURE there isn't another cgminer running? That's what that's there for in the first place... |
|
|
|
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... |
|
|
|
What does
hex2bin scan failed
mean? Using 3.8.3 with my Jalapeno.
Sam
That's bad, mmkay. Some code screw up on my part. Got some more output so I can figure out where the fuckage happened? Well here's a screen capture. I had moved the Jalapeno to an old low power machine and got this. On my normal rig it works fine. So I'm not sure it's not a problem on my old machine. cgminer version 3.8.3 - Started: [2013-11-23 22:47:12]
----------------------------------------------------------------------------
(5s):0.000 (avg):0.000h/s | A:0 R:0 HW:9 WU:0.0/m
ST: 2 SS: 0 NB: 1 LW: 23 GF: 0 RF: 0
Connected to stratum.btcguild.com diff 4 with stratum as user os2sam_Jalape
Block: 6eb3b7ad... Diff:609M Started: [22:47:12] Best share: 0
----------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
BAJ 0: max 25C 3.49V | 0.000/ 0.000h/s | A:0 R:0 HW:9 WU:0.0/m
----------------------------------------------------------------------------
[2013-11-23 22:47:02] Started cgminer 3.8.3
[2013-11-23 22:47:10] Probing for an alive pool
[2013-11-23 22:47:12] Pool 0 difficulty changed to 2
[2013-11-23 22:47:12] Pool 0 difficulty changed to 4
[2013-11-23 22:47:12] Network diff set to 609M
[2013-11-23 22:47:13] hex2bin scan failed
[2013-11-23 22:47:13] Pool 2 slow/down or URL or credentials invalid
[2013-11-23 22:47:14] hex2bin scan failed
[2013-11-23 22:47:15] hex2bin scan failed
[2013-11-23 22:47:15] hex2bin scan failed
[2013-11-23 22:47:16] hex2bin scan failed
[2013-11-23 22:47:17] hex2bin scan failed
[2013-11-23 22:47:17] hex2bin scan failed
[2013-11-23 22:47:18] hex2bin scan failed
[2013-11-23 22:47:19] hex2bin scan failed
[2013-11-23 22:47:22] BAJ0: empty result (INPROCESS:10x0aCOUNT:20x0a9FF7FB8
A5F26106934BA7BA68FEB1F1D693B8B1`636DD791B2F53AAAE3CEDB,FEA0DFDF529185321907
,00x0a57C7A36DC1291`574DA63990BBCC160x00) ignored
[2013-11-23 22:47:31] BAJ0: empty result (INPROCESS:00x0aCOUN0x00) ignored
[2013-11-23 22:47:39] BAJ0: empty result (INPROCESS:00x0aCOUN0x00) ignored Ah I see. The BAJ should only respond with text data that is in hexadecimal form and is sending back corrupted data that is not so it can't decipher the messages. Might happen on startup with an indeterminate device state with old data or with usb corruption. |
|
|
|
What does
hex2bin scan failed
mean? Using 3.8.3 with my Jalapeno.
Sam
That's bad, mmkay. Some code screw up on my part. Got some more output so I can figure out where the fuckage happened? |
|
|
|
At these BTC values, the scams are coming thick and fast  |
|
|
|
Updated that binary again. It delays re-enabling them progressively more every time they're disabled. The delay between disables is back and there is now a message saying that the cores are being enabled and have finished enabling at startup. It takes ~20 seconds on my saturn! |
|
|
|
New version of cgminer out, 3.8.3 with minor improvements for these devices.
Well, I updated MinePeon was CGMiner 3.8.3 also, was helping out Maidak with his setup & both systems (his and mine) keep zombie'ing all devices within several minutes of running on 3.8.3... fuck it I will stick with bg miner the pencil mod has been rock solid 2.61 4% error rate. nice spot on the resistor issues Probably just trigger happy then for slower hardware. I've relaxed the timeout duration in git master but if you've lost interest that's fine. |
|
|
|
Capitalising on the fact that I saw that dud cores are better disabled, here's an experimental binary that tunes things fairly aggressively: http://ck.kolivas.org/apps/cgminer/kncminer/cgminerFirst it enables all cores on startup (so it can take a while before it starts mining!) Then it will disable cores after only 3 hw errors in a row, but staggers disabling of cores 5 seconds apart. Then it tries re-enabling cores after only another minute, but staggers re-enabling them. If the cores fail 3 times in a row, they're decommissioned at that point. Update Here is that last binary without the experimental tuning for those that requested it: http://ck.kolivas.org/apps/cgminer/kncminer/cgminerI've renamed the experimental one. Here is an updated one with more tweaks to the tuning (does not delay before disabling): http://ck.kolivas.org/apps/cgminer/kncminer/cgminer-tune(Be patient before deciding what its performance is like since it takes many minutes to stabilise) I did nothing to the API that wasn't in the previous binary. The most likely thing if it's not working is either you changed your api allow commands, or there were two cgminer binaries running at once and one was holding onto the port while it was shutting down, not allowing the new binary to bind to the port. |
|
|
|
Capitalising on the fact that I saw that dud cores are better disabled, here's an experimental binary that tunes things fairly aggressively: http://ck.kolivas.org/apps/cgminer/kncminer/cgminerFirst it enables all cores on startup (so it can take a while before it starts mining!) Then it will disable cores after only 3 hw errors in a row, but staggers disabling of cores 5 seconds apart. Then it tries re-enabling cores after only another minute, but staggers re-enabling them. If the cores fail 3 times in a row, they're decommissioned at that point. |
|
|
|
RED HERRING TIME  Found that the ping time to my wireless access point that serviced it was also slow. I disabled some of the fancier features (WMM and short GI) and the ping times improved (though it might have just been rebooting it a few times that did it), and along with it the connectivity to the saturn. Thanks for those that tried to help. Sometimes it's just not the hardware at fault at all :blush: |
|
|
|
does this give you any clues as to a next step?
are you privy to the 'tuning suite' development at all?
also are you using 3 PCI-e cables or 4 or a twin molex to PCI-e??
No No No I only have a saturn  so 2 PCI-e cables and 1 molex. I did some experimenting with much less aggressive disabling of cores and found it had absolutely no useful effect on hashrate. They're being disabled for a reason. |
|
|
|
sent u a lil something with thanks!
- also hno is in the knc chan now
Thanks! Just checked the scrollback and realised he said: <hno> conman, that sounds as something else. There is no networking changes in 0.99. was drowned out amongst talk of porn, anime and random other stuff... |
|
|
|
Wasn't there a scrypt readme somewhere? I can't find it anymore  No scrypt support any more. |
|
|
|
is this where donations are sent?
148KkS2vgVi4VzUi4JcKzM2PMaMVPi3nnq
For me, yes indeed that is one address I gladly accept donations  |
|
|
|
I know its' saturday but just try to join kncminer channel @ freenode, hno's usuallly to be there most of the time.
He's in the #cgminer channel too as we've talked before  Seems he's been afk. |
|
|
|
|
Show Posts
