Bitcoin Forum
January 17, 2021, 04:08:55 PM *
News: Latest Bitcoin Core release: 0.20.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 [6] 7 »
101  Other / CPU/GPU Bitcoin mining hardware / Re: [SOLVED] 6990 Flashed BIOS Problems on: October 10, 2011, 11:45:30 PM
Thanks NLA,

I am doing some tweaking to find optimal settings with my setup and plan to post a comprehensive HowTo with our collective findings.
102  Bitcoin / Pools / Re: [1800 GH/sec] BTC Guild - 0% Fees, LP, SSL, API, 8 Decimal Payouts and more! on: October 09, 2011, 06:51:57 PM
The last share issue should now be fixed (it should no longer show 24 hours randomly).  The idle miner email issue has also been fixed, you should resume receiving idle emails if something is wrong with your miner.


Looking good eleuthria. Thanks for all your hard work!
103  Bitcoin / Pools / Re: [1800 GH/sec] BTC Guild - 0% Fees, LP, SSL, API, 8 Decimal Payouts and more! on: October 06, 2011, 03:36:48 PM
Anyone else been seeing intermittent weirdness with Last Share stats in the web interface and API lately? I have been noticing that every once in a while Last Share jumps to 24 hours. This seems to be more frequent on my slower workers that don't submit shares as frequently. The trouble seems to have started with the live worker stats update.

For reference:




104  Other / CPU/GPU Bitcoin mining hardware / Re: [SOLVED] 6990 Flashed BIOS Problems on: October 06, 2011, 12:39:11 AM
I've flashed both of my 6990's in the overclocked position using RBE & atiflash, no problems at all using Ubuntu and fglrx drivers.
I have them set to 600mhz memory, used to be 150mhz but I changed it in fear of causing damage.

Care to provide details on what you changed and how you changed it?

e.g. For the overclock BIOS on my rig I did the following:

1) With power off, set BIOS switch to overclock position on each 6990.
2) Boot to DOS on your mining rig with CD/USB/floppy (like Ultimate Boot CD) and attach media with ATIFlash.exe if not on the boot media.
3) Enumerate all cards detected with ATIFlash -i
4) Document the BIOS checksum for each of your cards with ATIFlash -cb x where x is your adapter ID provided in step 3.
5) Dump BIOS on each adapter to USB/floppy with ATIFlash -s x BIOSx.ROM where x is the adapter ID.
6) Remove USB/floppy and attach to a Windows PC with RBE.
7) Load each BIOSx.ROM into RBE where x is the adapter ID.
Cool In the Clock settings tab, locate Clock info 00 (this should have GPU (MHz) = 880).
9) Modify the settings for Clock info 00 to have GPU (MHz) = 880, RAM (MHz) = 150, Voltage (V) = 1.175. (Note: Only change the RAM MHz value)
10) Modify the settings for Clock info 03 to have GPU (MHz) = 800, RAM (MHz) = 150, Voltage (V) = 1.175. (Note: Only change the RAM MHz value)
11) In the GPU registers edit VID4 (mV) from 1175 to 1050.
12) Save each BIOS image to the USB/floppy named as BIOSxNEW.ROM where x is the adapter ID.
13) Move the USB/Floppy back to your mining rig.
14) Confirm the checksum on each ROM image with ATIFlash -cf BIOSx.ROM and compare with your previously documented values for each adapter.

If and only if the checksums match proceed to the next steps

15) Flash each new BIOS onto the respective adapter with ATIFlash -p x BIOSxNEW.ROM where x is the adapter ID.
16) Once all adapter BIOS images have been flashed, reboot. It is important not to reboot until both master/slave BIOS on a card have been flashed before rebooting.
17) Boot back into Linux, and confirm the clock settings have been updated with DISPLAY=:0 aticonfig --adapter=all --odgc
18) Mine away!




105  Other / CPU/GPU Bitcoin mining hardware / Re: [SOLVED] 6990 Flashed BIOS Problems on: October 05, 2011, 06:35:41 PM
what driver version are you on?

I'm using the 11.8 drivers with APP v2.5, and ADL 3.0 on CentOS 6 x86_64 mining with cgminer 2.0.5.

106  Other / CPU/GPU Bitcoin mining hardware / Re: Strange 6990 BIOS Flash Problems? on: October 04, 2011, 11:57:29 PM
EDIT:

[SOLVED] AND JUST LIKE THAT, I FIGURED IT OUT. OK, here's the deal: when I was modding the BIOS for my 6970's, I changed voltages and memory clocks for all 'modes' of the 6970 (boot, performance, etc), so no matter what, the same voltage and memory underclock would run all the time. Apparently you can't do that with the 6990 Master and Slave BIOS: you have to just edit the memory speed in the column with the 880core, and just edit the 1175mV voltage (to something else) in the GPU register -- leave everything else alone! I hope this helps anyone else out there that has been having trouble with this, as no one else on the internet apparently has had this problem. The 6990 BIOS is apparently more sensitive to changes than the 6970.

