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. |
|
|
|
I've put up a new version of cgminer, 3.8.1 with improvements to the blue/red fury devices.
Any idea why i get this errors on BF1s ? [2013-11-12 23:08:58] Hotplug: bitfury added BF1 5
[2013-11-12 23:08:58] BF1 5 BF1RequestWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
[2013-11-12 23:08:58] BF1 5: Device disappeared, disabling thread
[2013-11-12 23:08:58] BF1 5 failure, disabling!
And it is random on time and also on device. I run cgminer 3.8.1 on Debian 7.1. It is not runing on RPi. There is no pencil mod. There are 5 BEs and 5 BF1s, each od them on its own USB hub ( 3,5A powered). It was try with connection of hubs into cascade ( BF1s hub connected to BEs hub and this to computer) and also try to connect hubs directly to computer and always the same result. If i reset BF1s with reset switch on board it comes back. Today i "upgraded" to version 3.8.3 and i still get this LIBUSB error: [2013-11-23 12:12:24] Hotplug: bitfury added BF1 8
[2013-11-23 12:12:38] BF1 8 BF1RequestWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
[2013-11-23 12:12:38] BF1 8: Device disappeared, disabling thread
[2013-11-23 12:12:38] BF1 8 failure, disabling!
Does anyone else have this issue ? If the device disappears and shows up as ZOMBIE and never re-hotplugs, there's nothing there on the USB any more for cgminer to talk to, so something is causing USB flakiness there. Check what 'dmesg' shows you after this has happened. There's not much the software can do if the device is effectively disappearing from the USB hub. If on the other hand the device is still there and it's just cgminer dropping out, it's possible that cgminer is too trigger happy - but if that were the case it would re-hotplug soon after. |
|
|
|
Calm down folks. I just posted it to let people know it happens even to developers, and have read what people suggested, but none of those fixed my particular issue. Every time I try one of those fixes things seem to just get a little worse so I'm afraid to touch it now...
Conman - did you try the hard reset - 5 times + 5secs + 5 times? Yep, didn't make a difference. thx & sorry it didnt help. you made it quite clear nothing advised had helped but some people need it literally spelled out to get a clue. what GH/s rate are you getting now? mine has s.l.o.w.l.y crawled up to 530.1Gh/s over the past few days. could be and has been a lot worse. It eventually speeds up to almost normal hashrate, but is laggy as in connecting and never quite averages as much as it used to because of that, making rejects worse too. Maybe it's just coincidence and the problem is elsewhere in my network but the timing with happening from the moment I upgraded to 0.99 is hard to ignore when I haven't changed anything else. Downgrading didn't fix it either. |
|
|
|
Calm down folks. I just posted it to let people know it happens even to developers, and have read what people suggested, but none of those fixed my particular issue. Every time I try one of those fixes things seem to just get a little worse so I'm afraid to touch it now...
I read something last night where someone had networking problems and they ran a script to reset the network card. I'll try and find it Yes I saw that thanks, it was about the BBB dhcp implementation. Didn't help me. Think I should be satisfied that it's mining at all and leave it, but the hardware's too new to stop developing for it just yet  |
|
|
|
Calm down folks. I just posted it to let people know it happens even to developers, and have read what people suggested, but none of those fixed my particular issue. Every time I try one of those fixes things seem to just get a little worse so I'm afraid to touch it now...
Conman - did you try the hard reset - 5 times + 5secs + 5 times? Yep, didn't make a difference. |
|
|
|
|
Calm down folks. I just posted it to let people know it happens even to developers, and have read what people suggested, but none of those fixed my particular issue. Every time I try one of those fixes things seem to just get a little worse so I'm afraid to touch it now...
|
|
|
|
I got an attack of the network lags after upgrading to 0.99  Downgrading didn't help, powering down, restarting and rebooting didn't help. Even with cgminer not running ping times can take up to 2 seconds. SSH'ing in is excruciatingly slow. One time I couldn't even ssh in until I restarted it again. I just barely got it mining again. I saw others had gremlins that went away, but I can't seem to find any way to repair it. |
|
|
|
In two my laptops (Samsung and Toshiba) the BEs in Tecknet USB 3.0 10 port hub works stable only if hub is connected to one of USB port and does not using another.
Write timeouts appears there. What it can be the difference in laptops USB ports?
WinUSB driver 6.1.7600.16385 is in use, set up by zadig utility. OSes are different, win 8 x64 and win 7 x64.
USB 3 drivers on windows are inconsistent and have conflicts with the usb1.1 devices (like BEs) and the libusb library we use to talk to them. USB2 slots are infinitely more compatible (or use linux). |
|
|
|
can anyone tell me the difficulty of this hash
000000000000000001480bf37765db8beb84651395cc36e76e2c4e36fbb51026
About 858,000,000,000 |
|
|
|
|
Show Posts
