Topic: Block Erupter USB - Overclocking/ hacking ? - page 16. (Read 168765 times)

The icarus driver does infact re-calulcate the timings, if the hash rate is below 370 or above 420 MH/s.

With this old version you have to specify a device, this should work:
# cgminer -S /dev/ttyUSB0 --icarus-timing short

However, good to know you got the BE hasing.

I built bfgminer 3.1.4 on gentoo and you were right "-S all" made this with a 17 MHz clk. a small amount over but I'll run a longer test. When I ran it I saw this

[2013-08-24 09:29:54] ICA 0: Seems too fast to be an Icarus; calibrating with short timing

when I killed it off.

 [2013-08-24 09:29:19] Runtime: 0 hrs : 16 mins : 9 secs                   
 [2013-08-24 09:29:19] Average hashrate: 497.2 Megahash/s 

So good job. who knows how much time I may have wasted working on this when it was working, I guess this means all my theories were wrong and the problem was on the PC. But after reading some of the code I guess they only poll the device when they know it has used all the hashes up.. nice

Bitminter seems to have no such timing issues, it does tuning before it starts which may explain why I've had such good luck with overclocking.

I'll give both those things a try, sadly the box is a remote gentoo box on a raspberry pi so building things takes a little time.

Tried cgminer 3.1.1, didn't detect the BE

As far as I can remember, latest cgminer versions using as well fixed timings. Last version with timing adjustment was 3.1.1. You might use the "--icarus-timing short" option with 3.1.1 for automatic adjustment.

Edit: Here is a nice read regarding icarus-timing option -> https://bitcointalk.org/index.php?topic=187549.msg2285149;topicseen#msg2285149

Wow, great news that you recognized the symptom.  Sadly I'm on a plane out of town for a week.  Anyone else want to try this suggestion?  Or...  Anyone with a working O/C want to try cgminer and see if it trainwrecks?

I continue to suspect the firmware.  I modded a device to 16MHz today, and got the same behavior as other failed overclockers.  I'll describe it as follows: Startup fine, recognition fine.  Then green LED goes out for a bit as cgminer takes over, and gives fast blinks on first few accepts.  But as soon as the reported hash rate starts ramping up, it trainwrecks: you get a long-ish blink and hash rate starts over from 0.  It really looks like if the hash is returned quicker than the micro expects, it flushes everything (I'm assuming it's pipelined, to get one hash per clock) and starts over.  Valid accepts are certainly generated when it's running, just the device keeps resetting after a bit.  Hash rate definitely exceeded 335, but I'd say I never saw higher than about 380Mhz peak with a 16.000M osc before it resets.

I tried several feedback resistors (1.2k, 1.33k, 1.4k) and the action was the same except for increased supply current.  Scope tells me the clock is good, the core supply is good and chip is definitely not in overcurrent (better inductor + external 5V).  Heat was not an issue: With a big slab heatsink, chip temp was lower than running stock, and way lower than running stock with no forced air.  So this sounds like one of a couple of things.

1) It's an honest bug, due to a slowly clocked micro (clock limited to 12MHz using 3.3v supply, check the d/s).  Starts reading too late, gets the wrong answer and bails out.  Or gets totally munged and a watchdog eventually kicks it.  If there is no interrupt or anything, and it's really pipelining up to 1 clock per hash, it could be a very delicate balancing act to push and pull data quick enough to feed the asic without trainwrecking.  Anyone who knows a little more nuts and bolts about this chip, please chime in.  

2) It's a new "feature" to best monetize dollars per hash rate.  My devices are not the first build, so maybe firmware was updated in response to all the overclocking interest.  It would probably be quite easy: Check a timer, and if the asic is giving results too fast - user must be cheating.  Not that this is bad, or dishonest - it's asicminer's device, and you're paying your $50 for 335MH/s.  No more, no less.  But for us, it represents a limitation in the hardware we bought, and we have the desire to try to improve it.



