Luke-Jr: is there a way to replace the default programming file in BFG and have it use the overclocker file? Would it work if i swapped it out with the file from btfpamining? I think the bitstream included with 2.9.2 is the same overclocker one from fpgamining... |
|
|
|
My only problem now is with 2.9.2, one will get declared as sick after 10 mins or so, then the other ones will follow at random after a few minutes. Version 2.9.1 seems to be working fine but the devices will only operate at 375MH/s +/-, and sometimes the performance will slowly drop and not recover when I use the computer for browsing and other simple tasks. The only thing that can be done is restart the miner. Someone else reported this problem, but he couldn't get 2.9.1 to work at all. If you're willing, I'd love to bisect it on IRC sometime. |
|
|
|
PS: at 2.5 Taddr/s (about the speed address mining would reach if all Bitcoin's hash power were converted to GPU-optimized address mining code), you have about 0.000000000023% chance of finding one match per 4.54 billion years (age of the earth). And even if you did, I'm sure any competent jurisdiction would consider it fraud to sign a transaction with the bruteforced key spending money that isn't rightfully yours. |
|
|
|
Worst part is - it probably is something really simple. We know it does work with BFG/Win - but it is going to be a windows config issue.
Also - another interesting thing is that originally i had the x6500 showing up in device manager as a LUBUSB device - now when I plug it in - i just get a COM6 show up.
Anyone know which should i be seeing, the libusb device or the com port? Either way i still got the LIBUSB error - i never got passed that like some to the bitstream/FW load process in BFG - BFG doesn't show the device at all. WinUSB (the correct driver) is neither libusb nor emulates a COM port. |
|
|
|
|
I've had some safeguards against the "lost connection" crash in BFGMiner for a while. If anyone wants to tell Con (he likes to ignore me), the problem is that the submission threads pile up (as they sit around trying to retry) and Windows doesn't like having a lot of threads.
|
|
|
|
Is there plans to support BIP 23 Block Proposal? I could probably run a node on Eligius verifying its templates against bitsofproof with this  Yes, I build this for the server, for enterprises and miner. Bribe or inspire me and you'll get BIP 23. Not enough "bribe" to get more real-world mining testing? Proposals wouldn't be for Eligius's benefit, but for your own: your code will be tested for checking numerous possible blocks every day, and any failures will be reported to you for analysis/bugfixing. After it's proven to be reasonably reliable, I'd even make Eligius refuse to produce blocks your code rejects as a security measure - this way someone can't get Eligius to mine a block attacking bitsofproof users  |
|
|
|
Is there plans to support BIP 23 Block Proposal? I could probably run a node on Eligius verifying its templates against bitsofproof with this |
|
|
|
Now that I'm passed the stupid newbie filter, I can actually post this bug report Bug reports really belong on GitHub Issues I am noticing a slight decrease in processing power from one of my cards, a Radeon 5770 after upgrading from 2.8.2 to 2.9.2. No settings or configuration changed between upgrades. After seeing the drop I tried messing with the intensity which didn't work There were a couple of subtle changes to the OpenCL driver between 2.8 and 2.9. We could try bisecting the difference if you have time, but with the reward halving coming up in 2 weeks, I'm not sure it's worth it. If you want to do this, let me know in an Issue (since the bisect will probably take a while, best to track it there) |
|
|
|
I couldn't get my x6500 working with BFGminer  Tried posting here but seems that no one had any info/help. Luke mentioned trying a different usb driver. Still didn't help me. Seems BFGMiner will occasionally start communicating with my x6500, but gets thru a bit of programming the firmware and then BFGMiner crashes. Sometimes it gets thru programming it 100%, then it crashes. Lots of times it will fail on a JTAG detect. I think the JTAG detect code needs some work. I've been told the x6500 support is still new? So not too much help abounds there. Spent several hours doing trial and error, nothing worked. We're probably missing something. Tried the original x6500 usb driver and the one found here http://sourceforge.net/apps/trac/libusb-win32/wiki. Gave up and went back to MPBM for the x6500s. You need to be using the latest WinUSB driver. https://github.com/pbatard/libwdi/wiki/Zadig#wiki-Basic_usage (see Options menu if it doesn't show X6500s) |
|
|
|
I couldn't get my x6500 working with BFGminer Tried posting here but seems that no one had any info/help. Luke mentioned trying a different usb driver. Still didn't help me. Seems BFGMiner will occasionally start communicating with my x6500, but gets thru a bit of programming the firmware and then BFGMiner crashes. Sometimes it gets thru programming it 100%, then it crashes. Lots of times it will fail on a JTAG detect. I think the JTAG detect code needs some work. I've been told the x6500 support is still new? So not too much help abounds there. Unfortunately, I've got no idea where it's going bad for you. It's been working fine here... :/ |
|
|
|
First, no one with a reward under the minimum payout was paid yet because there were no miners who were inactive for more than 7 days at the time of payout.
((...snip...))
1KiUv3P3YCvvE2qPVhVyJQNLUdEm98TUsU --- address which hasn't mined on eligius in over a month. Just an example. Curious when your current ETA for "inactive payout" to be sent in a timely way, correctly entering a queue state or however you want to paint things with a brush of "sure, but no... well technically... uh..." More excuses is all I see from this pool's management. No excuses. Let me try and clear this up. Don't bother trying. kuzetsa won the prize for troll of the week, so I donated his entire unpaid balance to the pope. What wizkid057 said goes for all the legitimate miners. I'm joking about kuzetsa's unpaid balance, in case it wasn't obvious. |
|
|
|
Hmm... interesting. I've never had an issue getting it to clock up to 210mhz. The u is usually around 816-817mhash though.
Well, I let it get rather hot here too; usually at least 80 F. |
|
|
|
Yeah I did. It's still hashing at 840mhash, my U is at about 11.4/min It was in that area before, too. Maybe it only works up to a point. I've never seen 840 Mh/s myself. |
|
|
|
After running 2.9.2 for a little over 2 days, I haven't noticed any hashing improvement with my MMQ. Did you reprogram it? You need to either power cycle the MMQ (to clear the programming) or use --force-dev-init |
|
|
|
Git hub still compiling as 2.9.1
It's important to re-run autogen.sh |
|
|
|
NEW VERSION 2.9.2, NOVEMBER 7 2012I've also bumped the stable release to 2.8.5 including the fixes relevant to the 2.8.x versions. Human readable changelog:modminer & x6500: New bitstream, improving functional performance by about 10 Mh/s on average. You'll need to power cycle your device, or use the new --force-dev-init option to upload the new bitstream. (thanks wizkid057!)- x6500: Support for temperature sensors, including --temp-target & co.
- x6500: Extended per-FPGA details in RPC API.
- x6500: Support for older X6500 devices by manually specifying their serial numbers as --scan-serial x6500:serialnumber.
- Some basic stratum transparency checks to help keep pools accountable using new mining.get_transactions method.
Full changelog- Add endian swap defines for where missing.
- Only retarget stratum shares to new pool diff if diff has dropped.
- Bugfix: x6500: Use json_object_set_new to correctly count references to per-FPGA RPC data
- Bugfix: modminer: Use json_object_set_new to correctly count references to per-FPGA RPC data
- Bugfix: Only append newline when printing protocol data
- Bugfix: Use memchr to look for newlines in socket line data, since the buffer isn't null terminated
- Bugfix: Ensure GETWORK_MODE_GBT isn't replaced with GETWORK_MODE_POOL
- Count lost stratum share submits and increase message priority to warning.
- Show which pool untracked share messages have come from.
- Sleep 5 seconds before retrying submit.
- Changes to build prototypes to support building on FreeBSD 9.1-RC2 amd64
- Count lost shares with stratum as submit stale lost.
- Discard record of stratum shares sent and report lost shares on disconnection since they will never be reported back.
- Check that count of transactions received via stratum is reasonable
- Use realloc'd data_buffer to support stratum lines longer than 8 KB, and parse stratum responses during auth
- Use mining.get_transactions to check for stratum pool transparency (actual response ignored for now)
- ztex: Silence false "unexpected" hardware errors, and don't count them as hw errors
- README: Update build instructions to reflect current reality
- x6500: Expose per-FPGA details to RPC API
- x6500: Implement support for --temp-target
- x6500: Increase default clock frequency to 200 Mhz, now that new bitstream seems to run well around that
- x6500: Flush nonces in FPGA buffer at initialization to avoid false hw errors on restart
- x6500: Release device lock sooner during initialization, before logging initial frequency info
- x6500: Read temperature sensors after sending work, when enabled
- Bugfix: jtag: Fix optimized register reading code (it was reading an extra bit before the last, corrupting outside the buffer)
- Implement new --force-dev-init option to force bitstream upload to modminer and x6500 devices
- Bugfix: x6500: Include --scan-serial option even for x6500-only builds
- Bugfix: ztex: Include --scan-serial option even for ztex-only builds, so it can be used to disable autodetect if needed
- FPGA-README: Discuss X6500 --scan-serial usage of cases where it may be needed
- ft232r: If we are searching for a specific serial, pay no attention to the product id
- x6500: Try a more flexible approach to applying dynclock logic
- Bugfix: dynclock: Use standard C struct initializer to handle initialization, instead of memsetting memory to nulls
- x6500: Whenever we get a hardware error, purge buffers just in case of read/write desync
- Bugfix: x6500: When purging ft232r buffers (during bitstream upload), also clear JTAG delayed read counter to avoid any potential desync
- Bugfix: ft232r: Always flush writes before purging buffers, and empty local read buffer when flushing ftdi read buffer
- There is no need for addrinfo any more.
- Fix filename for x6500 bitstream to match previous commit's rename
- Rename x6500 bitstream to match existing licensing naming setup
- x6500 dual temp sensor support
- x6500 is far more stable with its own bitstream
|
|
|
|
I can confirm that I independently downloaded the blockchain off p2p, processed it with mkbootstrap, and reimported the orphan-cleaned blocks into a new Bitcoin and got an identical SHA256 hash for blk0001.dat. The dat file is trustworthy (and makes mine implicity verified too...). I will add this torrent to my blockchain download thread, where I also will have a blk0002.dat/full index for blocks up to 206000 for those that want to download a drop-in blockchain up to Oct 2012. Right now the torrent has three seeds and one peer. This thread is obsolete. You'll want to check out this thread: https://bitcointalk.org/index.php?topic=117982.0Not really, they serve different purposes. |
|
|
|
Anyway, my point was that if you can't create an automated way to make Bitcoin/mining safer by use of the transaction data while mining, then it makes no sense for it to be mandatory to push all that redundant data back and forth. But we can. Even without a local bitcoind, miners can setup multiple pools and the miner can avoid pools that have an odd contradicting transaction compared to all the others. |
|
|
|
Just a heads up, in the state of Florida, it is illegal to possesses a firearm at any location that sells alcohol for consumption on the premises. This includes a CCW permit. So don't plan on visiting any bars or restaurants while carrying. Yep, that's why bars are automatically excluded. However, at least the courts have interpreted the law to NOT include restaurants beyond a special section set aside for alcohol (eg, Olive Garden has a "bar" type area). |
|
|
|
|
Show Posts
