Are these facts, or is it what you assume? They are facts I just am not sure on the algorithm. Intensity x = # of hashes y. I knew the alogrithm for pheonix at one time. What I find contradictory is that the higher the intensity, the less responsive the PC becomes. With your explanation it should be the other way around, or am I missing something? After CPU asks for one billion hashes from the GPU, it can sleep for 2 seconds and collect the result, while with asking for only 100 millions it needs to get active after 200ms, right? It has to do with the way AMD writes the drives. The CPU has no idea when the GPU will finish so it spends clock cycles "checking". The way it checked w/ older drivers is what caused the 100% CPU bug. This has improved but the GPU doesn't go "idle" and then get the results at the end of the batch it continually checks to see if the batch has completed. The OS GUI also can't dedraw the screen while the GPU is working so the longer the batches the more "laggy" the desktop will seem. If intensity is too high it can crash windows (especially OS running Aero) because Windows isn't exactly OpenCL aware. It doesn't understand that the GPU may be unavailable for a long time. Prior to OpenCL there never was a time when GPU would be unavailable for graphical work. If it can't reach the GPU in a reasonable amount of time it causes unpredictable results. Remember when a batch is running the GPU is completely unresponsive. It totally ignores (without even a "sorry busy" notification) any communication from any other component (even the process running the miner code) until it completes. I'm not sure what causes the decayed responsivity with higher intensity. For sure it is not a matter of whether a multi GHz CPU is being woken up every 2 seconds or 2 msecs. Nor it should be caused by GPU being dumped with a big chunk of work - 2D and 3D units are independent, loading SPs should generally not impact desktop performance. The CPU is being woken up when done. The GPU is checking to see if the batch has completed. 2D units aren't independent on modern graphics cards and for OS using Aero the desktop is no longer 2D anyways. Sound's plausible. Well almost... Can't really believe that the AMD folks are not capable to design their driver in a way that does not require busy waiting/polling. Anyhow, I forgot to mention that I am meanwhile using a headless Linux system for mining. The lags caused by 2D engine should therefore not apply. Now I need to check whether intensity has an impact on the system like I noticed with GUIminer before. If so, I'd wonder why busy-waiting 2 seconds is worse than busy waiting 10*0.2 seconds... |
|
|
|
[...]
1 nonce range = 2^32 = 4 billion hashes. An 300 MH/s card would take 11 seconds to complete.
An intensity of 8 might say do 300 million hashes and return results.
And inensity of 9 might say do 600 million hashes and return results.
An intensity of 10 might say do 1 billion hashes and return results.
All you are doing is increasing the "batch size" which takes longer to run. You gain a small boost by eliminating the number of batches and thus overhead to complete a nonce but you also make the card unresponsive for longer and longer periods of time.
However a hypothetical 1 GH/s card could do intensity 10 in 1 second. So thus intensity 10 on this card is no different than intensity 8 on your card.
Make sense?
[...]
Are these facts, or is it what you assume? What I find contradictory is that the higher the intensity, the less responsive the PC becomes. With your explanation it should be the other way around, or am I missing something? After CPU asks for one billion hashes from the GPU, it can sleep for 2 seconds and collect the result, while with asking for only 100 millions it needs to get active after 200ms, right? I'm not sure what causes the decayed responsivity with higher intensity. For sure it is not a matter of whether a multi GHz CPU is being woken up every 2 seconds or 2 msecs. Nor it should be caused by GPU being dumped with a big chunk of work - 2D and 3D units are independent, loading SPs should generally not impact desktop performance. What am I missing? |
|
|
|
|
Whoa! Folks, what is happening here?
I'm following the Bitcoin saga now for quite some time and with the personal wars that broke out recently it makes me sad to have wasted most of my limited spare-time seeing this ingenious idea going to fail due to common human nature.
Within only half a year there were enough occasions to get distracted from the Bitcoin movement (lost considerable stakes when BTC tanked from 25 to 1US$, seen allinvain loosing >0.5M US$, seen my credentials openly circulating after MtGox hack, followed mybitcoin, Bruce, and much more), but believing in the potential of Bitcoin to positively change the world with an immanent leverage more than Linux did, made me (and majority of us) keep hanging on.
Sadly, with what is currently going on hits the rock bottom. What some of you are committing here is a direct and aggressive form of public which-hunt against Luke-Jr. I don't know (and it does not matter) if Luke is some 'poisonous' guy or not, but all of us should keep at least some remaining portion of decency.
I am contributing to different open source projects, but so far I've never seen any community slashing down on active members like it is done here. Posting captures of presumably private IRC sessions? Mixing personal with professional issues? Posting private photos of members to ridicule them? Come on, that's not the representation Bitcoin deserves. How do you expect this exposed on the official forum will attract potentially new members?
I am not advocating for Luke in any manner, I just don't know him other that being a core developer. What I for sure know is that personal fight should be carried out personally.
2 cents from a nobody. I'm also 99%, btw.
|
|
|
|
New version: 2.2.1
So I'm really loathe to leaving a version out there that makes people adopt to massive change that may not have been a good idea, only to have to pull it again in the future. Today I had the luxury of my long-lost mining rig returning so I was finally able to actually do some meaningful debugging and testing of the code I was putting into cgminer and came up with the conclusion: 2.2.0 was a stinker. I spent most of today putting out all the spot fires under my feet and to release something a little more respectable as quickly as possible.
[...]
FYI, the crash I reported is gone with the latest updates. Thanks! |
|
|
|
yap, I remember that one, he mainly criticizes Scalability. He reuses slides from Dan Kaminsky, this thread has some answers and reactions: https://bitcointalk.org/index.php?topic=34597.0Still I believe there is some truth that Bitcoin is not as scalable and decentralizable as it could/should be. You're sure the guy talking was reusing Dan Kaminsky's slides, or he was Dan itself?  |
|
|
|
Try cleaning out your tree with a fresh ./autogen.sh && ./configure && make clean first perhaps.
Did everything, also freshly installed APP-2.5. Problem is reliably reproducible with my setup (3*6950). I bisected and found that the problematic commit is 371e5f68, while all builds with up to 5a0b4f62 work. Need to go now. If you have some ideas on how I can help identifying the problem, let me know. Good night. |
|
|
|
[...]
Most unusual No system changes should be needed. ADL failing to initialise could be anything, but seems more common with multiple instances of cgminer running. Can you do a git pull and start with --verbose -D and see what it says with the extra debugging I just committed? What does the startup debugging give on the first device if you delete the binaries? 30% sounds like something horribly wrong. In fact it looks like all 3 "GPUs" may just be one device. EDIT: You did do "export DISPLAY=:0" didn't you? Something's really fishy. Rebuilt HEAD (f0746f0b4c), now it's crashing: [Thread debugging using libthread_db enabled]
[2012-01-29 23:06:22] Started cgminer 2.2.0
Program received signal SIGSEGV, Segmentation fault.
0x0026dc0e in ?? () from /lib/i386-linux-gnu/libc.so.6
(gdb) bt
#0 0x0026dc0e in ?? () from /lib/i386-linux-gnu/libc.so.6
#1 0x0026f925 in ?? () from /lib/i386-linux-gnu/libc.so.6
#2 0x00272f22 in calloc () from /lib/i386-linux-gnu/libc.so.6
#3 0x01b2f8b2 in XOpenDisplay () from /usr/lib/i386-linux-gnu/libX11.so.6
#4 0x02653003 in ?? () from /usr/lib/fglrx/libatiadlxx.so
#5 0x02652dc8 in ADL_Main_Control_Create () from /usr/lib/fglrx/libatiadlxx.so
#6 0x08062403 in init_adl (nDevs=3) at adl.c:172
#7 0x0804e731 in opencl_detect () at main.c:5563
#8 0x08058820 in main (argc=1, argv=0xbffff6d4) at main.c:5982
2.1.1 binary still working :-/ WTF? Sorry if it as known issue, though. Was not able to read the whole thread to find some indication. |
|
|
|
Any system changes needed with Linux to move from 2.1.1 to 2.2.0? I'm observing massive problems with the latest updates. I kept the previous working binary as reference, but was not able to isolate the problem. First obvious thing is ADL fails to initialize: [2012-01-29 19:30:32] Started cgminer 2.2.0
[2012-01-29 19:30:32] CL Platform vendor: Advanced Micro Devices, Inc.
[2012-01-29 19:30:32] CL Platform name: AMD Accelerated Parallel Processing
[2012-01-29 19:30:32] CL Platform version: OpenCL 1.1 AMD-APP-SDK-v2.4 (595.10)
[2012-01-29 19:30:32] ADL Initialisation Error!
The remaining initialization sequence looks ok, at least no obvious differences to what 2.1.1 was reporting: [2012-01-29 19:30:35] Init GPU thread 0 GPU 0 virtual GPU 0
[2012-01-29 19:30:35] CL Platform vendor: Advanced Micro Devices, Inc.
[2012-01-29 19:30:35] CL Platform name: AMD Accelerated Parallel Processing
[2012-01-29 19:30:35] CL Platform version: OpenCL 1.1 AMD-APP-SDK-v2.4 (595.10)
[2012-01-29 19:30:35] List of devices:
[2012-01-29 19:30:35] 0 Cayman
[2012-01-29 19:30:35] 1 Cayman
[2012-01-29 19:30:35] 2 Cayman
[2012-01-29 19:30:35] Selected 0: Cayman
[2012-01-29 19:30:35] Preferred vector width reported 4
[2012-01-29 19:30:35] Max work group size reported 256
[2012-01-29 19:30:35] Long-polling activated for http://pit.deepbit.net:8332/listenChannel
[2012-01-29 19:30:35] Loaded binary image phatk110817Caymanbitalignv2w128long4.bin
[2012-01-29 19:30:35] Initialising kernel phatk110817.cl with BFI_INT, 2 vectors and worksize 128
[2012-01-29 19:30:35] initCl() finished. Found Cayman
[2012-01-29 19:30:35] Pushing ping to thread 1
...but the hash rates achieved are at about 30% [2012-01-29 20:18:56] GPU0 (5s):131.0 (avg):123.5 Mh/s | A:53 R:0 HW:0 U:1.77/m I: 9
[2012-01-29 20:18:56] GPU1 (5s):103.2 (avg):121.8 Mh/s | A:55 R:0 HW:0 U:1.84/m I: 9
[2012-01-29 20:18:56] GPU2 (5s):95.6 (avg):121.2 Mh/s | A:43 R:0 HW:0 U:1.44/m I: 9
of what 2.1.1 does: [2012-01-29 20:22:51] GPU0 (5s):363.3 (avg):370.0 Mh/s | A:5 R:0 HW:0 U:4.58/m | I: 9
[2012-01-29 20:22:51] GPU1 (5s):360.9 (avg):365.9 Mh/s | A:2 R:0 HW:0 U:3.61/m | I: 9
[2012-01-29 20:22:51] GPU2 (5s):372.4 (avg):350.6 Mh/s | A:4 R:0 HW:0 U:4.35/m | I: 9
As said, using the same APP and ADL version, same kernel. I also tried with deleting previous kernel binaries with the same result. I am using the current git HEAD for 2.2.0 (82af288e69). Any ideas? |
|
|
|
[...]
our rate of 0.99% is for merchants who use our automated order processing, and take the bitcoins directly. If we assume all currency risk, exchange, and fiat transfer, we do all that for 2.99%. so there is more padding for us in there, but added costs and risks for us to absorb as well. And we would notice anyone trying to game the system with using our system to buy a 15-minute put option.  Ah, thanks for the clarification. Less than 3% in total fees for sure is still cheap. Plus still risky for you in times of high volatility (like we currently have). Detecting someone is attempting to get a free 15-minute put option is not preventing it, or? At least I did not read anything about being not allowed to cease and repeat the payment process when I paid the subscription to the Bitcoin Mag (to get back on-topic). Anyhow, waiting BTC/USD to tank for 4% within 15 minutes is not promising enough to try getting rich  . As a final note: as a buyer, I think the 15-minute acceptance period is way to long. Even if I had to first power on my wallet keeping computer to make the transaction, I feel like 5 minutes should be enough. In rare cases where it might not be, I as a buyer had to accept a re-calculation of the BTC amount. Cheers As a buyer using bit-pay, your payment is confirmed in seconds. No, I meant: as a buyer I had 15 minutes time to sent my BTCs at a pre-calculated exchange rate to complete the payment. The same time Bit-Pay takes the risk for fluctuating BTC/USD rates. I as a buyer would be fine with this rate being guaranteed for 5 minutes, if I'm really that slow it's ok to get an updated BTC amount every 5 mins. I'd personally feel this quite acceptable, while it reduces Bit-Pay's currency risk significantly. |
|
|
|
[...]
our rate of 0.99% is for merchants who use our automated order processing, and take the bitcoins directly. If we assume all currency risk, exchange, and fiat transfer, we do all that for 2.99%. so there is more padding for us in there, but added costs and risks for us to absorb as well. And we would notice anyone trying to game the system with using our system to buy a 15-minute put option. Ah, thanks for the clarification. Less than 3% in total fees for sure is still cheap. Plus still risky for you in times of high volatility (like we currently have). Detecting someone is attempting to get a free 15-minute put option is not preventing it, or? At least I did not read anything about being not allowed to cease and repeat the payment process when I paid the subscription to the Bitcoin Mag (to get back on-topic). Anyhow, waiting BTC/USD to tank for 4% within 15 minutes is not promising enough to try getting rich . As a final note: as a buyer, I think the 15-minute acceptance period is way to long. Even if I had to first power on my wallet keeping computer to make the transaction, I feel like 5 minutes should be enough. In rare cases where it might not be, I as a buyer had to accept a re-calculation of the BTC amount. Cheers |
|
|
|
PS.: Frankly spoken, after lots of mining and reading about Bitcoin, this was my first purchase with BTC. And it went like a charm. No problems ordering to Switzerland, withdrew payment from MtGox, got it accepted two seconds later. Great service, Bit-Pay! Makes me think: why is it not yet used everywhere?
Thanks zefir! We are working on getting as many businesses signed up as we can. The challenge is getting it integrated with whatever e-commerce solution they are already using. We have plugins for some of the major shopping carts, but not all of them. And the volatility still has some merchants scared off. I would say that whenever you shop somewhere online, you should suggest to them that they accept bitcoins! it is more convenient for you and cheaper for them. I would be happy to talk with them if they have any questions. We can payout the merchants in dollars, euros, or bitcoins. Didn't want to hijack this important thread, but just out of interest let me ask you to clarify the currency risk issue. From what you wrote further down, Bit-Pay is taking the currency risk fully, since the merchant is guaranteed to get his gross payout (minus the tiny fee of 0.99% as written at your homepage). I assume you are limiting your risk to the 15 minutes acceptance period, or even to the considerable smaller one from starting the period until you notice the transaction (i.e. after maybe 3 minutes you sell the amount being transmitted from your operational deposit at MtGox and redeem them when the transaction is approved). Even with some great trading discount at the exchanges I hardly can see how your business model is profitable. But for sure it is What is bothering me more with the currency risk is, how do you handle the following obvious attack scheme: assume me (or some automated bot) being the evil guy acting as merchant (using Bit-Pay) and buyer at the same time. Now I order some imaginary expensive stuff and let you calculate the amount in BTC. I let the acceptance period nearly pass and check BTC/USD rate change. If it went up, I won't pay ('sorry, serious technical problems etc.'). I'll repeat this until rate drops by more than 2% within an acceptance period. This time I accept, send the coins and by them immediately back at some exchange. Bottom line: you lost 1%, me and exchange won 0.5% each. Repeat. Profit. I'm not really evil and eager enough to try this out, but am pretty sure you implemented means to prevent this. Good Luck! Zefir |
|
|
|
Well done! I'm in for 12+1 printed issues + gift. This is a win-win for every bitcoiner: if BTC/USD tanks next week, this was a cheap subscription; if it skyrockets to 1000$ this year, the 18.5BTC will make it the most expensive ever - but with some more coins in the wallet it won't hurt too much Good Luck! PS.: Frankly spoken, after lots of mining and reading about Bitcoin, this was my first purchase with BTC. And it went like a charm. No problems ordering to Switzerland, withdrew payment from MtGox, got it accepted two seconds later. Great service, Bit-Pay! Makes me think: why is it not yet used everywhere? |
|
|
|
Please be more objective. I received my Mt.Gox YubiKey today. I got it for free, after my account was compromised during the last hack. Just out of interest I browsed the manufacturer's web site [1] to get some technical info on that device and found price tags at [2] that are given as 750US$ for 50 pieces. Adding the 1500 JPY Mt.Gox paid for shipping to Europe (after the devices were send from Sweden to Japan for programming), they for sure do not make money providing those YubiKeys to their customers for 30US$. If you want to complain about the money they make, better stick looking at the volumes and calculating the resulting fees (today so far: 65k*13.9US$/BTC*0.003*2 = 5421 US$). Cheers [1] http://www.yubico.com/[2] https://store.yubico.com/store/catalog/product_info.php?products_id=27I was merely pointing out have you ever heard of such a thing where a Business screws their customer base then charges them regardless if they make a profit or not its odd isn't it ? For sure I was not happy to see my account and hashed password in files freely downloadable for everyone  But hey, such things do happen regularly in modern world. Web-shops get hacked, as do companies and institutions that spend huge resources for securing their servers (VISA, FBI, Facebook, etc.). I am realistic enough to understand that there are no (and never will be) 100% secure systems. More than that, I am even aware of the potential risk to loose all my deposits at Mt.Gox (or TradeHill) after an attack more successful than the previous one. So far, I did not loose a single Satoshi - whereas seeing my hashed password flying around motivated me to double-check my security policies With respect to the charge for the YubiKey: I have to deal with a dozen of those 2-factor authentication devices to access my bank and brokerage accounts. About half of them I got for free (mostly 'cheap' TAN generators), for the others I payed some 15 to 25€ each. Cheers |
|
|
|
Please be more objective. I received my Mt.Gox YubiKey today. I got it for free, after my account was compromised during the last hack. Just out of interest I browsed the manufacturer's web site [1] to get some technical info on that device and found price tags at [2] that are given as 750US$ for 50 pieces. Adding the 1500 JPY Mt.Gox paid for shipping to Europe (after the devices were send from Sweden to Japan for programming), they for sure do not make money providing those YubiKeys to their customers for 30US$. If you want to complain about the money they make, better stick looking at the volumes and calculating the resulting fees (today so far: 65k*13.9US$/BTC*0.003*2 = 5421 US$). Cheers [1] http://www.yubico.com/[2] https://store.yubico.com/store/catalog/product_info.php?products_id=27 |
|
|
|
Ok, here it goes. I have my first mining rig up and running (3*HD6950).
Need two additional posts to leave the newbie section...
Forgot to mention: mining at ~1 GHps. Found my first block within the first two hours of mining at deepbit. Got nuts for not went solo... Meanwhile I earned some 20 BTC there (with still 1 block found) and curious how this will be statistically equalized. |
|
|
|
|
Ok, here it goes. I have my first mining rig up and running (3*HD6950).
Need two additional posts to leave the newbie section...
|
|
|
|
GPU developers, I'm too 'fresh' to post in the mining forums, hope that some seniors are around and help me out with some hints. Just started gaining interest in GPU programming after my first mining rig is up and producing some bitcents. Lurked around at AMD and Khronos websites and downloaded the documentation I found at [1]. Lots of information, but still it seems the last details are missing. What I haven't found (yet) is information on the lowest level with cycle times for machine instructions to figure out why e.g. - amd_bytealign((z^x),(y),(x)) is performing better than amd_bytealign((y),(x|z),(z&x))
- or amd_bitalign(x,x,(u)(32-y)) is faster than rotate(x,(u)y)
For the first case it might be obvious that one logical operation takes less than two of them. But for the second you need to have the cycle count for both instructions to know that one is faster than the other. Is someone aware of related documentation being freely available? Thanks [1] http://developer.amd.com/SDKS/AMDAPPSDK/documentation/Pages/default.aspx |
|
|
|
|
Sure. But you are not going to wait the day to see if the last 5MHz added to core really increased the performance, or? Especially when a short lag in network connectivity might fully distort your measurement.
I should better have asked: what is your process of finding the optimal settings for your mining HW?
|
|
|
|
Miners, just put together my first mining rig (3*6950) and was playing around to get reasonable MHps rates out of it. I'm mining at deepbit with guiminer and started first using the gfx cards untouched. I got some 270-280 each. Increasing core from 800 to 880 with MSI afterburner moves the performance to the 310-320 range, giving an overall performance of ~950 MHps (which is also reported as my rate at deepbit). Now I'd try to tweak further to get the kickin' numbers from the mining HW comparison list that gives a max of ~365 for locked HD6950s. Alas, I don't see which measure to use for reliably detecting MHps. Increasing core or voltage values further with afterburner, I see the numbers displayed by guiminer (which in fact are poclbm values) fluctuating between 180 and 320 with no clear trend indicating an increased performance. After a while (~3 min) the values stabilize near the old level of ~320 (but still fluctuating between ~290-340). As an effect, it's impossible to reliably determine if the last tweak was helpful. Even more strange are the values reported by deepbit (averaged over last 5 minutes): every now and then the MHps rate varies quite significantly in a range between 700 and 1000 with sporadic outliers going down to 300 and peaking up to 1150. And this really confuses me: how can the mean value reach 1150 while guiminer was not reporting values > 950 the previous 10 minutes? I might be missing something, but the observed issues indicate (at least for me) that there is a lack of reliable MHps measures. My best guess so far is just listening to the fans and correlate noise and performance Or, how do you measure your MHps values? |
|
|
|
|
Show Posts