Would you mind posting a writeup on the specifics of what you had to change with GPU-Z/RBE/WinFlash for your 6990s to drop your memory clock to 300MHz with a core clock > 125MHz above the memory clock? Like many, I have tried dropping the memory clock below the core clock with the stock 6990 BIOS via cgminer and other tools like aticonfig, atitweak and AMDOverdriveCtrl only to see the memory clock jump back up to 1250MHz when mining.

Your post seems to be the only reference to this even being possible with 6990s on Linux and I for one would be very appreciative of some guidance.


107  Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx on: August 31, 2011, 04:06:53 PM
This has probably already been answered but honestly.... some people have better things to do than re-read 60 pages of a thread.

When I use cryptopp_asm32 mode for the CPU miner, I get ridiculously wrong values for the hash rate - things like 150 MH/s, wildly fluctuating up and down and the 5 sec average frequently displaying Nan.  Is there a bug in the rate calculation for that algorithm?
I'd say the cryptopp_asm32 on windows is likely broken.

I'm seeing the same wildly inaccurate hash rate reporting on Linux with cryptopp_asm32 as well. it looks like this is just the reporting though as the pool is reporting normal values from my miner.
108  Bitcoin / Pools / Re: [~2400 GH/sec] BTC Guild - 0% Fees, LP, SSL, API, 8 Decimal Payouts and more! on: August 04, 2011, 08:28:29 PM
eleuthria, any possibility we could get 24 Hour Luck added to the JSON API? This would be helpful to reference WRT the 24 hour rewards already available in the API over the same time period.
109  Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx on: August 03, 2011, 12:24:23 AM
What is wrong with  leaving in the manual override option?  What is crappy about leaving people  the option to not install more abstraction layers on things they don't want?  If I want enough abstraction layers I may as well just go use windows and autoupdates.

Did you actually read ./configure --help at some point? Is it your vax experience that did not prevent you from blaming pkg-config that is preventing you from exporting LIBCURL_LIBS and LIBCURL_CFLAGS before running ./configure if so you wish? --with-libcurl option was broken and hence removed. If you don't want to use pkg-config, fine, override the flags and there you go. I have just checked it by uninstalling pkg-config and it works fine.

Works for me as well ala:

Code:
CFLAGS=-I/usr/local/cuda/include LDFLAGS="-L/usr/local/cuda/lib -L/usr/lib/nvidia-graphics-270.41.19" LIBRARY_PATH="/usr/local/cuda/lib:/usr/lib/nvidia-graphics-270.41.19:/usr/local/lib" LIBCURL_LIBS=/usr/local/lib/libcurl.so LIBCURL_CFLAGS=-I/usr/local/include ./configure

110  Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx on: August 01, 2011, 04:21:12 PM
Looks like the 1.5.3 configure script inadvertently dropped support for alternate cURL library path support via --with-libcurl:

Code:
$ ./configure --with-libcurl=/usr/local/lib/

configure: WARNING: unrecognized options: --with-libcurl
.
.
111  Bitcoin / Pools / Re: [~2250 GH/sec] BTC Guild - 0% Fees, LP, SSL, API, 8 Decimal Payouts and more! on: July 20, 2011, 05:07:08 PM
Fixed the problem with payout processing.

I've also had quite a few emails regarding the new stats "Last Block Awarded" and "Shares Since Last".

Last Block Awarded is just as it sounds.  It's how long since a block was announced and the rewards were allocated to accounts.  Everytime that timer resets, you will have new confirmed/unconfirmed rewards (assuming you participated in that block).

"Shares Since Last" is a compromise.  Many people were upset that "Round Shares" was removed.  The increasing counter provided some sign that the server as a whole was continuing to accumulate shares towards the next block.

The value of Shares Since Last will be equal to:  The number of shares since the last block announcement, plus one hour.  So if a block was announced 45 minutes ago, Shares Since Last will contain 1 hour and 45 minutes of shares.  There may be any number of unannounced blocks that are waiting to be announced (solved within the last hour).  It is possible there are no blocks in that number as well.

Any possibility these could get added to the JSON API? These are good stats for widgets/pool health monitoring.
112  Bitcoin / Pools / Re: [~2250 GH/sec] BTC Guild - 0% Fees, LP, SSL, API, 8 Decimal Payouts and more! on: July 18, 2011, 06:34:49 PM
Thanks for getting the Last Share stats working again eleuthria! 

Grin

That graph is so painful to look at, poor CPU miners.  Although that's a pretty good example of variance in bitcoin hashing, since a CPU working on difficulty 1 is pretty similar to a pool working on difficulty 1.5 million =).

Hehe... Yea, and this graph is from my most powerful miner at the moment while the 6990s are on backorder Sad 
113  Bitcoin / Pools / Re: [~2250 GH/sec] BTC Guild - 0% Fees, LP, SSL, API, 8 Decimal Payouts and more! on: July 18, 2011, 05:26:46 PM
Thanks for getting the Last Share stats working again eleuthria! 

