 Show Posts
|
|
Pages: « 1 2 3 4 [5] 6 »
|
|
To be blunt your "other real option" might be investing in a little more hash power (i.e. assuming you are mining as a hobby or for reasons comparable).
If there was some degree of transparency with this pool I might have stuck around, but sadly there is not and there also is little-to-no communication from the admin. Variance is one thing, but when there's a 7-10 PH/s hike and luck concurrently seems to plummet (and this becomes reoccurring or pattern-like) it's difficult to continue mining and just assume everything's working as normal.
|
|
|
|
We have two types of cables 16AWG and 18AWG, we noticed the Avalons have a higher hashrate while using the 16AWG rather than the 18AWG on the same PSU. Our difference was about 100GH depending on the miner. With some miners it didn't matter they always hashed at a high rate, but most of the low rates were fixed by a cable swap.
Most of our miners use the Dell 750W and this is the PSU that we keep in stock.
That's totally normal, and related to the voltage drop according to the resistance of the wires. On 2 different PCI-E cables, 36" long, one cheap 16 AWG, and one homemade with wires slightly thicker, I noticed 0.4v difference between the cheap cable and the homemade one. Less voltage at the plug of the miner also means more amps for the same wattage, so more stress on the connectors. I'm curious, are you using 16 AWG 600V wire, or 16 AWG 300V wire? I'm looking at specs from NTE wire, for example, their 16 AWG in 600V wire carries a max of 15 Amps, whereas the 300V wire is 6 Amps max. I've never used heavy-load hookup wire (i.e. 600V wire) before so I'm wondering if this is what you're referring to. Thanks |
|
|
|
Well from what I've read plugging in a pcie 6+2 connector into the cpu slot (on the psu) will fry whatever your connecting.
You would have to verify the pinout. If you change the wiring so that +12v go to +12v and ground to ground, there should not be any problem, assuming the cpu socket is on the main rail. Seem risk prone. I think the best way to save a socket would probably use perif to molex, then use a 2x molex to PCI-e adapter to power the controller. I would not do this to power a blade.So the pci connection on top of the S7 is purely for powering the control board? I'm thinking of running each S7 off an EVGA 1600, but I need another port on the PSU for the controller. |
|
|
|
For those of you that have seen the movie Forrest Gump remember the scene were young Jennie yells to young Forrest "RUN FORREST RUN' comes to mind
Nope that doesn't really come to mind, but thanks for the ill-founded analogy. |
|
|
|
|
Sorry to revisit a topic that's been beaten to death already, but can someone help me understand why I'm frequently not moving up in the queue after a block is solved. For example, the last 6 blocks: block #'s "378,967", "379,009", and "379,011" were solved and I've remained 19th in the queue after each of these; prior to this blocks #'s "378,792", "378,776" and "378,775" were solved and I stayed 20th in the queue. Is this because miners with large minimum-payouts were ahead in the queue, and fulfilling their payment bumped me back a spot? (or rather, prevented me from moving up in the queue) I'm just trying to understand why this happens so often. It didn't seem to occur as frequently when I started mining on Eligius, but now it's like clockwork. Thanks
Update: Blocks 379,029 and 379,069 have been solved... still 19 in the queue. Is this normal??
|
|
|
|
|
Well this is a bummer: three blocks away from a payout and I got bumped to the back of the queue with only 80% of my unpaid balance paid. I'm guessing this has to do with a manual payout? The remainder still shows in my unpaid balance, but damn, now I have to wait 20 more blocks to collect it (that is, assuming this doesn't happen again, or there's no fail-safe thingy that extends the queue).
|
|
|
|
|
Is something happening to the payout queue? I was in the queue until yesterday and I moved up to 15 blocks ahead ahead of me; today I'm back in the queue. I've noticed that sometimes the queue goes blank but eventually returns so I'm guessing this had something to do with it? Thanks
|
|
|
|
|
Are these new images compatible with the A2 Mega? Or is everyone overclocking the original 88 MH/s A2's?
|
|
|
|
I first reached out to them a few weeks ago. They responded quickly. Since then, and now that I'm ready to ship out, they aren't responding as fast.  M I'm in the same boat. Communication was going well with Jonathan but I haven't heard back in six days. |
|
|
|
For those of you buying other watercooling supplies. Can you give me a frozenCPU shopping list for what kind of fittings you are going to use along with the diameter of the tubing please.
The tubing you choose will dictate what size fittings you’ll need. Bitmain states the unit has G1/4” connectors. Here is a list I quickly created from parts on fronzecpu: Tygon Silver Antimicrobial Tubing* 1/2" x 3/4" (Part #: ex-tub-638) *preferable to clear tubing since it impedes algae grows Barbs and compression fittings are likely made from copper or brass, which when paired with Bitmain’s aluminum blocks, will be susceptible to galvanic corrosion. Chrome plating or matting can help protect against this, but I don’t know to what degree. Apparently Primochill makes a polycarbonate compression fitting which I put in the list. Barbs are cheaper than compression fittings. This list assumes you're using a tubing size of 1/2" inner diameter x 3/4" outer diameter. BARBS: XSPC G1/4" Thread 1/2" Barb (Part #: ex-tub-1026) CLAMP (FOR BARBS): Koolance Reusable 19mm, 3/4" OD Hose Clamp (Part #: koo-151) COMPRESSION FITTINGS FOR BARBS: Primochill Ghost Compression Polycarbonate Fittings (Part #: ex-tub-492) or Swiftech Lok-Seal Compression Fitting (Part #: ex-tub-1289) |
|
|
|
|
What constitutes "specialist coolant"... anything with corrosion inhibitors? I was under the impression that using automotive fluids (like anti-freeze) in a loop was harmful to plastic parts inside a pump. I’m wondering if something like Feser Base would suffice. I have some copper radiators on-hand that I’d like to use but mixing metals just sounds like it's asking for trouble.
|
|
|
|
|
I'm running a US based p2pool node at:
54.187.28.11:28741
|
|
|
|
I can't get the v2.1-MiniTerminator image working with my new A2 Mini Terminator. Here a debug from run.sh: [2014-10-11 18:33:24] Started cgminer 3.9.0
[2014-10-11 18:33:24] Run Reset=1
[2014-10-11 18:33:24] ST MCU hardware reset start
[2014-10-11 18:33:28] SPI Speed 4000 kHz
[2014-10-11 18:33:28] ST MCU - Enable (Pre-header)
[2014-10-11 18:33:28] A1 = 1200,10
[2014-10-11 18:33:28] A1 PLL Clock = 1200MHz
[2014-10-11 18:33:28] A1 = 1200,10
[2014-10-11 18:33:28] A1 PLL Clock = 1200MHz
[2014-10-11 18:33:28] A1 = 1200,10
[2014-10-11 18:33:28] A1 PLL Clock = 1200MHz
[2014-10-11 18:33:28] A1 = 1200,10
[2014-10-11 18:33:28] A1 PLL Clock = 1200MHz
[2014-10-11 18:33:28] A1 = 1200,10
[2014-10-11 18:33:28] A1 PLL Clock = 1200MHz
[2014-10-11 18:33:28] A1 = 1200,10
[2014-10-11 18:33:28] A1 PLL Clock = 1200MHz
[2014-10-11 18:33:28] AUTO GPIO CS
[2014-10-11 18:33:28] SPI '/dev/spidev0.0': mode=1, bits=8, speed=4000000
[2014-10-11 18:33:29] Failure(cs0)(20): missing ACK for cmd 0x04
[2014-10-11 18:33:29] ACK(cs0) timeout:cmd_RESET_BCAST-1.5556s
[2014-10-11 18:33:29] SPI '/dev/spidev0.0': mode=1, bits=8, speed=4000000
[2014-10-11 18:33:29] SPI(cs1) no device
[2014-10-11 18:33:29] ACK(cs1) timeout:cmd_RESET_BCAST-0.2142s
[2014-10-11 18:33:29] SPI '/dev/spidev0.0': mode=1, bits=8, speed=4000000
[2014-10-11 18:33:29] SPI(cs2) no device
[2014-10-11 18:33:29] ACK(cs2) timeout:cmd_RESET_BCAST-0.2165s
[2014-10-11 18:33:29] SPI '/dev/spidev0.0': mode=1, bits=8, speed=4000000
[2014-10-11 18:33:29] SPI(cs3) no device
[2014-10-11 18:33:29] ACK(cs3) timeout:cmd_RESET_BCAST-0.2161s
[2014-10-11 18:33:29] SPI '/dev/spidev0.0': mode=1, bits=8, speed=4000000
[2014-10-11 18:33:30] Failure(cs4)(20): missing ACK for cmd 0x04
[2014-10-11 18:33:30] ACK(cs4) timeout:cmd_RESET_BCAST-1.3649s
[2014-10-11 18:33:30] SPI '/dev/spidev0.0': mode=1, bits=8, speed=4000000
[2014-10-11 18:33:30] SPI(cs5) no device
[2014-10-11 18:33:30] ACK(cs5) timeout:cmd_RESET_BCAST-0.2177s
[2014-10-11 18:33:30] No any A1 board
No any A1 board
: Inappropriate ioctl for device |
|
|
|
|
I placed an order from Innosilicon a week or so ago and have not received an updates on shipping nor order status. Maybe I'm being paranoid about this, but I'm reading that these pro-democracy protests in Hong Kong are temporarily halting certain businesses, banks, and shipping. I'm not sure where Innosilicon Technologies LTD is located, however I was under the impression that they shipped out of Hong Kong. Does anyone know anything about this, or perhaps, can someone who is in Hong Kong comment on this?
|
|
|
|
|
I've tried numerous ways to set this node up... on my own LAN, a VPS, or even when I solo mine without using P2Pool. My miners always sit at Worker Utility of 0. I have the wallet fully synched and I believe the config file is set correctly. Does anyone know why WU stays at zero? I've seen the question raised before but no clear answers. Thanks.
|
|
|
|
|
Please correct me if I'm wrong, but aren't Hashra's units just Zeus chips in a modified case? Who is manufacturing 100+ MH/s asic chips apart from KNC and Innosilicon at the moment? Zeus's next gen miners aren't due until the end of this year, so am I missing something? I'd be happy to purchase one of these if I knew how the units are being made available (in less than 10 days from today).
|
|
|
|
Wipe the SD card and install a fresh Raspbian. SSH into it and install the essentials (e.g. git, libtool, byobu, build-essentials, etc.) Git clone dmaxl's fork of cgminer from https://github.com/dmaxl/cgminer.gitConfigure it with --enable-scrypt --enable-gridseed and then make I run it with a shell script that looks something like: ./cgminer -o X -u X.x -p X --scrypt --gridseed-options freq=838,chips=40 --lowmem |
|
|
|
|
