I'm curious if this custom solution will work with 8GB cards, or only with 4GB cards?
Its a custom solution that would work with ANY card, could be future Vega 12GB cards as well. Yes there is no theoretical limit to what my solution will work with, should be fine with Nvidia cards as well. I am specifically testing with a mix of 470s/480s with 4/8GB
|
|
|
geeze what motherboard can do 16 gpus?
With any standard motherboard and some pcie multiplier you can do same thing ! Its been asked many times and he is not giving up the gold. The motherboard is a MSI Z97 gaming 5 but he did his own bios and very low level linux kernel changes. Not quiet, but the prototype systems I have run a Z97 variant. The host boards for the production systems will most likely be a Z170 or C236 board.
|
|
|
I P.M asking him for 1. Hahah. I want 1 of these bad boy!!! Although..............that would increase my odds of 1 of them crashing rig much higher but seems like Linux handle it better than windows. It would probably best on very stable unmod cards. Although I wouldnt mind running 16 x Furies for bragging rights. The Sexy designs I can do with it..................... =)
It will actually decrease your crash rate even compared to a 4-7 GPU rig setup. I engineered these boards to be built for GPU hashing from the ground up...the cheap Chinese risers were never designed for that purpose( or at least USB 3 cables used to carry the sensitive differential pairs in PCIe lanes is a horrible way to do it). Unfortunanlty I have to reboot these mutiple times for testing otherwise id post a screeny of them running for a week straight (oh and all GPUs have modded bioses on them).
|
|
|
geeze what motherboard can do 16 gpus?
With any standard motherboard and some pcie multiplier you can do same thing ! unless its something like http://amfeltec.com/products/gpu-oriented-cluster/which I have to say is pretty neat, but im sure its not cheap Nope...this is a complete custom board engineered by me.
|
|
|
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.
|
|
|
Optiminer v1.7.0 released![1.7.0] New --pci-modes (0-3). Try if you see GPU freezes. [1.7.0] Reduced CPU utilization. [1.7.0] Small performance improvement ~1%. Enjoy! Can you explain in detail what the differences are between the pci-modes?
|
|
|
Any updates Jstenfanop?
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.
|
|
|
Miner does not use 1.88 factor in calculations, using it is a bad idea because it is theoretical factor and real implementation may be not so good. Therefore miner just counts all solutions found, and time that was spent. If algorithm implementation has a bug that causes 1.8 factor, it will cause less number of solutions and less calculated hashrate. So this idea is wrong. I still think it's related to pool. What pool do you use? I will put all my polaris cards to it and check 2-3 daily hashrates to see hashrate deviations.
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?
|
|
|
Miner does not use 1.88 factor in calculations, using it is a bad idea because it is theoretical factor and real implementation may be not so good. Therefore miner just counts all solutions found, and time that was spent. If algorithm implementation has a bug that causes 1.8 factor, it will cause less number of solutions and less calculated hashrate. So this idea is wrong. I still think it's related to pool. What pool do you use? I will put all my polaris cards to it and check 2-3 daily hashrates to see hashrate deviations.
flypool
|
|
|
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 1. Hashrate is calculated in the same way for all cards, so Polaris cards cannot get different numbers related to 280X calculations. Your idea about adding 5% on polaris is wrong too. 2. You know I don't care about Linux much. In Windows you can easily see that my miner is the fastest for Polaris because the difference is significant; in Linux speeds must be similar. If you get bad numbers on pool and think that it's because of the miner, don't use it, you have a choice. My opinion: it's something related to pool calculation, for ZEC I always get more hashrate variations on pools side than for ETH mining. 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
|
|
|
I am almost done. 11 out of 12 Equihash kernels work flawlessly. GCN support of LLVM is incredibly buggy, but I can at least fix them now!
Are you seeing any speeds ups from using LLVM vs stock compiler?
|
|
|
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 spill the beans 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 https://i.imgur.com/OQKf9QN.pnghttps://i.imgur.com/lkLSbNr.pngwill the software part of the solution (if not oob) be paid as well or OSS? i suppose running this on linux is by far easier as on windows another interesting concept i have thought of would be running linux as a base and passing through 4-6 gpus into a vm, one just needs to create multiple vms for windows and a single one for linux (or run it barebone) 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.
|
|
|
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 spill the beans 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
|
|
|
Can you recommend an ATX PSU for these miners? 5PCIe Connectors / min. 400W? Since the Miner is quite silent I am not willing to put a noisy server psu next to it.... Thank you
Well you need a PSU with at least 5 pcie ports so that tends to push you up into a larger PSU than is really needed to run the L3. The EVGA 1000w P2 is a good PSU that can be used for GPU rigs and work well for the L3. Also the AX1200i also a good PSU, but both are oversized for this particular miner. Maybe some other users can chime in with their experiences with some smaller PSU's, but these are my go to PSU's around here for most things. 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
|
|
|
|