That's the ubuntu binary I guess? I'll rebuild it without needing dynamic libjansson
Yep, it's the Ubuntu binary. Uploaded fresh builds. Try again. It's running now, but it says it's running 2.11.3. I can see the 2.11.4 cosmetic changes (removed queued, efficiency and discarded work) though, so I know I copied over the right files.  Yeah my bad, I built from the master git branch which isn't labelled 2.11.4, but you do have the latest code (and the no-one-ever-READMEs). |
|
|
|
That's the ubuntu binary I guess? I'll rebuild it without needing dynamic libjansson
Yep, it's the Ubuntu binary. Uploaded fresh builds. Try again. |
|
|
|
Getting an error when I try running 2.11.4. 2.11.3 is running just fine. error while loading shared libraries: libjansson.so.4: cannot open shared object file: No such file or directory That's the ubuntu binary I guess? I'll rebuild it without needing dynamic libjansson |
|
|
|
|
New version: 2.11.4 - 5th April 2013
Cosmetic changes and documentation updates only. For those on git, this version is being made from the 2.11 branch, not master.
Human readable changelog:
Lots more documentation that won't be read has been added to README and SCRYPT-README.
Removed many of the values from the display that are no longer relevant in the stratum mining world.
Logging wouldn't work without the text user interface enabled.
Yet more tweaks to the hashrate display.
Full changelog:
- Remove bfl-sc option from configure for 2.11 branch.
- Only update hashrate calculation with the log interval.
- Update the total_tv_end only when we show the log to prevent failure to update
logs.
- Minor README updates.
- Add example 7970 tuning for scrypt in readme.
- Update driver recommendations.
- Add extensive GPU FAQs for the flood of new Scrypt miners.
- Remove help option for cpumining in build environment.
- Remove scripts that make it too easy to compile CPU mining support.
- Win32 and win64 build updates
- Remove references to CPU mining from README.
- Show share hash as little endian as needed.
- usbutils extra message requirements
- Make hashmeter frequency for hash_queued_work match sole_work.
- Update links and recommended SDKs.
- Update scrypt readme re drivers and sdk.
- usbutils.c usb_cmdname() usb_cmds -> string name
- BFL FPGA Windows timeout set to 999ms
- AUTHORS - spam update time (one year since the last)
- Update README for x970 memdiff values.
- Update README to match changes to display.
- Remove increasingly irrelevant discarded work from status lines.
- Remove increasingly irrelevant queued and efficiency values from status and
move WU to status line.
- Allow cgminer to start if usb hotplug is enabled but no devices yet exist.
- Do not scan other gpu platforms if one is specified.
- Update README for sync objects on windows.
- Update README about intensity.
- Add information for setting gpu max alloc and sync parameters for windows with
scrypt.
- If the hashmeter is less than the log interval and being updated by the
watchdog, don't update the hashrate.
|
|
|
|
I have a weird problem.. cgminer crashes at startup.
It seems like it cannot create the .bin files. Using an older cgminer that already has them generated works fine though. I'm on Windows 8, Catalyst 13.2.
Even the bare minimum configuration doesn't work.
Running cgminer as administrator does nothing to help as well.
You've borked your SDK installation with mixed files. |
|
|
|
It seems to hash correctly though, but it is submitting 3-4 shares per second, I thought it would automatically adjust difficulty.. isn't that one of stratum's features ?
No, that's a pool feature. |
|
|
|
here is nothing that says that all future ASICs will have this same hardware limitation. It is an intrinsic design flaw/limitation/shortcut taken in the first generation Avalons.
it affects more devices, the bfl singles have the same issue. the minirigs have a work around, but sort of the same as well. I will bet money the bfl SC when/if they come out will as well. The way the current asics are designed is the issue, they are clusters of many small devices with overhead. No, the BFL SC devices do not suffer this. |
|
|
|
|
To take out variables, please at least upgrade to latest cgminer!
|
|
|
|
Hi! May I ask you where do I get the bflsc drivers?
Why, do you have one? The drivers are incomplete since the hardware doesn't exist outside of BFL labs yet so we have not posted any of the code. I wish to have mine! But I was thinking about having the cgminer built and ready when my bfl arrives sometime in the future (I hope!) It will definitely be available before you get yours. |
|
|
|
Hi! May I ask you where do I get the bflsc drivers?
Why, do you have one? The drivers are incomplete since the hardware doesn't exist outside of BFL labs yet so we have not posted any of the code. |
|
|
|
It sounds like forrestv is instead in favor of alternate means to extend the effective work interval through merging of parallel chains. Various theoretical designs were discussed.
We may end up making a fork or a frankenbuild of p2pool to fix things for testing. I don't see why in the end it would need to fork for everyone, but it would be a hard fork and everyone would need to upgrade to a version where everyone is on the same share chain.
It ultimately seems like 10 seconds is just too short, given Internet propagation, current Avalon hashrate, and the up to 1.5-second delay it can take for work to be returned from Avalons (high latency). Thus, I argue for around 30 seconds, which would imply a hard fork at some point. No, taking this direction is a mistake. You are trying to redesign p2pool around the design of one device. There is nothing that says that all future ASICs will have this same hardware limitation. It is an intrinsic design flaw/limitation/shortcut taken in the first generation Avalons. |
|
|
|
|
Nope, voltage changes are ignored by the driver on linux. Don't overvolt anyway, it's the only dangerous form of overclocking and the increase in power consumption is far greater than any increase in hashrate.
|
|
|
|
|
Dual 6870s are not well supported and need a specific driver and sdk combo. What, I can't tell you offhand since they are so rare.
|
|
|
|
Use an older driver/sdk combination, and don't go above intensity 11.
Mad props! Downgraded to 12.8 and worked like a charm! Much much better rates on both BTC and LTC ...! Thanks I wrote the program, I should know  |
|
|
|
How can I use my computer while mining with cgminer?
I'm currently mining Bitcoins and Litecoins, (AMD 5850)
for Bitcoins I use 'GUIMiner' using 'OpenCL miner',
for Litecoins I use 'GUIMiner-scrypt' using 'cgminer'.
Now, for Bitcoins I just add the flags "-v -w128 -f 60" and it works extremely fast even when I play BF3 and nothing shatters (If I play heavy graphics games it will go down to ~150Mha/s tops, and when I finish playing it jumps back to ~300Mah/s), the computer works flawlessly,
but for Litecoins whenever I use the flag "-I d" it goes down to 10% of it's power (from 325Kha/s to 30-20Kha/s) even when I just look at the computer!
So again, my question is, is there any way to have the same experience with performance while using the computer with cgminer?
Or, alternatively, is there anyway I can mine Litecoins with GPU, using the computer at the same time and still have maximum performance as I just demonstrated that I have with OpenCL miner?
thanks for the help, hope I gave all the details necessary!
Yes, that IS the experience with scrypt in dynamic mode. You have to sacrifice loads of hashing performance for the desktop to be usable. Alternatively find a static intensity where you can deal with the lag. |
|
|
|
problem:
$ ./cgminer -n
[2013-03-31 14:05:49] CL Platform 0 vendor: Advanced Micro Devices, Inc.
[2013-03-31 14:05:49] CL Platform 0 name: AMD Accelerated Parallel Processing
[2013-03-31 14:05:49] CL Platform 0 version: OpenCL 1.1 AMD-APP-SDK-v2.4 (595.10)
[2013-03-31 14:05:49] Error -1: Getting Device IDs (num)
[2013-03-31 14:05:49] clDevicesNum returned error, no GPUs usable
[2013-03-31 14:05:49] 0 GPU devices max detected
$
Tho
aticonfig --lsa
* 0. 06:00.0 AMD Radeon HD 6800 Series
1. 07:00.0 AMD Radeon HD 6800 Series
* - Default adapter
thoughts?
Usual initial advice: Have you installed AMD driver, configured Xorg for all your devices, started it and exported the DISPLAY variable. |
|
|
|
|
Use an older driver/sdk combination, and don't go above intensity 11.
|
|
|
|
Same cards in a rig... CGminer
Different cards in a rig... Reaper.
I don't understand this reasoning. |
|
|
|
Just get an Avalon for ckolivas and cgminer will be hashing Avalon on all working pools as quickly as possible.
I don't want an Avalon as I have made clear for quite a while now.
So no, it's not get "cgminer team" an Avalon, it's get "ckolivas" an Avalon.
This is happening next week. If plans go well. I should reiterate this is happening due to the generous offer from Aseras himself to provide me remote access to his units. Since p2pool is part of Aseras' concerns, I will try and address anything I can from the cgminer end but I think that will only achieve so much. Xiangfu has said that they should send me an actual unit, but he doesn't have that power himself, and thinks he should try and convince them. |
|
|
|
I was curious about starting a pool just for fun. This thread changed my mind, it doesn't sound fun at all.
I wasn't joking about: The benefits? Realistically: many sleepless nights, headaches, heartaches, trolling, frustration, loss of money and the very slim chance of making a profit...
and eleuthria with: Con: Dealing with botnets that screw up your servers by overloading them and then dealing with assholes who DDoS you when you kick them off.
Eleuthria is making a sizeable profit now but that belies just how much investment and work he has and is continually putting into it. |
|
|
|
|
Show Posts
