Buying ASIC miners goes against the common good. It give an individual the upper hand for a while until most miners upgrade to ASIC. By that time, a 5Ghps miner will give the same a amount of bitcoins as a 200Mhps GPU miner gave 6 month before.
In the long term, we all loose and the only winners are the ASIC manufacturers.
This is a fine example how group behavior eventually goes against the common good.
But I guess it's too late for that now... the hash rate snow ball is rolling faster and getting bigger by the minute.
Yes that's absolutely correct. The reason people want to get in on the asic act is that if you're the first in with the hardware before the difficulty has plateaued, you stand to make a killing, and that's precisely what's happening at this time with anyone who has one. However it's a gamble whether you can get one early, and if you pay massive amounts to secure one now (like ASICMINER hardware), you are getting ripped off and missing the big picture since it will not be profitable till long after the diff has plateaued, potentially never. |
|
|
|
a quick question, I'm not familar with openwrt: root@OpenWrt:~df -h
Filesystem Size Used Available Use% Mounted on
rootfs 320.0K 228.0K 92.0K 71% /
/dev/root 2.5M 2.5M 0 100% /rom
tmpfs 14.2M 540.0K 13.7M 4% /tmp
tmpfs 512.0K 0 512.0K 0% /dev
/dev/mtdblock3 320.0K 228.0K 92.0K 71% /overlay
overlayfs:/overlay 320.0K 228.0K 92.0K 71% /
it seems only /tmp have enough free space for new cgminer binary. But it is a tmpfs so it will gone when restart , right? This is what I did, wget the file to /tmp (don't forget to chmod 755) and replace the old cgminer with a symbolic link cd /usr/bin mv cgminer cgminer.old ln -s /tmp/cgminer cgminer Be aware this will trash it on startup as you suspected since there will be no binary in /tmp on reboot. |
|
|
|
ok, cgminer -n gets the following:
./cgminer -n
[2013-06-21 15:10:01] CL Platform 0 vendor: Advanced Micro Devices, Inc.
[2013-06-21 15:10:01] CL Platform 0 name: AMD Accelerated Parallel Processing
[2013-06-21 15:10:01] CL Platform 0 version: OpenCL 1.2 AMD-APP (1113.2)
[2013-06-21 15:10:01] Platform 0 devices: 1
[2013-06-21 15:10:01] 0 Tahiti
[2013-06-21 15:10:01] Failed to ADL_Adapter_ID_Get. Error -10
[2013-06-21 15:10:01] This error says the device is not enabled
[2013-06-21 15:10:01] Failed to ADL_Adapter_ID_Get. Error -10
[2013-06-21 15:10:01] This error says the device is not enabled
[2013-06-21 15:10:01] GPU 0 AMD Radeon HD 7900 Series hardware monitoring enabled
[2013-06-21 15:10:01] 1 GPU devices max detected
[2013-06-21 15:10:01] USB all: found 7 devices - listing known devices
[2013-06-21 15:10:01] No known USB devices
aticonfig --lsa
* 0. 01:00.0 AMD Radeon HD 7900 Series
1. 04:00.0 AMD Radeon HD 7900 Series
There is a Sapphire 7970 in the PCIe X16 slot and a GigaByte 7950 on a PCIe X16 PCIe X16 extender which is plugged into a PCIe X16 connector on the MB which is actually X4. any ideas why I'm only seeing one card? this is running on 64 bit ubuntu 12.whatever LTS i didn't see anything specific to this in README or GPU-README
SDK 2.8 |
|
|
|
|
I don't create firmware, I write the software and build binaries which I load directly. However, I have committed the code supporting the higher speeds to the git master tree for cgminer and xiangfu will create new test firmware shortly supporting the new speeds. Mine has been stable at 350 now for a few hours, averaging ~82GH.
|
|
|
|
Okay I experimented with different frequencies around 350, and the hardware error count was about 1.8% by the time it was at 350, but the effective useful hashrate was the highest there, so on my hardware at least, 350 really is a sweet spot. It ran for 45 minutes and averaged about 82.3GH of submitted shares. An extra 11GH for another 10W is ... quite remarkable. I get ~82GH for 605W (at 240V) at the wall now where I used to get ~71GH at 595W at frequency 300. Wow... with all these improvements, Batch3 is going to be great!
Actually this is all software... |
|
|
|
Con,
Just a thought about 39:325. I do not know why 40:300 was increased to 43:300 with latest updates, but i am positive that 3.1 with 40:300 is making 70500-71000 stable. Following that logic will 37:325 be better?
No, the latency number (43) only affects the risk of duplicates and the code has been so drastically changed since the original code that the higher value is actually better since it reloads work less frequently and uses less CPU without any chance of dupes. |
|
|
|
After a few more minutes it's up to (5s):83.39G (avg):82.64Gh/s | A:350 R:0 HW:357 U:21.4/m WU:1173.2/m Power usage only went up by 5W going to 325 and 10W going to 350. 375 was unstable. The code is already in git master along with the values in ASIC README 34:375 36:350 39:325 Since mine is a batch 2, it has a 750W PSU and it does not seem to be a power issue at 350, but HW errors go nuts above this. does the Avalon temp increase? Indeed, but the fans also increase, so it only went up by 2 degrees here max here (it's winter here). |
|
|
|
After a few more minutes it's up to (5s):83.39G (avg):82.64Gh/s | A:350 R:0 HW:357 U:21.4/m WU:1173.2/m Power usage only went up by 5W going to 325 and 10W going to 350. 375 was unstable. The code is already in git master along with the values in ASIC README 34:375 36:350 39:325 Since mine is a batch 2, it has a 750W PSU and it does not seem to be a power issue at 350, but HW errors go nuts above this. |
|
|
|
|
In another thread, I'm running mine stable at 350...
|
|
|
|
|
Even better, I've tried implementing overclocking to higher frequencies and can get my Avalon stable at 350 (without any voltage mods).
It was unstable at 375, but this is at 350 (diff 56) after a few mins:
(5s):81.58G (avg):81.55Gh/s | A:144 R:0 HW:135 U:22.4/m WU:1158.3/m
|
|
|
|
|
For grins, I have tried this and it worked at 325, 350 and 375. The error rate at 375 meant the useful hashrate was lower than at 300, but it worked at 325 and 350 quite well and I got 81GH. The power usage went up by 5W (at the wall) at 325 and 10W at 350.
|
|
|
|
somebody recompilation avalon drivers and run avalon Frequency 332Mh,it's hash ability about 80G.
Question: what should be buf[6] and buf[7] for 325MHz, 350MHz, and 375MHz? if (frequency == 256) { buf[6] = 0x03; buf[7] = 0x08; } else if (frequency == 270) { buf[6] = 0x73; buf[7] = 0x08; } else if (frequency == 282) { buf[6] = 0xd3; buf[7] = 0x08; } else if (frequency == 300) { buf[6] = 0x63; buf[7] = 0x09; } It was explained to me that only certain values are actually accepted by the hardware. However the values are simply little endian values with a fairly precise linear relationship with the corresponding frequency so it seems it's a simple multiplier. 0x0803 = 2051 = 256 * 8 0x0873 = 2163 = 270 * 8 and so on so if you want to try 325 etc it would be 325 * 8 = 0x0A28 so it would be buf[6]=0x28 buf[7]=0x0a 350 buf6=0xf0 buf7=0x0a 375 buf6=0xb8 buf7=0x0b but bear in mind the power supply probably won't take that, and I have no idea what the other components would do, nor if it will actually accept those values. |
|
|
|
|
Are you going to be running a bitcoin pool again in the future or does this not belong in the bitcoin pool section any more?
|
|
|
|
Don't forget "unsuitable hardware"
I think there are not so many BFL owners here... yet  Maybe not, but the biggest hashrate hardware from BFL and Avalon are currently unsuitable so even if it's not a lot of people, it's a lot of hashrate. BFL ASICs are 10 TH at most, Avalon are about 40 now. Not too much. ...compared to p2pool though? I have 80GH of ASICs which is more than 10% of p2pool atm. One minirig (which I don't have) is more than half the size of p2pool. |
|
|
|
Don't forget "unsuitable hardware"
I think there are not so many BFL owners here... yet Maybe not, but the biggest hashrate hardware from BFL and Avalon are currently unsuitable so even if it's not a lot of people, it's a lot of hashrate. |
|
|
|
With my deep respect to Con and Kano i can state following:
I calculate my ACTUAL hash rate as advised by Kano taking in account Diff1 shares accepted from pool(s) and cgminer up-time. This gives me EXACT (Real) hashrate. Knowing the fact my network was fine and i did not have downtime due to Network issues, pool issues or FPGA controller hangs (I am monitoring it every two minutes + automated power off/on no reboots) i am 100% sure that 3.2 is not performing.
PS: just for the reference (do math yourself)
Computer: cgminer 3.1.1
Elapsed: 7h 11m 30s
Difficulty Accepted:431530.00000000
MHS:71587.77
That was not happening with 3.2
Found the regression and I've rewritten the code to avoid this performance loss. It is committed to the master git tree now and will be in the next release. Hopefully xiangfu will be able to make an official testing firmware with it before then too. |
|
|
|
|
Don't forget "unsuitable hardware"
|
|
|
|
Wow $150,000 for something that initially was priced at $30,000 and had originally twice the specified hash speed?
Don't forget that it then got upgraded to thrice that hash speed. |
|
|
|
"--temp-cutoff" doesn't work for me, my GPU keeps on hashing even above the allowed target temperature. cgminer -o pool-de.50btc.com:8332 -u [username] -p [password] -o http://mint.bitminter.com:8332 -u [username] -p [password] -I 9 --temp-cutoff 70 pause http://abload.de/img/tempcutoffgcjnu.pngAnybody got an idea? I don't remember but don't you need --auto-gpu for that? Interesting. But what if I don't want cgminer to mess with my GPU clock speed? I just want it to stop if the temp gets too high. Is there a way to achieve that? Well at least enable auto fan and set your target temp below your cutoff temp. Right now your cutoff temp is 70C and you left the target set to the default of 75C. You may want to set an overheat temp in between somewhere too. But --auto-fan is what enables the fan temp control. Just curious, why do you want to cut off your GPU at such a low temp? Sam --auto-gpu will not mess with your engine clock speed at all unless you give it a range. However --auto-gpu IS needed if you want the auto-cutoff feature to work. |
|
|
|
|
Show Posts
