Topic: New Official AMT Thread - page 80. (Read 149472 times)

Obvious Alert : this will be taken down

But how is it that you can see how you were treated and then treat your customers the exact same way.

Now don't get me wrong, you guys got screwed 6 ways from sunday there is no debating that fact. And just as it looked like you turned tail and ran for the hills you re emerged with a new found respect for the community. I'm sure there was legit reasoning behind your silence, probably due to legal issue you were working out with third parties. I can accept that.

What I can't accept is a "It's not that the boards don't work..." answer because the fact of the matter is the boards don't work on a technical level that you can reasonably  expect your average consumer to understand nor have the knowledge to fix. If I get a faulty TV the company can't reasonably expect me to wait 4 months while they find out what was wrong in their manufacturing process or have me take the TV apart to make find the problem my self.

You say it's about making bitcoin stronger not 3 month ROIs. Well you know what? It was about 3 month ROIs to your earliest orders who could have reasonably expected that if the product was indeed delivered when they were told it would be.

I came to your page way later than that date. I didn't expect a 3 month ROI. I did want an Positive ROI like anyone else who is buying from you. But I didn't sink my money in to coins, I sank it into a miner. Because it's not just you or zefir that cares about what bitcoin stands for or will potentially be. It's also the adopter of the technology, not just the creators, that drive growth and acceptance. A pile of (currently) useless boards doesn't strengthen bitcoin, but getting people up on the network does. I'm going to apply the fixes you've mentioned here in this thread in the hopes of getting something working up on the next work. But I'm not going to let the equipment burn in my apartment and potentially kill someone because it slipped through the hands of your quality assurance people.

I think you are just making this up about manufacturer problems and defective parts.

The reason I say this is that based on what you shipped and how you shipped it,  you seem to want to cut corners at every opportunity.  

So given the opportunity to acquire sub-standard parts,  you likely would have taken it.

In summary,  all you do is pretend to care about quality, but you never deliver on it.   

Now to be fair and although they ruined the business we need to not make them look like complete outlaws.They did order from Digi and mouser, but some of the hard to place parts were ordered from "a guy I knew that had them in stock". These were for the harder to find NXP parts and LTC's. But yes,when asked for invoices/proof of purchase we were met with weeks of delays followed by a stack of papers comparable to something you'd find in one of the Junior lawyers offices in our law firm. And "sure you can make copies, but we're closing now,maybe some time next".. bs bs..

I play the wave game as well now and then switching from dgm to pps.. Hit the jackpot on the last 2-day block with over 185 million pps shares good for 0.486 BTC vs the typical dgm payout of 0.046 BTC per-block I get Usually do not do as well with pps.

That explains the spikes I see at times. By the numbers my pharm is running 1.65THs yet often the pool reports 1.8-1.93 THS for several minutes as well as equal dips from nominal every now and then. Overall is on target with the numbers though @ 1.65-1.71

Yea, pools "calculate" your rewards... not all calculate fairly... (Some don't count work after a new block has been found, though you were honestly still working on the block it last told you to work on. Some do.)

That, and they calculate the "credit/shares" based off what you return. If you return only a few 256 diffs, and you are hashing at 256, you are 100%. If you submit a few lucky finds of 2048 and 4096 diffs, (though you are only hashing at 256-level), you seem to be doing 4x to 8x faster work... but that is usually neutralized by your submission of a few 256 diff shares, later.)

Also, depending on your credit, per shift... you may submit valid work after a shift is complete, which goes into the next shift. Thus, your last shift will be short, and your next closed shift will be higher. (The average there works-out in time too.)

I was recently on a server that gave me credit only for blocks in which I actually submitted a share to. (That was in improperly setup pool.) It rewarded some goof with super-low share-submits, the majority of the reward for those blocks, while the finder, who obviously submitted a much higher reward diff, got 1 share. Thus, creating a lotto for that one guy who did not find the block, but sneakily submitted thousands of small shares, while some workers honestly working, did not even get one share into that shift, because it ended so fast, and thus, do not get that reward, that they earned. (In time, that does not work-out, because bigger machines are forced to submit harder diffs, thus getting less shares, and missing blocks/shifts, on some fast coins. This is not much of an issue with BTC, due to the nature of the long-ass block-times.)

So, yea... just had to mention that.

