Topic: [CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers - page 83. (Read 903163 times)

If it was a custom proxy, yes.  As I posted, my personal believe is this problem would be in software or firmware.  Hardware is possible, but doesn't quite make sense given how barebones a mining ASIC *should* be.  My bias points me towards firmware/controller software rather than mining software since that is where it makes the most sense.  However, if somebody is running *custom* software or a custom proxy, that would be another possibility for where the flaw lies, assuming there is one somewhere.

Could it be a somebody's botched implementation of a custom stratum proxy?

There have been many issues with chips though the years. Both ASICs and regular processors.
The Intel FDIV bug to the huge errata lists on some RISC processors tend to be more impressive then ASICs, but that is because they are more in the public eye. Do you think that the get it out as fast as you can hardware that we are using is *really* that well tested....

-Dave

Still love this error list from the old days (the 5th one down is my favorite) you could blow your hardware with bad code:

The Amstrad Plus ASIC improved a lot of the old CPC's capability. Yet this was a bit flawed.

    Despite removing some tasks from the CPU (Z80), ASIC registers are mapped onto memory from #4000 to #7FFF range prior to other type of memory (RAM or ROM).That means this memory range is not accessible when ASIC registers are paged.

    PPI emulation is not correct as the original 8255 does not need validation.On ASIC emulation , this validation is needed so some programs written for "old CPCs" will not be able to get keyboard state.

    Z80 IM2 mode is bugged.In this mode , the Z80 I register gives the high word for vector table.ASIC gives the low word from IVR and the devices that generate interrupt (raster and DMAs channels).ASIC generates sometimes a bad values and the raster interrupt routine is called instead of DMA0 routine.The reasons of this bug are not known.

    There is a conflict between programmable interrupts and some CRTC settings (line screen split).That will cause the RAM refresh to stop and the memory content will be quickly corrupted causing machine crash.

    Reducing Horizontal BLanking could cause another internal conflict when using DMA lists.In the worst case , this conflict can cause irreversible damage to the ASIC.

    Original CPC colors emulation is not correct.

Holy shit dude... 6.82 Ph

And luck is improving.  Not to say that there's any correlation between the two.  I just look at each number on a daily basis to see what it looks like out in my little bitcoin mining world.

My electricity costs are about to drive me to quit this game though.  And that certainly isn't something anyone can change.

Wow ... the pool speed has dipped hugely from a couple of days ago.

The Antminer U1 and the S2 have the exact same chip, the S2 just has more of them, pretty much the same idea.

Didn't say they were as efficient

I would hate that 1,000,000 1mh/s electricity bill...

1 million 1 MH/s miners are just as likely to solve a block as 1000 1 GH/s miners or a single 1 TH/s miner.

I respect this position, but no one is throwing red flags for luck going down from 105% to 95%..the three month is already at 90% and it has been a completely different rhythm.  (longer lows and clipped highs)   Sorry that isn't scientific but many things can only be sensed with your gut to tell your brain that it doesn't have enough information to make a conclusion yet and needs to keep digging.

the discussion is healthy.. because if 80% is the new normal, there should at least be a reason for it.

Are you referencing total shares submitted above a particular difficulty? Just total shares against block size? Sorry I just have a lot yet to learn and am not sure what/how your 150% is compared too.

Will a 1PH pool of S2's find more blocks than a 1PH pool of S1's?

Difficulty has become so high that older slower miners may never ever find a block to help balance out luck. They are slowly becoming leechers instead of seeders for the pool.

Let's compare 5 S1's vs 1 S2. We are given 10 minutes to work on a block. Each S1 starts counting from 1 and makes it to 1000, The S2 makes it to 5000 in the same time frame. Are those 5 S1's counting a total of 5000 really equal to the single S2 that counted to 5000 on its own? To me, comparing the 5000 vs 1000 of each S1, says that the S2 will produce a higher share height in a given time frame compared to the 5 S1's.

Yes.  Before we pulled everything off BTCguild about a month ago, we had solved blocks worth around 150% of the payments collected.

Can you elaborate on the test in bold?  Are you speaking of your own farm? 

It could also be in the silicon.  You could have a fully unrolled hasher with a perverse error that corrupts the last 32 bits of the hash value under circumstances that includes the second 32 bits hashing to 0 (diff >4.2B).  The silicon could then find plenty of golden nonces but none (or a significant % lost) over 4.2B.

I was quite unhappy about the closed nature of many of the recently released products specifically because I wanted to run a test suite of known solutions against the hardware and was unable to do so.  The hardware we have online have solved ~150% more blocks than we have collected reward on, so I do have indirect confidence about the systems we own.

If the problem is related to the difficulty going above the limits of a 32-bit variable, it may not have anything to do with *recent* hardware releases.  It could be OLD hardware.  It would likely be firmware or software in the controller for the hardware.  (See edit for more info).

This would explain why these accounts were not noted the last time I did a pass.  I was looking for active withholding previously.  Accounts with significantly low block submissions vs shares submitted.  Last night's pass was specifically targetting shares vs blocks over the last 6 weeks, eliminating the chance of past luck making up for recent shortfalls.


EDIT/CLARIFICATION: The hardware itself has no reason to actually know the result of its hashing outside of diff>=1 (or >=1024 in some newer hardware I believe).  It's probably not in the software since *most* ASICs do not use custom software, they use cgminer or bfgminer.  So the point in the middle that handles communication between the hardware and the software is the most likely culprit.

Well, if we want to entertain the idea of faulty hardware having some bearing on the overall results, we need to identify recent release's. I follow a number of the Antminer threads and see a significant number of miners struggling to keep the S2's up and running. Also see a significant number of S2 miners posting screen shots with concerns over large numbers of Hardware Errors and Rejects. Some one will do a little math and say...Mheee...that's not too bad. My point though is that is 1TH/s equipment and those rejects and errors accumulated in 2-3hrs exceed my accepts for a given time period. AND knock-off miners with slightly less advertised total hash speed from Bit-Mine seem to have a slightly higher error rate/hour as well. Just seems too me like these units are a bit off, maybe they are putting out some bad vibe static.......

I froze a few accounts last night that had started showing unusually bad block solving rates over the last 6 weeks, even if they had previously not had bad luck, or did not have abnormally bad luck over the lifetime of their account.  One of those users has contacted me and we're now going to go over their HW/SW configuration to find out if something is busted.

The pool luck only took a drastic turn ~6 weeks ago.  And unfortunately, you can't tell how abnormally bad luck is until you have enough time to identify a clear pattern.  2-3 weeks at 15% of the network is not enough to call 90% luck bad enough to be suspicious, so it was not clear if it was abnormally bad or just bad until ~2 weeks ago, when we had a solid month at ~90%.  Even that is not enough to rule out variance for certain.  Since then, the 1 month time frame is in the 80s, which is even worse worse.

6 weeks ago is (roughly) when difficulty surpassed the limit of an unsigned 32-bit integer (4.2b).  It is very possible that this is the cause of it, but until I know hardware/software specifications of these users, it's uncertain.

Looks like miners are getting skittish and bailing fast.  Not sure I have ever seen such a drastic fall in hash-rate on the guild before.  Down by a couple thousand TH overnight.