Darn, didn't try benchmark. Presumably that b0rk with the networking upgrade.
|
|
|
Con, sorry, maybe I was not clear. Every time you startup, you look for bin files with "cgminer-version-bin-file-name.bin" bin names, if not found create a bin and put current cgminer version in the file name. When the user upgrades to next version of cgminer, you'll not find the bin because you'll be looking for "my-current-cgminer-version-bin-file-name.bin", so you recreate. When they run cgminer again, you already have a bin that does match your current cgminer version so you use it.
That way you don't recreate bins every time someone runs cgminer, only when they upgrade to new cgminer version.
Makes sense?
Yes but then that would make it hard for someone to do what this user just did: copy over the bin files from 2.3.6 to get the benefit from before they fucked up their SDK installation.
|
|
|
I guess you haven't deleted the .bin files between testing...
cgminer-2.3.6 and cgminer-2.4.0 located in different folders. I copied config file from 2.3.6 to 2.4.0 and received result 418Mh/s Did you delete the .bin files in the 2.3.6 directory after upgrading your driver+sdk? Con, it might be worthwhile to put cgminer version in the bin file name so that you can detect upgrades and force recompiles on the fly. I cannot seem to win with this never ending SDK upgrade fail problem. At least people have the option of keeping around a .bin file from an older SDK installation and use it on the current cgminer provided the kernel hasn't changed in the interim. No solution seems optimal, and most of the problem seems to surround the optimisation cgminer does by caching the .bin file which speeds startup of cgminer significantly. If I forced it to build the kernel every single startup, there would never be this confusion, but startup would be butt slow if you had lots of GPUs whereas now it starts hashing in the blink of an eye after the very first startup.
|
|
|
Geez, all you need is someone to set up p2pool for you on your VPS if you can't do it yourself. You don't need anything more than that for an operation of your size. That'd take about 5 mins on any common linux distribution.
|
|
|
I guess you haven't deleted the .bin files between testing...
cgminer-2.3.6 and cgminer-2.4.0 located in different folders. I copied config file from 2.3.6 to 2.4.0 and received result 418Mh/s Did you delete the .bin files in the 2.3.6 directory after upgrading your driver+sdk? No. Here are the contents of my folders: This is what I'm trying to say.. .that has been said many times and is in the FAQ. If you run cgminer, it caches the binary built from the SDK installed the very first time you run it, and then even if you upgrade driver+SDK, it still runs like the old SDK. However if you install a new cgminer, there are no cached .bin files (see the .bin files in each folder), so it generates a new .bin file from the current SDK installed. The only way to compare versions 2.3.6 and 2.4.0 with your current installation of driver+SDK combination is to delete the .bin files from both of them and start them both again.
|
|
|
Yes, I know this is loooooongshoot, but I`m getting 0.01-0.02/block on pool so.... ;]
bitcoind does not accept "shares", only p2pool does. If you're mining in bitcoind, it only accepts block attempts and nothing else. If you're mining on both bitcoind and p2pool, then you'll see shares going to p2pool and pretty much nothing while you're on bitcoind unless you hit the jackpot. The longpolls will keep coming in and that has pretty much nothing to do with bitcoind since they're coming from p2pool, and when a longpoll comes in, some work is sneaking to p2pool in the process. In short, these miniscule amounts you're earning are coming from p2pool. If you found a block, cgminer would also add the words BLOCK! to a share, and you'd earn 50+ BTC.
|
|
|
I guess you haven't deleted the .bin files between testing...
cgminer-2.3.6 and cgminer-2.4.0 located in different folders. I copied config file from 2.3.6 to 2.4.0 and received result 418Mh/s Did you delete the .bin files in the 2.3.6 directory after upgrading your driver+sdk?
|
|
|
cgminer-2.3.6 + OpenCl from AMD Catalyst 12.5 Beta = 462Mh/s cgminer-2.4.0 + OpenCl from AMD Catalyst 12.5 Beta = 418Mh/s
Considering none of the opencl, GPU or kernel code was changed between 2.3.6 and 2.4.0, I find that a little more than a little unlikely. I guess you haven't deleted the .bin files between testing...
|
|
|
cgminer-2.3.6 + OpenCl from AMD Catalyst 12.5 Beta = 462Mh/s cgminer-2.4.0 + OpenCl from AMD Catalyst 12.5 Beta = 418Mh/s
Considering none of the opencl, GPU or kernel code was changed between 2.3.6 and 2.4.0, I find that a little more than a little unlikely.
|
|
|
Here is my best guess: 2. Intel HD Graphics = 3-10 mhash
That seems a bit optimistic IMO. I'm guessing it would be around 500khash. LOL, you may be the first person to estimate even less than I would have.
|
|
|
I use cgminer-2.3.6 on my HD 5870 and received 460-462 Mh/s. In the new version cgminer-2.4.0 was just 418 Mh/s. Sys. Win7x64 + OpenCl from AMD Catalyst 12.5 Beta http://www.ngohq.com/home.php?page=Files&go=giveme&dwn_id=1624Maybe, you should pay attention to the new drivers and optimize a new version of CGMINER Wrong, you should downgrade your driver and read the FAQ.
|
|
|
We're not there yet I'm guessing, even with the new version of CGMiner cgminer version 2.4.0 - Started: [2012-05-03 10:31:14] -------------------------------------------------------------------------------- (5s):314.4 (avg):296.8 Mh/s | Q:573 A:285 R:18 HW:0 E:50% U:3.7/m TQ: 2 ST: 9 SS: 5 DW: 158 NB: 9 LW: 731 GF: 7 RF: 6 Connected to http://pool.bonuspool.co.cc:80 with LP as user DutchBrat Block: 00000a50b14e181ee2eddb662905d6da... Started: [11:40:04] -------------------------------------------------------------------------------- [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit GPU 0: 73.0C 2436RPM | 312.3/296.8Mh/s | A:285 R:18 HW:0 U: 3.73/m I: 5 --------------------------------------------------------------------------------
[2012-05-03 11:45:07] Accepted cd1d2d67.dbb1ffa3 GPU 0 pool 0 [2012-05-03 11:45:10] Accepted aecd4b84.ee3321f3 GPU 0 pool 0 [2012-05-03 11:45:14] Accepted 5ac588ed.f944086e GPU 0 pool 0 [2012-05-03 11:45:39] Accepted 4ba3b78c.43439465 GPU 0 pool 0 [2012-05-03 11:45:46] Accepted 033d897c.54c84c35 GPU 0 pool 0 [2012-05-03 11:46:16] Pool 0 communication failure, caching submissions [2012-05-03 11:46:37] Pool 0 communication resumed, submitting work [2012-05-03 11:46:37] Rejected bc157d83.3ba10608 GPU 0 pool 0 [2012-05-03 11:46:53] Rejected dcc02b84.454b2080 GPU 0 pool 0 [2012-05-03 11:46:59] Rejected 5396d980.319d0554 GPU 0 pool 0 [2012-05-03 11:47:06] Rejected b659cd6f.299f9fcd GPU 0 pool 0 [2012-05-03 11:47:26] Accepted 17cc28c1.95018954 GPU 0 pool 0 [2012-05-03 11:47:32] Accepted 708e48de.01d0c49c GPU 0 pool 0
![Wink](https://bitcointalk.org/Smileys/default/wink.gif) That's the code being polite... you should see what it would have done before.
|
|
|
The previous code definitely was not polite and had a "take no prisoners" approach so it would bombard by default for the miner's benefit and if anything went wrong at the pool end, the pool would get hammered.
|
|
|
Bumping this up to stress again that all users of cgminer should immediately upgrade to the latest version! You will definitely see a performance improvement since the longpoll handling has been fixed to not cause occasional problems with PoolServerJ-based pools. https://bitcointalk.org/index.php?topic=28402.0 - Get it now! Hopefully the pool itself should also notice a significant decrease in load as people migrate to this version.
|
|
|
Cool, seems CGMINER 2.4 just got released, hopefully no surprises for me ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) I definitely had services like yours in mind when I developed it, so I hope not ![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
|
|
|
NEW VERSION: 2.4.0 - May 3, 2012
This version has a fairly significant upgrade to the way networking is done, so there is a minor version number update instead of a micro version, but it has already been heavily tested.
Human readable changelog: A whole networking scheduler of sorts was written for this version, designed to scale to any sized workload with the fastest networking possible, while minimising the number of connections in use, reusing them as much as possible. The restart feature was added to the API to restart cgminer remotely. If you're connected to a pool that starts rejecting every single share, cgminer will now automatically disable it unless you add the --no-pool-disable option. Once a pool stops responding, cgminer won't keep trying to open a flood of extra connections. Failing BFL won't cause cgminer to stop; it'll just disable the device, which an attempt may be made to re-enable it. Hashrates on FPGAs may be more accurate (though still not ideal). Longpoll messages won't keep going indefinitely while a pool is down.
Full changelog: - Only show longpoll warning once when it has failed. - Convert hashes to an unsigned long long as well. - Detect pools that have issues represented by endless rejected shares and disable them, with a parameter to optionally disable this feature. - Bugfix: Use a 64-bit type for hashes_done (miner_thread) since it can overflow 32-bit on some FPGAs - Implement an older header fix for a label existing before the pthread_cleanup macro. - Limit the number of curls we recruit on communication failures and with delaynet enabled to 5 by maintaining a per-pool curl count, and using a pthread conditional that wakes up when one is returned to the ring buffer. - Generalise add_pool() functions since they're repeated in add_pool_details. - Bugfix: Return failure, rather than quit, if BFwrite fails - Disable failing devices such that the user can attempt to re-enable them - Bugfix: thread_shutdown shouldn't try to free the device, since it's needed afterward - API bool's and 1TBS fixes - Icarus - minimise code delays and name timer variables - api.c V1.9 add 'restart' + redesign 'quit' so thread exits cleanly - api.c bug - remove extra ']'s in notify command - Increase pool watch interval to 30 seconds. - Reap curls that are unused for over a minute. This allows connections to be closed, thereby allowing the number of curl handles to always be the minimum necessary to not delay networking. - Use the ringbuffer of curls from the same pool for submit as well as getwork threads. Since the curl handles were already connected to the same pool and are immediately available, share submission will not be delayed by getworks. - Implement a scaleable networking framework designed to cope with any sized network requirements, yet minimise the number of connections being reopened. Do this by create a ring buffer linked list of curl handles to be used by getwork, recruiting extra handles when none is immediately available. - There is no need for the submit and getwork curls to be tied to the pool struct. - Do not recruit extra connection threads if there have been connection errors to the pool in question. - We should not retry submitting shares indefinitely or we may end up with a huge backlog during network outages, so discard stale shares if we failed to submit them and they've become stale in the interim.
|
|
|
As reported in another thread, the latest GIT updates improved cgminer performance with Clipse's bonuspool noticeably. With 2.3.6 my router had hundreds of active connections to the pools, now there are max. 20. If you're mining with bonuspool, you should try and build cgminer from latest GIT sources. Thanks for the feedback. This update has been significant enough to release a new version so I'm planning on releasing 2.4.0 soon.
|
|
|
Additionally, I noticed that the total mining power at TripleMining averages to about 80GH/s, as opposed to Deepbit's total mining power at over 3TB/s, which gave me the assumption that all the major/super-dedicated miners mine there. It's almost certainly the opposite. Major super miners care about profits, and profits are at their lowest on a hoppable prop pool with 3% fees or non-hoppable but heart-stopping PPS 10% fee. If anything's keeping people at deepbit, it's inertia, perceived advantage of mining with the biggest, language issues, and botnets. I work in concert with some of the biggest miners that use cgminer when developing it, and none of them use deepbit except as a backup pool.
|
|
|
127 is a "bug" value. It means the driver has crashed and is reporting nonsense. It does not actually mean the temperature is 127.
|
|
|
|