Grin
114  Bitcoin / Pools / Re: [2220 GH/s] Slush's Bitcoin Mining Pool (mining.bitcoin.cz) on: July 18, 2011, 04:35:35 PM
Hi Slush,

After watching my worker stats for the past few days with my Cacti template that uses the JSON API, I noticed the last share times seemed to jump around for the running workers.



The following graph shows another worker that was shut down late Thursday night and stopped submitting shares. The initial jump to ~9600 seconds at ~22:40 (the time I shut the worker down) is odd given the previous values, but the growth rate from then to the end of the graph on the right looks normal.


Since the JSON API provides the last_share time in UNIX time format, my script simply subtracts the last_time value for the worker from the current time to get the elapsed time in seconds. It seems to work most of the time, save the weird spikes shown in the first graph.

Is it possible one or more of the servers providing the last share data aren't synced time-wise resulting in these jumps as load balancing shifts the JSON API query to one of the affected servers?

Still no response on this eh? Just for reference, this is what it looks like when the time is reported correctly (from BTC Guild):
115  Bitcoin / Pools / Re: [2220 GH/s] Slush's Bitcoin Mining Pool (mining.bitcoin.cz) on: July 18, 2011, 04:05:34 PM
Ok well it showed up. But in our recent 140 minute block I mined for the first 120 minutes before my PC crashed, during which I submitted about 1300 shares. My reward per block is normally 0.015 BTC but this blockI was only rewarded 0.0012 (10x less)?? Why isn't my work being counted?

Because of the score based system.  Each share is worth more than the previous one, on an exponential curve.

That's ridiculous, I legitimately submitted shares in 120/140 minutes because of a BSOD and I get 10 times less?

I may as well just not have mined for 2 hours at all...all of the money that I worked for is getting paid to everyone else who didn't legitimately work for it...

That's the reason I switched to deepbit. I like slush but my computer network is not always stable.

To be fair, slush implemented the score based system to prevent pool hopping (which is bad to the pool). I just wish they implement a different method such as delayed stats.

BTC Guild just implemented delayed stats within the past week. The jury is still out on whether things have improved for those of us who don't pool hop, but time will tell.
116  Bitcoin / Pools / Re: [2220 GH/s] Slush's Bitcoin Mining Pool (mining.bitcoin.cz) on: July 08, 2011, 11:18:00 PM
Hi Slush,

After watching my worker stats for the past few days with my Cacti template that uses the JSON API, I noticed the last share times seemed to jump around for the running workers.



The following graph shows another worker that was shut down late Thursday night and stopped submitting shares. The initial jump to ~9600 seconds at ~22:40 (the time I shut the worker down) is odd given the previous values, but the growth rate from then to the end of the graph on the right looks normal.


Since the JSON API provides the last_share time in UNIX time format, my script simply subtracts the last_time value for the worker from the current time to get the elapsed time in seconds. It seems to work most of the time, save the weird spikes shown in the first graph.

Is it possible one or more of the servers providing the last share data aren't synced time-wise resulting in these jumps as load balancing shifts the JSON API query to one of the affected servers?
117  Bitcoin / Pools / Re: [2220 GH/s] Slush's Bitcoin Mining Pool (mining.bitcoin.cz) on: July 08, 2011, 05:24:29 AM
Hi folks,

I recently added support for Slush's pool to my Cacti monitoring template. Here are a few sample graphs:

User Rewards


Worker Hash Rate (OpenCL)


Worker Hash Rate (Total all workers)


Worker Last Share (OpenCL)


Worker Last Share (Total all workers)


Worker Score (OpenCL)


Worker Score (Total all workers)


Worker Shares (OpenCL)


Worker Shares (Total all workers)


If this looks interesting to you, installation instructions and additional details can be found on the following thread: http://forum.bitcoin.org/index.php?topic=23406.0

Have fun!
118  Bitcoin / Pools / Re: [~2700 GH/sec] BTC Guild - 0% Fees, Long polling, SSL, JSON API, and more on: July 04, 2011, 04:48:48 PM
Cmon guys find a block 5.6 million shares already...

Looks like it was just solved, but something must have been goofed up again:

119  Bitcoin / Mining / Re: "Rug Monitor" - Monitor your mining rigs (graphs for hashrate, temps, etc.) on: June 30, 2011, 05:13:58 AM
To get the hash rate out of phoenix, you can also use my XML-RPC interface approach instead of parsing log files.

Good stuff! I'll roll this into my Cacti templates (http://forum.bitcoin.org/index.php?topic=23406.0) when the 6990's come in...
120  Bitcoin / Pools / Re: [~3000 GH/sec] BTC Guild - 0% Fees, Long polling, SSL, JSON API, and more on: June 29, 2011, 01:24:00 PM
The round time didn't reset after the last block it's currently up to 3hr 55min (should be around 50 minutes).

Everything else looks good though. =)

Yep, looks to be just the round time stats, but the rounds are rolling along mostly like normal. The round that ended at 01:25 local time seems to have been one of the longest I have seen since turning on monitoring though.




Pages: « 1 2 3 4 5 [6] 7 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!