I assume your ants are graciously reporting "safe" estimates... but actually submitting an average higher. That happens when you use real estimates. Some are higher, some are lower. Luck in coins, comes in waves. It is only pseudo-random, not true random hashing. Though others will argue with me, the history of any pools "luck" and "found blocks" indicates clear patterns of waves, almost predictable enough that I can predict who will find the next block in the pool, but not when they will find it, or on what block they will find it on. As well as tell you how-many they will hit in a row. xD Usually goes... 0, 0, 1, 0, 2, 0, 0, 3, 0, 4, 5, 0, 0, 6, 0, 0, 5, 4, 0, 3, 0, 0, 2, 0, 1, 0, 0... or 0, 1, 0, 0, 2, 3, 0, 4, 0, 0, 5, 6, 0, 6, 5, 0, 0, 4, 0, 3, 2, 0, 0, 1, 0... (For the bigger boys in a pool. For smaller boys, they have that same pattern, but wider, in the 0's.) This changes with each diff-change, but remains a similar pattern, just with more 0's and less "multi-hit" blocks. It is a lot easier to see on lower-diff coins, or coins where the miners are larger, by identity.

They are waves in waves in waves... Like sound, how the output is the accumulation of all frequencies, on one wave. But, it is all waves. That is the predictable part. Once you determine the length of each isolated wave in the accumulation. Helps if you know the hidden prime-number used for the base in the calculation too. There is always a prime number in the formula, not always a blunt number, but the formula itself is a prime result or leads to one. Welcome to my world, the matrix, xD.

Just for a comparison benchmark my best s1 OC'd to 190 ghs is 10 raw HW over the past 4 days, worst at stock 180ghs is 11,236 raw HW over the past 11 days.

These folks are selling the Bitmine reference board:

http://theminingware.com/opencart/upload/index.php?route=product/product&path=25_33&product_id=52

Well sumptin' sure is lying there.

For that Ants the stats are also additive but give just 1 hr or over 11 days the result comes up the same. My pool reported rates generally are pretty close/exceed what the Ants locally report and tbh the pool numbers are what pays. So I have to assume that clean work is being done no?

Yes, a formula like that would be accurate to the "output", not the "workload". (Now, if both those were low, that would be another issue, other than one with a high workload and high errors. Which is what we should be seeing.)

Eg...
On a system that normally runs about 390-375 Ghs...
1: Doing 380 GHs of work and 0% errors, thus Validity is 380 GHs "accepted" = Normal
2: Doing 380 GHs of work and 50% errors, thus Validity is 145 GHs "accepted" = Reboot needed (? Software errors, Initialization errors, possibly ?)
3: Doing 145 GHs of work and 0% errors, thus Validity is 145 Ghs "accepted" = Stop miner (? Hardware critical failure, card dead or unit half dead ?)

Right now, for #2, both the screen and GUI indicate 360 GHs, as if nothing is wrong at all. #2 will eventually lead to #3 in time, or worse... If not rebooted or attended to.

P.S. Seems the hardware errors are not persistent... they are accumulative. Might want to formulate a time-scale for that number, as the total number is irrelevant. It is the hardware-errors per second/avg which is needed for that formula. I am up to over 185 hardware errors, and so I am sure that would translate into 100% death, if that was how many errors there are at the moment, not just over time.

Eg, It has been running for 60 min, or 3600 seconds, so 185 errors in 3600 seconds = HW-Error rate of 0.0514/second Which is not bad. (Started with a lot, right out of the gate, now it is only one every few seconds.)

Well... in theory at least the tweaked cgminer for the A1 is on Github so the code for that can be looked at (not by me - otta my scope of things). Are the calcs from it right and being reinterpreted by the web UI?

Oh, standard rule of thumb Bitmain uses for the Ants error % is
HW error % = HW/(diffA + diffR + HW) * 100

Following that my S1's range from truly infinitesimal to 0.000012% error. Have never ever had my pool report rejects/errors/stales. Always 0/0/0 even from my worst Jala that BFgminer reports as having 6.7% error rate.

And my s2 is in Alaska, UPS says will be here on Tuesday

Ok, one more frustrating issue...

Though this is not an issue with AMT, but with the software being used for mining-control.

The issue:

The number on the screen "Estimated hash-rate", is completely inaccurate, on many levels.
1: Several times the machine is running, it has run with over 50% "device rejections". Screen still indicates hashing-rate as "380 GHs", though the output is obviously only "190 GHs", as seen in the pools. (This is "rejected shares due to invalid, rejected at the RasPi".)
2: Every time, I have "hardware errors". They grow in time... 2 - 7 - 14 - 24 - 36 - 48... Still, the screen shows hashing-rate as "380 GHs", though the output is obviously only about "290 GHs", as seen in the pools. (This is "failed hardware, not responding, not hashing.)

Worst is when I have 50% hardware rejected, and 48 hardware errors, which brings the output to "145 GHs", (290/2=145). Still the screen indicates a healthy "380 GHs". (Not sure if hardware errors are accumulative, or "total", but it seems like a "total", in the final output.)

I am not sure what it is using to get the GHs calculations, but it is not actually calculating them from the output of the machine. Seems it may be estimating based on "single best share", for whatever share is still being hashed. Thus, as long as one fraction of one chip was running, it would indicate "380 GHs", though the output may actually be only "2.3 GHs".

Seems each hardware error is roughly 2.3 GHs, in the state of the cards, which I have. While the device-rejected percent is just a percent of what is being delivered down the chain, from non-failing portions. So, I have to roughly subtract 2.3 GHs for each error, and then subtract the percentage of rejections from the Pi, and then subtract the small percentage of rejections from the pool-server. To determine the "actual estimated hashing rate".

Might be one reason why you guys are having a difficult time "detecting" the failing or failed boards... Prior to shipping. Because the software is essentially fudging the "output" or the "production". (Not sure if this was done on purpose, to thwart the introduction of THs machines into the market, but I suspect it was not done on accident. No-one can be that stupid to have overlooked that, when programming. It had to be purposely reprogrammed, because the program which they made this from, did formulate for all of that. Not AMT, the people who made this web-UI and the RasPi distro. The web-UI has access to that information, obviously, in the logs and output.)

If I had not checked it, I would have run for days, at less than 50%, thinking it was running 100%, as the screen and web-UI indicated.

Sample output from the "LOGS -> CgMiner" page... (Screens indicate "380 GHs". Pool indicates "145 GHs".)

Pool Rejected%=>1.3
Device Rejected%=>54.8
Hardware Errors=>85
Device Hardware%=>11.3485
MHS av=>382077.53 (Not even possible with 50% rejects, which should not be counted.)
MHS 5s=>388568.23
Remote Failures=>0

Suggestion...

In the Web-UI, Indicate the "Workload Output: 380 GHs", then the "Valid Output: 145 GHs". Also taking note of "Device rejected: 53%", and "Hardware Errors: 85"...

The screen on the machine should just read "Speed: 145 GHs", not "Speed: 380 Ghs", since that should indicate our "Valid production". Which, if low, we KNOW there is an issue, and can investigate further with the GUI, or reboot, or alert you of an issue before the issue becomes a major device failure. Since, seeming as if nothing was wrong, we would let it keep keep running, possibly burning up the device and causing more "expensive damage", which the MFG would be responsible for repairing. (Just trying to reduce your future potential losses here.)

At the moment, a simple reboot fixes this issue... for the "device rejected" errors. (That too, you could indicate on the miner screen and the web-UI, since you can detect that "error rate", easily.)

Works best if you shut it down and wait 30 seconds, to allow the unit to completely drain itself of power. Seems the caps hold a lot of power in the Pi, and some on the miner, causing it to linger in a low-power, half-alive, dysfunctional state. One which causes it to not boot correctly, if instantly turned off and back on, in a time-period below 20-seconds.

Unauthorized vendors/brokers selling components of unknown origin (not directly obtained from the maker and no paper trail). Think e-bay. The parts might be good and are cheaper because they are legit factory over runs (rare) or someones surplus inventory. But - they might not be and unless one checks every single piece used against spec there is NO assurance that it will be right.

Counterfeit electronic components is a very serious problem in all industries. If one is lucky they are just out-of-spec factory-rejects that failed testing and were improperly disposed of so someone dumpster dived for them to resell. There have even been cases of chips with no actual die in them! Most common is components which are an older version that have been relabeled to be a new one.

I am unfamiliar with the "grey market", could you elaborate?

You name it, the contract mfgr did it: sourcing (questionable) parts from the grey market, parts in wrong places (caps vs resistors), copper possibly too thin for the current/thermal loads, no solder mask over some vias, other general assembly issues...

I'm sorry, I haven't been following the thread as diligently as I have wanted to in the past few days. What exactly went wrong with the manufacturer? Did they not make their parts correctly? I don't really want to go fishing through this thread and the last to find what everyone has said about them. Also, I don't understand what you mean by saying "its[sic] not that the miners dont[sic] work". When I received my miner, 3 of the 5 boards did not work at all.

Just trying to get caught up on what's been going on lately.

Thanks again,
Termonator61

Was referring to the power the USB hub has to supply. BFL forum is full of stuff on that. I take it that the USB/SPI bridge is powered from the hub and some setups draw more than the 500ma/port is supposed to supply. My 2 lil' 10ghs Jala's pull 750ma per-port (and 60w per Jala off the +12v supply).

Possibly but its better than the alternative being dealt with now. Like I said its a workaround or stopgap, not a full fix. Its something to at least mitigate problems until a more reliable and permanent solution can be found. And the power demands would be fairly minor in comparison IMO. I could be wrong there.

Isn't USB how the original test boards in the dev thread communicated? Near the end of the thread someone mentions having to change  software from USB coms to using the GPOI link. Maybe Bitmine wanted to avoid USB hub issues? Power has been a historical sticking point there.

Great thanks. That will work.