bfgminer version 2.99.2 - Started: [2013-03-30 23:37:17] - [ 0 days 00:01:57
------------------------------------------------------------------------------
5s:17.85 avg:16.58 u:14.26 Gh/s | A:342 R:0 S:0 HW:0 U:179.6/m
ST: 2 DW: 10 GW: 3 LW: 494 GF: 0 NB: 1 AS: 0 RF: 0 E: 2.08
Connected to 192.168.1.1 diff 8 with stratum as user test
Block: ...ee2e8a72 #3123 Diff:153 Started: [23:37:17] Best share: 528
------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
BFL 0: 45.0C | 17.83/17.52/14.58Gh/s | A:343 R:0 HW:0 U:180.16/m
------------------------------------------------------------------------------
[2013-03-30 23:38:52] Stratum from pool 0 requested work update
[2013-03-30 23:38:52] Accepted 0ecf365f BFL 0 Diff 17/1
[2013-03-30 23:38:53] Accepted a91d942c BFL 0 Diff 1/1
[2013-03-30 23:38:53] Accepted 15d55ee2 BFL 0 Diff 11/1
[2013-03-30 23:38:53] Accepted be2972c6 BFL 0 Diff 1/1
[2013-03-30 23:38:53] Accepted 9e87d2fd BFL 0 Diff 1/1
[2013-03-30 23:38:53] Accepted 7f854200 BFL 0 Diff 2/1
[2013-03-30 23:38:54] Accepted 03c5d641 BFL 0 Diff 67/8
[2013-03-30 23:39:08] Accepted 040aab96 BFL 0 Diff 63/8
[2013-03-30 23:39:09] Accepted 14997fe3 BFL 0 Diff 12/8
[2013-03-30 23:39:10] Accepted 123ded4b BFL 0 Diff 14/8
[2013-03-30 23:39:11] Accepted 0453e37f BFL 0 Diff 59/8
[2013-03-30 23:39:14] Accepted 06bd2321 BFL 0 Diff 37/8 |
|
|
|
Alright enough. STFU. If any other miner software was posting in the CGMiner thread about how the author thought their software was better, they would get a shitstorm up the ass. If Diablo, ufasoft, M0mchil, or Jedi95 was in here saying their miner was better than CGMiner, they would get their posts removed. Yet somehow because your program was forked from CGMiner, you get these special privileges. From now on, I will reporting any post by LJR in the CGMiner thread to the mods. I suggest everyone else to do the same. Cool story bro. |
|
|
|
Correct, devices that hash ~5s or slower per nonce range indeed do not show a very reliable value for a 5s average ... since that really is what to expect if you think about the mathematics of it  Your reasoning sounds valid, but this is a bug that didn't exist in a previous version. How is that not a regression? I am always using the latest git version, and at least for now, reverting commit 072ffbba424770afcbd2e1a10aead8a5035f80de returns the old (correct) 5s hashrate average for slow devices. I intentionally did not merge this regression into BFGMiner. |
|
|
|
what can trigger this error ? 2013-03-29 19:49:56,743 StratumHandler DEBUG Traceback (most recent call last):
File "xxxxxxxxxxxxxxxxxxxxxxxxstratumserver.py", line 91, in found_terminator
rv = getattr(self, funcname)(*rpc['params'])
TypeError: _stratum_mining_subscribe() takes exactly 1 positional argument (2 given)
2013-03-29 19:49:56,805 StratumHandler DEBUG Traceback (most recent call last):
File "xxxxxxxxxxxxxxxxxxxxxstratumserver.py", line 91, in found_terminator
rv = getattr(self, funcname)(*rpc['params'])
is this version bitcoind 0.8.1 eligious branch is ok from git clone git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git ? Ignore it for now. |
|
|
|
The pool balancing options were written in cgminer - they were just copied to the clone here.
Ignore the troll
Were the pool balancing options written by you, or by the CGMiner team? If the latter, then he has a point, and he's not trolling. Nice try removing the rest of kano's troll. The pool balancing stuff was written by Con Kolivas, including all the bugs which CrazyBlane is concerned about. On that note, I think it's detrimental to the community that you guys are arguing in each others release threads. Personally, I'd like to see you guys working on the same branch. If that's not going to happen, why don't you just leave each other alone? I proposed a truce to Kano a month or two ago, that if he stopped trolling and FUD all over BFGMiner, I'd just ignore cgminer. He flatly refused. |
|
|
|
How difficult would it be to implement the ability to tie a pool to a specific mining device?(Using backup pools as failiver only for each device) Probably not too difficult, but it'll be a lot easier when I get to rewriting the work-fetching interfaces to be cleaner. My concern is the unreliable load distribution using the various load balancing switches. An unproportionate amount of hashing power given to a pool that's having issues or underperforming could result in a huge loss in mining profit for the day. With ASICs rolling out in mass quantities soon, I predict pool issues are going to climb dramatically. Hmm, you may be right about older pools suffering more from ASICs. Already Deepbit is having trouble keeping up with some faster FPGA farms. I would recommend picking a couple of pools known to manage with ASIC-like loads to use - pretty much anything with vardiff and (GBT or stratum) should do the job. Personally, I prefer and recommend Eligius. Besides having originally started the pool, I also maintain the software that keeps it going, and have seen it tested with plenty of hashrate. |
|
|
|
By the way, and this is totally unrelated, is it possible to use Eloipool to run a TRC pool? I don't know what TRC is. Try it and see? Honestly, I don't really know how to set up a pool. I'm a programmer, but I haven't found much information out there. If you could point me to a resource, that'd be awesome. |
|
|
|
While I agree that using direct USB is probably better overall, Then we have no argument here! You're agreeing with kano! Come on, context! Devices talking to mining software with raw/direct USB, is probably better than using a serial interface. But it's still more sensible to use the standard interface/drivers when they're implementing the protocol with serial! By the way, and this is totally unrelated, is it possible to use Eloipool to run a TRC pool? I don't know what TRC is. Try it and see? |
|
|
|
USB does, yes. But not the devices in question.
If that's the case, then I suppose I see no real benefit to using libusb either. cgminer already implements functionality that uses the advantages of libusb The most obvious one is hotplug. I have implemented it within the main cgminer code and the usbutils code, without need for the drivers to handle it directly. Thus all current usbutils drivers (MMQ and BFL) and all new drivers will already have hotplug. This is not a libusb feature. In fact, libusb explicitly does not support hotplugging itself! You are merely scanning all devices poll-style every so often. That can be done just as well with the standard serial interfaces (Ufasoft has done it since BitFORCE FPGAs were originally released), but is the wrong way to do hotplug and breaks a number of assumptions in the original code that BFG and cg today are based on. Another is the 'cgminer -n' function - it will list all known libusb mining devices without each driver having to do any actual hashing on the devices or sending commands to the devices. It does exactly what the -d? option has done since I created the device API interface in 2.2.0. How is this redundancy somehow libusb-specific? Another is the usb API stats
All devices have statistics recorded about all I/O to them, including the initial control transfers that the serial-USB code doesn't even know about Yes, this is made possible using libusb. Too bad it's completely useless. ... and of course, if any manufacturer does implement a much better device that uses the clear advantages of direct USB, cgminer will already have most of the code necessary to support it, tested and been run already for months right now. While I agree that using direct USB is probably better overall, there is nothing special about your libusb code in cgminer. BFGMiner also uses libusb, just only when it's the right interface for the job. ZTEX and X6500 use direct USB interfaces. The reality is, there isn't any generic "code necessary to support" direct USB (outside of what libusb itself provides) - just "Kano's pointless reinvention of the standard serial-USB interface". |
|
|
|
I'm glad to report that I have been added as a new admin! What a shame. Given your explicit intention to abuse power, I fear this may result in a need to fork the wiki. Too bad the Foundation seems to not be giving due diligence to its decisions. Edit: Obviously I'm going to try to work with ripper234 in the meantime, but he has thus far proven unwilling to collaborate fairly. |
|
|
|
Wait, you just said that it was the current, supported, standard interface, and libusb is low level. Then you said libusb adds a lot of abstraction and does the same things as the serial I/O libs, which would make it higher level. Which is it?
Both. For the network analogy, libusb would be libpcap - it adds some programmer-friendly abstractions on top of a raw socket. It's still working with low-level raw sockets, but in an abstracted way. If we're using that analogy, then the serial I/O libs would be the regular TCP/IP stack. Right... And libpcap is still faster and offers more functionality than the TCP/IP stack, it doesn't reimplement too much. Even if you implement your own TCP/IP stack on top of it? But it's nothing like that. USB provides a lot more than serial transfers, as kano said. So it's not a reimplementation. USB does, yes. But not the devices in question. |
|
|
|
The correct solution is to implement the sweep function, and make that easily accessible. Ok, so ignoring smaller previous pull requests that could be the start of such feature is a solution? I remind you that Bitcoin is still beta software. But it isn't the start of such a feature. It's the end. The start needs to come before the end. I agree this would be nice (in some form), but the filtering is inevitably a political move to try to force others to stop reusing addresses. While I think that may be necessary, it's arguable whether it belongs in the reference client. Oh no, not again. The feature is there waiting for an approval that never comes. WTF? I refuse to fork or join or split or whatever. The code is there waiting for what? Main developers mercy?The point is that people are not supposed to be reusing addresses in the first place, which would make the filter useless. You are granting people "main developers" status. Don't complain about authority you give people - if you don't like it, don't give them that authority. But in the end, the decisions you're talking about here have reasons behind them. Ignoring those reasons isn't the best idea. Pardon me, but people have authority when things get done through them, or not? So if someone decides over a matter you imply they don't have any authority. I respect Gavin and team for this and because they reached there with allot of hard work and learning, but I don't agree with their "nanny" attitude towards bitcoiners. Hope I make myself understood and you don't beat the subject around the bush. Nobody is deciding this for you, except yourself. If you choose to go with Gavin or someone else's decision, that is still your choice to do so. You can just as easily decide to ignore Gavin on this, and merge the branches yourself, as everyone has been trying to tell you. I enjoy only using Bitcoin-qt, this way my coins are safe and I help the network because other implementations aren't even considering this issue. People create features and submit them to Bitcoin mainstream client, where main developers actually get "free lunch" and only have to merge those. What you don't understand from that? They have a long record of not accepting even minor changes and leaving them rot on Github. This puts off people wanting to help or develop new features more every day.
As you probably understand main developers consolidate their position by doing this, assuring no one has any significant contribution towards the reference client, so we depend on them for whatever minor feature we need or want. Yes, there is a problem with getting things merged. But this problem mostly comes down to testing. You can "fix" it by skipping testing, or getting more people available to test. Only the latter is acceptable to Gavin, and for good reason. Don't give me that "testing" crap, you know very well the same thing we're discussing here happened to you and many other people. Testing is non-issue when you've already tested all known cases. Unknown are to be discovered, just like the recent database fork that even Satoshi himself couldn't foresee. Satoshi isn't a god. Testing is the main issue. One person testing is not sufficient, no matter what the change is. Some of my oldest outstanding pull requests have had months of testing on Eligius and other pools now, but I can accept that they really need unit tests to truly prove themselves. |
|
|
|
Too dangerous for easy access - do you really want to enable people coins from newbies? Power users can already import private keys using the debug console. What? Please listen to yourself. The answer is yes, people can and will take care for themselves.I was missing a word: "stealing". Importing private keys that others might have makes you vulnerable to theft. Newbies could easily be fooled into this kind of an attack. Advanced users can still do it via the debug console. The correct solution is to implement the sweep function, and make that easily accessible. I agree this would be nice (in some form), but the filtering is inevitably a political move to try to force others to stop reusing addresses. While I think that may be necessary, it's arguable whether it belongs in the reference client. Oh no, not again. The feature is there waiting for an approval that never comes. WTF? I refuse to fork or join or split or whatever. The code is there waiting for what? Main developers mercy?The point is that people are not supposed to be reusing addresses in the first place, which would make the filter useless. You are granting people "main developers" status. Don't complain about authority you give people - if you don't like it, don't give them that authority. But in the end, the decisions you're talking about here have reasons behind them. Ignoring those reasons isn't the best idea. I enjoy only using Bitcoin-qt, this way my coins are safe and I help the network because other implementations aren't even considering this issue. People create features and submit them to Bitcoin mainstream client, where main developers actually get "free lunch" and only have to merge those. What you don't understand from that? They have a long record of not accepting even minor changes and leaving them rot on Github. This puts off people wanting to help or develop new features more every day.
As you probably understand main developers consolidate their position by doing this, assuring no one has any significant contribution towards the reference client, so we depend on them for whatever minor feature we need or want. Yes, there is a problem with getting things merged. But this problem mostly comes down to testing. You can "fix" it by skipping testing, or getting more people available to test. Only the latter is acceptable to Gavin, and for good reason. |
|
|
|
To Bitcoin developers,
Who do you think you are to decide what's good or bad for us?
Why are you treating bitcoiners like a "nanny-government"?
Why do you stall for months patches and features to the reference client that are useful to all of us? Oh please... For a popular feature, nobody was willing to take the effort required to address problems with it, until very recently (too late for 0.8). Hopefully it will make it into 0.9. Too short-sighted. sipa and CodeShark have been working on true multi-wallet support for a while, and that will hopefully be ready for 0.9. Too dangerous for easy access - do you really want to enable people stealing coins from newbies? Power users can already import private keys using the debug console. I agree this would be nice (in some form), but the filtering is inevitably a political move to try to force others to stop reusing addresses. While I think that may be necessary, it's arguable whether it belongs in the reference client.
Sounds like I need to get around to spinning a 0.8-based next-test release, though... |
|
|
|
Wait, you just said that it was the current, supported, standard interface, and libusb is low level. Then you said libusb adds a lot of abstraction and does the same things as the serial I/O libs, which would make it higher level. Which is it?
Both. For the network analogy, libusb would be libpcap - it adds some programmer-friendly abstractions on top of a raw socket. It's still working with low-level raw sockets, but in an abstracted way. If we're using that analogy, then the serial I/O libs would be the regular TCP/IP stack. Right... And libpcap is still faster and offers more functionality than the TCP/IP stack, it doesn't reimplement too much. Even if you implement your own TCP/IP stack on top of it? |
|
|
|
That's no reason to continue using deprecated technology. CGMiner could also be a 16-bit binary. You missed the point. CGMiner is also deprecated software for deprecated technology (GPUs). Well, if you consider the fact that shortly, when indeed GPU mining will be deprecated, that the crappy clone will ONLY be using the old termios serial IO libraries that were designed around 30 or more years ago, meanwhile, cgminer has been updated to use the libusb library to talk directly to the USB devices rather than via the old serial libraries that put an old interface in front of the USB devices and restrict access to most of the USB functionality ... yes it's quite clear that the clone is old technology and written using the serial library because the guy who wrote it was not only fail in programming ability he chose the simplest interface with the most restrictions coz he had no idea what he was doing ... You mean the current, supported, standard interface, instead of bypassing it to use a low-level interface that has no benefit whatsoever. It's like writing your own TCP/IP stack instead of using the one included in the OS. Not only is it stupidly redundant, it also means you've lost support, driver updates, ease of use, forward compatibility with new hardware, and regular-user-mode access. Speed might be a reason to use libusb rather than 30 year old serial I/O libs... Just saying... If Kano's lies were true, perhaps. But "30 year old serial I/O libs" is not quite right. While the interface may be 30 years old, the code behind it certainly isn't. Nor is there any need for a new interface. It's also a "library" builtin to the OS itself, so pretty much as little overhead as you can get. On the other hand, libusb is designed for raw USB access, and non-native on at least Windows. But it does add a lot of abstraction which theoretically harms performance. It then goes and does the same things as the "30 year old serial I/O libs" using a non-standard interface. libusb is nice when there are no existing drivers, but totally the wrong tool for these specific devices. Unfortunately, libusb also lacks any support for asynchronous access on Windows too, which makes some device API improvements impractical - before I can move BFGMiner to a completely asynchronous model, I would need to first do some major improvements to the underlying libusb library itself. Edit: Disclosure... there is one reason I can see using libusb could be beneficial: unfixed bugs in the OS/official OS drivers, or workarounds for buggy hardware. This is the case with Windows's ACM driver (used by ModMiner) - but easily worked around in software (as BFGMiner has done for a while). The chip used in the Icarus also had a bug that prevented it from working with certain USB hosts - this too, was easily worked around in software. But those are the only reasons I can see using libusb would make sense for a device using a serial interface, and they're already managed just fine without it. Wait, you just said that it was the current, supported, standard interface, and libusb is low level. Then you said libusb adds a lot of abstraction and does the same things as the serial I/O libs, which would make it higher level. Which is it? Both. For the network analogy, libusb would be libpcap - it adds some programmer-friendly abstractions on top of a raw socket. It's still working with low-level raw sockets, but in an abstracted way. |
|
|
|
That's no reason to continue using deprecated technology. CGMiner could also be a 16-bit binary. You missed the point. CGMiner is also deprecated software for deprecated technology (GPUs). Well, if you consider the fact that shortly, when indeed GPU mining will be deprecated, that the crappy clone will ONLY be using the old termios serial IO libraries that were designed around 30 or more years ago, meanwhile, cgminer has been updated to use the libusb library to talk directly to the USB devices rather than via the old serial libraries that put an old interface in front of the USB devices and restrict access to most of the USB functionality ... yes it's quite clear that the clone is old technology and written using the serial library because the guy who wrote it was not only fail in programming ability he chose the simplest interface with the most restrictions coz he had no idea what he was doing ... You mean the current, supported, standard interface, instead of bypassing it to use a low-level interface that has no benefit whatsoever. It's like writing your own TCP/IP stack instead of using the one included in the OS. Not only is it stupidly redundant, it also means you've lost support, driver updates, ease of use, forward compatibility with new hardware, and regular-user-mode access. Speed might be a reason to use libusb rather than 30 year old serial I/O libs... Just saying... If Kano's lies were true, perhaps. But "30 year old serial I/O libs" is not quite right. While the interface may be 30 years old, the code behind it certainly isn't. Nor is there any need for a new interface. It's also a "library" builtin to the OS itself, so pretty much as little overhead as you can get. On the other hand, libusb is designed for raw USB access, and non-native on at least Windows. But it does add a lot of abstraction which theoretically harms performance. It then goes and does the same things as the "30 year old serial I/O libs" using a non-standard interface. libusb is nice when there are no existing drivers, but totally the wrong tool for these specific devices. Unfortunately, libusb also lacks any support for asynchronous access on Windows too, which makes some device API improvements impractical - before I can move BFGMiner to a completely asynchronous model, I would need to first do some major improvements to the underlying libusb library itself. Edit: Disclosure... there is one reason I can see using libusb could be beneficial: unfixed bugs in the OS/official OS drivers, or workarounds for buggy hardware. This is the case with Windows's ACM driver (used by ModMiner) - but easily worked around in software (as BFGMiner has done for a while). The chip used in the Icarus also had a bug that prevented it from working with certain USB hosts - this too, was easily worked around in software. But those are the only reasons I can see using libusb would make sense for a device using a serial interface, and they're already managed just fine without it. |
|
|
|
That's no reason to continue using deprecated technology. CGMiner could also be a 16-bit binary. You missed the point. CGMiner is also deprecated software for deprecated technology (GPUs). Well, if you consider the fact that shortly, when indeed GPU mining will be deprecated, that the crappy clone will ONLY be using the old termios serial IO libraries that were designed around 30 or more years ago, meanwhile, cgminer has been updated to use the libusb library to talk directly to the USB devices rather than via the old serial libraries that put an old interface in front of the USB devices and restrict access to most of the USB functionality ... yes it's quite clear that the clone is old technology and written using the serial library because the guy who wrote it was not only fail in programming ability he chose the simplest interface with the most restrictions coz he had no idea what he was doing ... You mean the current, supported, standard interface, instead of bypassing it to use a low-level interface that has no benefit whatsoever. It's like writing your own TCP/IP stack instead of using the one included in the OS. Not only is it stupidly redundant, it also means you've lost support, driver updates, ease of use, forward compatibility with new hardware, and regular-user-mode access. |
|
|
|
That's no reason to continue using deprecated technology. CGMiner could also be a 16-bit binary. You missed the point. CGMiner is also deprecated software for deprecated technology (GPUs). |
|
|
|
|
Show Posts
