Search content
Sort by
Showing 20 of 89 results by despoiler
Re: DiabloMiner GPU Miner (LP, BFI_INT, async nw, multipool, 79xx GCN)
Weird; I wonder why it never manifested itself until I installed Catalyst 12.6.
And unfortunately, I do want my monitors off when I sleep.
I wonder if I roll back to 12.5
And unfortunately, I do want my monitors off when I sleep.
I wonder if I roll back to 12.5
So shut them off before you goto sleep.
Re: [208 Gh] MtRed (PPS, LP+, API, 0 FEE) Merged Mining Test LIVE
in the main server down? minrs haven't been connectign the last few hours it looks like.
Same here. Wooo down again.
I get 857 and some change mh/s with the 864 firmware.
But not long term, or? The values averaged over the last 5s might fluctuate (I even see higher values than clock rate now and then), but if you let the device run for a day or so, the hash rate should settle to the values I gave - at least that's what I see with my Linux driven BFLS.
That is the average over a day +. The only time the thing comes off of 857 is when the long poll hits from the pool.
Are you really sure you flashed the 864 FW? 857 MH/s would otherwise perfectly match 872 MHz. If you're sure, what OS and miner SW are you using?
Confirmed 864 is loaded. My unit stays pegged at 857.7 and the only time it comes down is when the LP hits. It goes right back to 857.7 and the average starts to climb back up to that also. I'm running Win7 64 with CGIMiner 2.4.1
I get 857 and some change mh/s with the 864 firmware.
But not long term, or? The values averaged over the last 5s might fluctuate (I even see higher values than clock rate now and then), but if you let the device run for a day or so, the hash rate should settle to the values I gave - at least that's what I see with my Linux driven BFLS.
That is the average over a day +. The only time the thing comes off of 857 is when the long poll hits from the pool.
Are you really sure you flashed the 864 FW? 857 MH/s would otherwise perfectly match 872 MHz. If you're sure, what OS and miner SW are you using?
Ill double check when I get home. I tested all of the faster firmwares that were out at the time my single arrived. I see they have added even faster ones since I last checked. I'll post some screen shots if my memory has served me well.
I get 857 and some change mh/s with the 864 firmware.
But not long term, or? The values averaged over the last 5s might fluctuate (I even see higher values than clock rate now and then), but if you let the device run for a day or so, the hash rate should settle to the values I gave - at least that's what I see with my Linux driven BFLS.
That is the average over a day +. The only time the thing comes off of 857 is when the long poll hits from the pool.
I believe BFL addressed this question elsewhere. But basically when going through the full nonce range (2^32, of 4 billion hashes), a Single runs at its full speed of 832Mhps. It is able to do this in 5.16 seconds. After that it stops until the mining software give it another work unit. So the question is, how long does it take for the mining software (e.g. cgminer) to give it more work? Well, the miner needs to POLL the USB port to see when the Single is done, it needs to collect any difficulty-1 solutions found (typically 1), then it needs to send the next work. I believe the polling interval in cgminer is on the order of 100ms. The USB link to the Single seems to be only 9600 baud, which will add many more milliseconds to the sending of commands, collecting results, and feeding more work.
Let's assume the average delay between polls is 50ms (100ms polling interval means an average of 50ms delay); we'll assume the additional delay due to sending/receiving/processing commands is negligible. So the Single is running for 5.16 seconds at a speed of 832, then sitting 'idle' for 0.05 seconds. Another way of looking at this is that it takes (5.16+0.05) seconds to run through the entire nonce range. That would give it an effective speed of only 824Mhps, not 832.
This happens to be what cgminer reports for a full-bore 832-firmware Single (my 832-speed Singles are reported as 825 by cgminer). Perhaps my assumptions are a bit off, perhaps the polling interval is faster than 100ms ... maybe it is only 10ms. But then the overhead in transferring the serial commands becomes more significant and we're basically back to the same situation again.
You asked why EasyMiner reports a higher rate than cgminer. This is why. I think you already suspected as much. EasyMiner reports the raw rate only. That is, the rate at which a full 2^32 hash range is calculated at. It does NOT take into account the overhead of polling and command transfer over a longer period. cgminer does take this into account, which is why its reported rate will be lower.
It may be possible for BFL to tweak the firmware such that the next work could be queued in the device before it has completed its current work; that would essentially eliminate the polling delay and allow the device to operate at 100% efficiency. Currently that is not the case; we lose about 1% due to the polling and USB communication overhead.
Let's assume the average delay between polls is 50ms (100ms polling interval means an average of 50ms delay); we'll assume the additional delay due to sending/receiving/processing commands is negligible. So the Single is running for 5.16 seconds at a speed of 832, then sitting 'idle' for 0.05 seconds. Another way of looking at this is that it takes (5.16+0.05) seconds to run through the entire nonce range. That would give it an effective speed of only 824Mhps, not 832.
This happens to be what cgminer reports for a full-bore 832-firmware Single (my 832-speed Singles are reported as 825 by cgminer). Perhaps my assumptions are a bit off, perhaps the polling interval is faster than 100ms ... maybe it is only 10ms. But then the overhead in transferring the serial commands becomes more significant and we're basically back to the same situation again.
You asked why EasyMiner reports a higher rate than cgminer. This is why. I think you already suspected as much. EasyMiner reports the raw rate only. That is, the rate at which a full 2^32 hash range is calculated at. It does NOT take into account the overhead of polling and command transfer over a longer period. cgminer does take this into account, which is why its reported rate will be lower.
It may be possible for BFL to tweak the firmware such that the next work could be queued in the device before it has completed its current work; that would essentially eliminate the polling delay and allow the device to operate at 100% efficiency. Currently that is not the case; we lose about 1% due to the polling and USB communication overhead.
Hi Epoch,
I had similar estimates in a different thread and did some further digging to get a more solid understanding.
Bottom line is, if the BFLS is not throttling, you will get some long term hash rate of (system clock - 14) MH/s, that is a device with 864MHz firmware will deliver 850MH/s at most. The loss is taken for the communication to/from device. Converting it down based on a nonce time of ~5.2s, the idle time is around 80ms per cycle. That matches the real numbers for cgminer operation, that are:
- baudrate of 9600 => ~1ms (937.5 us exactly) to read/write a single character
- submitting work: write ">>>>>>>>[32 bytes midstate][last 12 bytes of block header]>>>>>>>>" => 56ms
- polling for shares: after work submission, first wait 4.5 seconds, then poll every 10ms by writing "ZFX" => 8ms average delay
- reading shares: read "NONCE-FOUND:1234ABCD,2468EFAB,1111BBBB" => (11 + #nonces * 9) ms => 18.7ms average
One could maybe implement some pre-fetching of work and caching of nonces functionality to add the potential 12MH/s - but at the same time maybe the FPGAs need this small idle time to cool down a little bit.
I get 857 and some change mh/s with the 864 firmware.
I bet someone that has a high capacity CNC machine that releases a water block for these would make bank. I wish I knew how to mill.
I thought BFL was already working on one.
What heatsink compound have you guys been using as a redo on the singles 
Personally, I despise thermal grease. I plan to replace the grease in my mini rigs with phase change material (PCM).
Some info:
http://www.electronics-cooling.com/2002/05/understanding-phase-change-materials
Where I buy it:
http://www.opentip.com/Electronics/Startech-Heatsink-Thermal-Pads-Pack-p-1075383.html
Also on Newegg:
http://www.newegg.com/Product/Product.aspx?Item=N82E16835230030
Experience has led me to love PCM for CPU and GPU cooling. Never tried on an FPGA, but I'm definitely going to.
Thanks,but I have grown VERY fond of Ceramique for CPU's & GPU's,for the last 6-8 years,but for these FPGA's I think it's a little too thick.
I'm mainly curious about what folks have actually used for the FPGA's.
So far MX-4,any others??
Please keep the suggestions coming,Thanks
Most people use MX-2. It's pretty much the price to performance king of thermal pastes. I think it's about $4-5 cheaper than MX-4.
What heatsink compound have you guys been using as a redo on the singles
MX-4
As in Mining.
Gaming is not a concern for me. I was simply wondering if the 7970 and 5850 would mine together without hanging or crashing the system.
Gaming is not a concern for me. I was simply wondering if the 7970 and 5850 would mine together without hanging or crashing the system.
I have the same cards in a Win7 rig. No issues.
Re: DiabloMiner GPU Miner (LP, BFI_INT, async nw, multipool, 79xx GCN)
What's with the double spaced lines of output in this new version? I personally don't like it.
Sounds like your terminal isn't quite wide enough.
The default size? Yah no.
Got my single today. I've been experimenting with firmwares since I got off work. Noticed some odd dips in mh/s with the stock firmware. No flashing throttle light, but happened in a noticeable interval. Flashed the 864 and 872 firmwares. Again noticed some dips in performance, but this time intermittent throttling light. Pulled the cover off. Immediately saw a good amount of white thermal paste on a sliver of one chip that isn't covered by the heatsink base. Took the heatsink assembly off the board (FU push pins). Confirmed my suspicion that the thermal paste used is not good(very runny white paste and applied copiously). Cleaned it off and put some MX-4 on both chips, got a good press seal between the chips and heatsink, then reassembled. My temps are a solid 3-4C lower with the 864 firmware. No more throttling or dips in mh/s. Mh/s stays pegged.. Haven't tried the 872, but suspect I should have good enough thermals to run it. Just an FYI for anyone seeing something similar.