|
The little screw/knob in the bottom corner, turn it clockwise just a little. Factory spec is 1.48V but the full range is about 1.40 to 1.60 volts so there's plenty of headroom. A little goes a long way - we saw a measurable increase in burn-in test performance from changing the default setpoint of 1.44 to 1.48
Rule of thumb with cooling is literally a rule of thumb. If it hurts to put your thumb on the heatsink, you need more cooling.
The controller is whatever USB host computer thing you're running on. That shouldn't be a problem with only three sticks; a basic Pi can handle more than that load.
|
|
|
|
|
Make sure it's staying cool
Turn up the voltage a bit
If you know you have adequate power and your controller is strong enough to run three sticks, that's the bulk of it.
|
|
|
|
Also we tend to over-build, so it'll probably still work without that part. eeeehhh yes and no.... I assume that is a large value cap in parallel with the bank of lower value caps right? Ja the ASIC chip may still be operating because the DC is 'reasonably clean and good enough' but it would be interesting to probe there and at the chips power pads to look at the switching spikes with and w/o that cap... It is far too common for power supply designers that want to feed high current/high speed digital circuits to neglect the fact that chip switching speeds are deep into the RF spectrum making the DC power planes feeding them a transmission line. The end result is that as the gates inside of the chip switch the signal and DC power voltages at the chip pins can/will be quite different than what you probe and see as you get away from the chip. Point is ya should verify the at the chip itself that the Vcore referenced to its return pads along with the data eyes into/out of the chip look solid even without the cap. Neglecting that is one of the things that back in early 2014 killed Bitmine.ch's based Coincraft miner using their A1 chip that they paid Innosilicon to design and work with a Foundry(TSMC) to source. Well, that and totally neglecting the fact that that you also need sizeable heat sinks on top of the ASIC's... The folks that did things right used the same A1 chip in their legendary Dragon miners had great success with them... There's 300uF (minus DC bias derating) of ceramics and a 470uF tant/poly at the regulator output, and then another 330uF tant/poly for bulk plus some 4.7uF and 0.1uF ceramics for high frequency bypass right at the power pads of the ASIC. It would probably run fine with either of the tant/poly missing, but not both. |
|
|
|
|
Also we tend to over-build, so it'll probably still work without that part.
|
|
|
|
|
When testing the new regulator design for the current version, I pushed a stick to 600MHz on our burn-in tester and ran it for a day, worked beautifully. 800MHz, I'm not sure what that would look like power-wise.
A T17+ 64TH pushes around 22W into the chip for neighborhood 720MHz, so estimate 25W into the chip for 800MHz (which the main regulator can handle) means about 5.5 amps from the USB port. That's not safe. If you could solder lines to pipe current in directly as suggested above, and if you could cool the chip effectively, the rest of the stick should be able to keep up.
|
|
|
|
|
That was an idea we had at the beginning but which wasn't implemented.
|
|
|
|
|
If you've got a half-decent hot air soldering station, or an iron and some skills, replacing a regulator chip is pretty easy.
|
|
|
|
|
I can, yes. In related news, we're working on a new hub design with better failure protection and power handling.
The ports being disabled by cgminer, more likely what's happening is the regulator's running weak or hot and when two sticks are plugged in, it's turning off.
The lines between ports on the top case indicate which ports share a voltage regulator. It's also noted on the label on the bottom. If you're having trouble, try 3 sticks per hub, one per linked pair. Might also help to provide a bit of airflow into the hub itself.
|
|
|
|
|
Probably the voltage regulator chip roasted. Who'd you buy it from?
|
|
|
|
|
No, I just haven't updated my sig for a while. I've kinda given up on the upgrade kits, seeing as the last miner with that chassis stopped shipping like six years ago. There's some other fun stuff in the mix, and I'm hoping to have several product announcements between now and year's end.
|
|
|
|
|
If you can, it'll probably be better to not daisy-chain your hubs though.
|
|
|
|
|
You could also roll back to a cgminer version older than the U3, or try to build with an Icarus driver older than the U3. The icarus driver which handles most USB miners from then uses pretty simple logic to tell one from another; along the lines of "oh, XXX is the USB chip? Well send this data and see what comes back. Oh YYY is the return string? Eh, probably ZZZ miner." Not sure I've seen a U2 detect as a U3 before, but it's not unbelievable. U2 has 1x S1 chip, U3 has 4x S3 chips. We based the early Compac (1x S5 chip) driver on the U3 portion of icarus because it detected as a U3 by default also.
|
|
|
|
|
I'm not sure offhand what options there are in cgminer but you should be able to isolate individual or collections of sticks to a single instance of cgminer. Our testers run a debian PC with two USB busses each piped to hubs, so we run two instances of cgminer, one locked to each bus using a command-line flag. VH's driver I believe had settings to load in sticks by serial number but I don't remember if kano carried that over for the Compac F driver.
In general, unless you specifically tell cgminer otherwise, it'll load in every stick on the controller and use them as a combined hashrate for the given pool connection, like /Fuzzy said.
|
|
|
|
|
Nuts, beat me to the punch. I've been working on something similar.
|
|
|
|
Where are you looking for stock? Here's the official resellers. It's always best to buy from 419Mining, ASICPuppy, MineFarmBuy, BitcoinMerch, Eyeboot or bitshopper.de because those are the guys I've trusted for years to take care of things for their people.
|
|
|
|
|
It could be an old Compac just running like balls under the wrong cgminer, detected as an Antminer U3 pod via Icarus.
|
|
|
|
|
AU3? Either that's not a Gekko device, or you're using the wrong version of cgminer.
|
|
|
|
|
No mining ASIC will send back the hash. They all send back the nonce, and the output will be random because that's just the nature of hashing. If fewer responses come back from something with a higher hash rate, it's probably because of the ticket mask - a system to reduce IO load by ignoring nonces for a hash below a certain threshold. It's just like the pool target difficulty but internal to the hardware.
More nonces doesn't mean a better chip. More diff-1 nonces sure, but the actual nonce count must be scaled against the share value.
We've had some inquiries to Intel, but no news to report yet.
|
|
|
|
|
Bitshopper.de is the authorized reseller for the EU region. He got forced into some extra work for CE registration but, from what I understand, should have sales re-opened soon.
|
|
|
|
|
Show Posts
