Nope personally designed custom solution. Everything else out there was either cheap Chinese crap, or overpriced crap.

Here another little teaser for you guys 

Finished the second dev board and have 4 more GPUs coming in so should be able to test the full 16 GPU setup. I was knocked out with strep all last week so didn't have time to work on the project

just realized I never sold this....still available.

Can you explain in detail what the differences are between the pci-modes?

I should be able to make a formal announcement at the end of this week...Im still in the final stages of designing the production board, and want to be within a month of announcement to ordering/shipping.

Take a pic of where USB plugs into board (there might be a separate little board for that), and I'll id it/ get you the right drivers for it.

Claymore I found your bug...seems like shares are dropped when there is high network latency in your share queue (time after block is found on network, network disconnects, pool disconnects etc). Either there is a bug in your share queue that not properly submitting queued shares, or when you do regain connection to pool, you dump all the shares at once to pool and pool software might be blocking/loosing those submits.

Below you can see a test of my theory, network is manually dropped at 12:58:22 and reconnected at 12:58.36 and in that time system finds 18 shares, but only 15 reach the pool.

This issue is obviously magnified by larger rigs since the faster the system finds shares the more shares will eventually be dropped if there is a network latency, so it explains why you or others might not see the same behavior. Maybe put in a slight delay(10-20ms) between queued shares so they are not all dumped at the pool at same time?

flypool

Yes he hasn't optimized his polaris kernel under windows, so that makes sense. What does not make sense is that your miner reports a certain hashrate that is not matched on the pool. Your miner does not produce any invalid shares or errors so its not that, and the pool calculates shares the same way for both miners, so if it was calculating wrong for your shares it would be wrong for optimizer's shares as well (pool does not care where valid shares come from, calculation is simply #shares/time). Hash rate variation also is not it since this is a 24 hour average.

The miner is simply submitting less shares to the pool than it *should* based on the hashrate calculated by your miner. So again either your hashrate calculation is wrong, or shares are "disappearing." The only explanation that would explain a correct hashrate calculation, but less "valid" shares being retuned by your kernel is that for your Polaris ASM implementation you have optimized it to the point that the theoretical solutions per iteration (which is what I'm assuming your hashrate calculation is based on), is slightly less than its supposed to be (i.e. 1.8 instead of 1.88).

Hmm so I can confirm there is some weird stuff going on with claymore v12 and polaris hash reporting. First shot is claymore 24h average v12.1 right before I switched to optiminer 1.6.2. Second is optiminer after 24 hours. 

Claymore reports exactly 2804 average hashrate miner side which should equal ~2750 poolside after dev fee is taken out. Poolside reports over 100mh less than that though.
Optiminer reports 2734, which is exactly what pool is reporting at 2731

Whats more interesting is that Claymore on a 280x rig reports the exact hashrate minus fee that the pool reports. At first I thought this was either a pool/hashrate bug issue, but the fact that optiminer reports the correct hashrate, and the 280x rigs report correct with claymore.

My guess is that either there is a bug with polaris hash reporting (i hope) or he couldn't reach optiminer performance on polaris, so he bumped his numbers by 5% to make it look like his miner is faster 

Are you seeing any speeds ups from using LLVM vs stock compiler?

Yea linux image will be part of the solution and provided with the hardware (as well as BIOSes and anything non hardware needed to run it). Definitely wont run on windows.

Cant spill everything yet, as im still finalizing design...but here are some teasers from my prototype system  All the GPUs are 470s 4GB, would have more connected but only have one dev board built and ran out of 470s lol

5 PCIE power ports for this miner is way over kill. Each board is about 100 watts, so you can easily power 2 with 1 line, so 3 total (2 for boards split, and one for controller). Just use splitters (make sure they are at least 18AWG) and youll be fine...you could also double split one line to power the controller (which uses basically no current), and get away with a total of 2 pcie lines per miner.

Anyone else notice that v12/12.1 is reporting about a 5% higher hashrate than pool(flypool) for polaris based cards?

For example a 470 is reporting 280H/s miner side, and 260H/s poolside average. With 2% fee should be reporting ~275H/s.

Can anyone else on flypool with polaris cards confirm...want to see if its just me or a pool related issue.

I should have a pretty interesting announcement on this front in the next few weeks ...if I were you guys don't buy anymore of these cheap switches (they suck and are not even designed properly), or even GPU risers. I will have something that will change the way we GPU mine

pmed

Have 6 R9 280x Sapphires Dual X cardsand two Sapphire 7970s (those two are brand new from warrenty replacement few months ago). All cards run great, few off the dual X have fan issues (wobbly, but I keep them oiled and they still spin). SOLD

All cards also have custom BIOSes and can keep them on there...currently hash at 320 S/s on zcash on stock clocks.

Yea there is so much insider crap going on with bitcoin/litecoin these days its pretty sad.

Pascal + Eth would be interesting, since its pure SHA so might be able to get some nice numbers.