I have not slurped the serial comms with a logic analyzer, but that's the next logical step in trying to figure out what's causing the resets.  Or fetching the firmware, but chances are it's locked.

Well I left it running at 17 Mhz, getting an average of 390 MH/s, it could be a power issue but I don't know, I feel that there is something else going on but w/o access to the MCU program it will be hard to tell. For some reason I am unable to leave well enough alone, my next plan is to build a schematic of the board and hook a bus capture on the MCU <-> BE100, I want to believe it is as simple as converting a serial stream to a parallel one and back. If it is simple enough , sometimes it turns out that way, then the BE100 could be interfaced more directly, thinking about it the data bus can not be to fast the MCU is only @11Mhz I would not image it could go to fast, although I don't have any atmel experience , it the MCU was a silabs then maybe. I find it kind of curious that lsusb reports this

Bus 001 Device 005: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light

The myAVR is interesting to me, I know some of the Ti MCUs can be programmed though the serial port.

I noticed it as well but I just chalked it up as a firmware bug because the higher frequency probably was not accounted for in the design. I wouldn't think it would have anything to do with hashing speed, it is interesting nonetheless. I may start hacking mine again in a couple days I won't be satisfied till I get 560Mhs. 

After a little more tinkering I was wondering, the ASIC is a hard wired device so changing the clock should have a direct effect on the output, I wondered if there is a timing issue between the BE100 and the MCU so I though I would change the speed of the MCU, of course it turns out it did not use an oscillator but a crystal so that made it a little harder, it really does not tolerate much speed increase due to changing the serial baud rate on the output side but it turned out to be to finicky and I don't guess there is an easy to change what baud rate the program communicates at (cgminer(re-compile I guess)), all the things I tried did't work at all so I but the crystal back on and went on.  After some testing I wound up with this. This is using 1.4v at the board, current is BE100 not 5V USB. This is a 10 min average.

Clock MHz     Actual MH/s(Avg.)     Expected MH/s      Current
12                   328              336               2.4A
13                   346              364              
14                   363              392               2.73A
15                   359              420               2.87A  
16                   376              448               3.02A
17                   390              476               3.12A
18                   381              504               3.20A
19               would not run        532               3.30A

Something I did notice, I put a logic analyzer on the end connections and at 12 MHz don't see much, but 12+ I see the pin that has been labeled in an early photo to invert for as long as the LED is on.

I am glad it has worked for a lot of people, I am just not seeing what I wanted to.

True, but to me as long as people realize that what they are doing can kill one and not act surprised when they smoke it.

Well I am not sure, I did mount it on a quite large heatsink and it looks to run about 107F normally, before it was around 135F with the stock  piece of metal.

I have gotten it going at 16MHz, with 1.43V @ 2.91A at the board, before made a rookie error , forgot to account for voltage drop in the cables, this supply does not have a remote sense so have to adjust it above what I want which is OK when it is running but when it goes idle the voltage of course jumps up.

After a couple of hours the average is 378 MH/s which at 16 MHz should be closer to 448 MH/s.

Yes replacing the parts is a little hard, unless you have a hot air station which helps a lot.

Off to experiment more...

Why would a block erupter be killed when being supplied by correct voltage?.... Not sure what you mean here.

One 448Mh/s one 458Mh/s. I dont think I will go for all BEE replacing 16Mhz ... I wonder what to do with the heatsinks I ordered.
Maybe i will stick them to normal Bees

Here you go the osc is the 16Mhz ones linked on here from digikey  and the heatsinks are some gpu  mem ones i had laying around.

How many MH/s do your sticks run?

I have noticed it also. (the green led thingy) but, when I addd some cooling ... it does not longer happens. So I think maybe the BE100 is overheating?
Also on my 108BEE's farm it happens from time to time. But it is a very short strong bleep.

Right now at 16Mhz 458 448 Mhz one on 1.4V the other on 1.3, Can tell right now wich one is which after 13 hours... it seems that its working but replace the crystal is darn hard.