loshia
Legendary
Offline
Activity: 1610
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 10, 2013, 03:55:55 PM |
|
Thank you Kano! I will find my way to hack around miner.php:)
|
|
|
|
FreshJR
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 65
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 14, 2013, 07:48:48 PM |
|
Sometimes my GPU crashes, and CGminer will either say DEAD, or be stuck on my last hash rate.
Is there anyway we can get a hypervisor type of program, where if CGminer stops updating its hash rate, or if it says DEAD, CGminer could be automatically closed and restarted?
It doesn't even have to monitor CGminer, if my GPU temp falls below 60*C, thats reason enough to restart CGMiner.
|
|
|
|
amigaman
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 15, 2013, 12:55:40 PM |
|
@FreshJr: I had a similar problem. My simple solution was to add a planned task in windows, executed 1h after the automatic winupdate, having the shutdown command. So my machine updates every night, then reboots. Since then (almost 8 weeks now) no problems with hanging CGM for more than a few hours, without any touching of the machines. I had a hang sometimes, needed to plug monitor and keyboard, try to restart, notice restarting CGM did nothing (maybe opencl hung), restart the machine. On weekends i often had one (problematic) machine often stop shortly after i was on holiday, missed almost 2 1/2 days of work. Now, the h, and no intervention needed. The place where my machines (4x 2x7970) work has a unstable DSL, it sometimes reconnects 12 times a day, sometimes only 1. I have 4 pools in failsafe mode, 98% of all shares go to pool 1, but sometimes even pool 4 gets some shares (0,25 BTC since Dec. 1 ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) )
|
|
|
|
mining4fun11
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 110
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 18, 2013, 05:57:11 PM |
|
With multiple modminers, I can't view all of my devices on cgminer as it shows each fpga on a line. This causes to many lines and I can't see every device. Are you able to consolidate it back to where each board has a line.
|
|
|
|
kano
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 18, 2013, 10:31:04 PM |
|
With multiple modminers, I can't view all of my devices on cgminer as it shows each fpga on a line. This causes to many lines and I can't see every device. Are you able to consolidate it back to where each board has a line.
No, because the original consolidated code meant that the (almost) independent boards were not independent and were not storing independent data for each board and some commands and failures would affect all 4 boards unnecessarily and independent data details were being consolidated (and the independence lost). It's best to think of an MMQ as 4 Ztex boards. However, the only thing shared is the USB MCU, which is resolved (shared) by locked access to it. Or even like a BFL MiniRig - again, one physical device, but multiple independent devices in cgminer, with locked (shared) access to the USB When I rewrote the MMQ code, I made them 4 independent devices with only one common thing, shared, locked access to the USB MCU. If you have too many devices on the screen there are 3 things to try: 1) make your terminal windows bigger 2) use --compact 3) use the RPC API to view the full details of all devices (e.g. with miner.php or other such API interfaces)
|
|
|
|
zvs
Legendary
Offline
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 19, 2013, 07:25:27 PM |
|
Is there any support for the x6500 with cgminer? I know bfgminer has it but I really prefer cgminer. Why do you prefer cgminer? I have been using it since I started mining. I don't follow; why is that a reason to prefer it? If there is something cgminer does that BFGMiner doesn't, that you find value in, I'd prefer to add it to BFGMiner. does bfgminer actually restart dead gpus? and i hate having to edit cfg files to fix fan speeds, what is up with the 85 max anyway, he's always used cgminer, that's why he prefers it. i used phoenix with phoenix rising until about 2 weeks ago
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 19, 2013, 07:48:54 PM |
|
does bfgminer actually restart dead gpus? I presume so. I've never seen a dead GPU that doesn't also crash the entire system, so I'm not really sure how to test this to make sure it still works. and i hate having to edit cfg files to fix fan speeds, what is up with the 85 max Can you elaborate?
|
|
|
|
zvs
Legendary
Offline
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 19, 2013, 08:15:42 PM |
|
does bfgminer actually restart dead gpus? I presume so. I've never seen a dead GPU that doesn't also crash the entire system, so I'm not really sure how to test this to make sure it still works. and i hate having to edit cfg files to fix fan speeds, what is up with the 85 max Can you elaborate? Any changes vs cgminer in regard to restarting GPUs? I would say only about 1% of the time my computer also crashes on a GPU failure. That seems to occur w/ heat issues. I've had Windows blue screen and say something about how it was shutting down for the 'safety' of my system. Most of the time they just blink the screen and reset. cgminer says they're dead and it can't restart them, but it takes me about 5 seconds to press q and reload cgminer and the card starts fine. As for the fan thing, I know that's a setting you can change in the program, I just haven't bothered. It may be part of the 'powertune' thing. I just opened the cfg file and changed the 0-85 to 0. What I didn't expect was for it to put an 85% limit on my fans as part of a 'default' config. It shouldn't mess with my clock, memory, or fan settings at all. Just pool settings, intensity, etc.
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 19, 2013, 08:24:02 PM |
|
does bfgminer actually restart dead gpus? I presume so. I've never seen a dead GPU that doesn't also crash the entire system, so I'm not really sure how to test this to make sure it still works. and i hate having to edit cfg files to fix fan speeds, what is up with the 85 max Can you elaborate? Any changes vs cgminer in regard to restarting GPUs? I would say only about 1% of the time my computer also crashes on a GPU failure. That seems to occur w/ heat issues. I've had Windows blue screen and say something about how it was shutting down for the 'safety' of my system. Most of the time they just blink the screen and reset. cgminer says they're dead and it can't restart them, but it takes me about 5 seconds to press q and reload cgminer and the card starts fine. As for the fan thing, I know that's a setting you can change in the program, I just haven't bothered. It may be part of the 'powertune' thing. I just opened the cfg file and changed the 0-85 to 0. What I didn't expect was for it to put an 85% limit on my fans as part of a 'default' config. It shouldn't mess with my clock, memory, or fan settings at all. Just pool settings, intensity, etc. Yes, the whole "restart dead GPUs" code has been abstracted in BFGMiner so it works for other devices (eg FPGAs) as well. If there is a problem, I'd love to make sure it gets fixed, or at least be aware of it. If you don't use "auto-fan", BFGMiner shouldn't mess with them at all...?
|
|
|
|
|
zvs
Legendary
Offline
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 19, 2013, 09:22:44 PM |
|
So that makes BFGMiner vs CGMiner comparisons off-limits? Inferiority complex? How bizarre
|
|
|
|
os2sam
Legendary
Offline
Activity: 3582
Merit: 1094
Think for yourself
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 19, 2013, 09:26:33 PM |
|
So that makes BFGMiner vs CGMiner comparisons off-limits? Inferiority complex? How bizarre Haven't seen any comparisons, just you asking Luke-jr questions about bgfminer. How bizarre
|
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 19, 2013, 09:31:36 PM |
|
So that makes BFGMiner vs CGMiner comparisons off-limits? Inferiority complex? Feel free to make comparisons on the BFGMiner thread.
|
|
|
|
kano
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 19, 2013, 11:57:11 PM |
|
So that makes BFGMiner vs CGMiner comparisons off-limits? Inferiority complex? Feel free to make comparisons on the BFGMiner thread. As stated clearly above, but I guess is beyond your feeble levels of understanding, there was no comparison, only questions about your clone which has lots of old outdated code for the non-GPU parts. Meanwhile, the GPU code is ckolivas. ... and now the FPGA code has been rewritten by me using direct USB (libusb) Though I haven't updated the Icarus driver code for libusb yet, but that driver code was mostly written by xiangfu and me anyway - and even your clone CM1 driver is from the Icarus code I wrote ... and I'd not at all be surprised if the clone x6500 code is based on the ZTex code that nelisky wrote ... But, the clone still uses, for most of the FPGA drivers, the old 1900's serial I/O code that Mr. Clone chose coz it was easy, not coz it was best (though there is code in there that I wrote also to fix problems and debug serial issues) Anyway, performance comparisons will of course be of great interest once ASIC devices come out ... ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Will Mr Clone actually be able to write some original important code, or will he just copy it from cgminer like he does all the time and then fudge minor code changes and claim his clone is the original ... Clone: Stratum code, copied from cgminer, Scrypt code, copied, GPU code, copied, pool & work scheduling, copied, API, copied, Icarus, BFL, Ztex, driver code, copied. Even the code that makes the CM1 work properly, copied. CGMiner only original code (mostly not copied to the clone): GBT, MMQ, USB driver libraries for all but Icarus (yeah I'll get around to redoing that for Icarus one day ...) Truly original (different) code in the clone? GBT - the currently suckyest work protocol on the planet - that still does nothing to secure anything. I wonder what a 'current' lines of code per programmer would show with cgminer? ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) I've no idea how to get that accurately ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) GitHub doesn't even show me for some of the reports ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) (yes I know why)
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 20, 2013, 01:42:09 PM Last edit: January 20, 2013, 01:56:34 PM by Luke-Jr |
|
... and now the FPGA code has been rewritten by me using direct USB (libusb) Yes, you've rewritten a lot (but not all) of the FPGA code in cgminer since you and con forked it from BFGMiner. However, your FUD about VCOM is just FUD (the VCOM interfaces are not "slowed down" in any way because they use standard file interfaces), and there is no reason to prefer libusb; in fact, I know of at least four reasons to prefer VCOM at this time: - libusb has no way to be used asynchronously on Windows; part of my original plan for ASICs was to move to a few-threaded model (BFGMiner has already a single async share submission thread) to improve scalability. I still plan to do that, but libusb-based drivers are going to force me to "hold it back" a bit.
- VCOM has a user-friendly interface for devices: COM port numbers. This allows users to easily manage which devices are enabled or not, even if they don't have unique serial numbers (such as BFL FPGAs)
- There is no guarantees that the USB interface for any given FPGA/ASIC is set and unchanging. It is possible a vendor could change the USB chip in their ASIC/FPGA to another brand to avoid shipping delays, for example. While there is a standard for USB VCOM interfaces (USB CDC), only the MMQ has ever used it by having a mostly-CPU-controlled USB interface on the device. All the "ready to go" USB VCOM chips use their own incompatible interfaces; your libusb-based code will fail on anything changing here!
- VCOM drivers, at least for FTDI, are installed automatically by most operating systems. While libusb for Linux allows us to tell the OS to "steal" the device from the VCOM driver, doing so on Windows requires the user to manually change to the libusb driver.
Though I haven't updated the Icarus driver code for libusb yet, but that driver code was mostly written by xiangfu and me anyway - and even your clone CM1 driver is from the Icarus code I wrote ... and I'd not at all be surprised if the clone x6500 code is based on the ZTex code that nelisky wrote ... While admittedly you have made some contributions to the Icarus driver, you can only claim to take as much credit as you do because you have since forked the driver originally developed by xiangfu while FPGA code was maintained by myself (thus part of what is now BFGMiner). BFGMiner's Cairnsmore1 driver is 100% my own efforts, and only "based on" your code to the extent that it doesn't conflict with it. While I have heard that Ztex and X6500 share some common logic, I am still unfortunately not familiar enough with nelisky's "libztex" code to have ensured they share common code where appropriate; instead, I implemented JTAG and FT232R bitbanging mode in their own semi-isolated modules from scratch. Perhaps someday, I will have time to integrate the Ztex driver in with these better as appropriate, but as I lack the 1.15a/b/c/d models, I am hesitant to make major internal changes I cannot test. Clone: Stratum code, copied from cgminer, Scrypt code, copied, GPU code, copied, pool & work scheduling, copied, API, copied, Icarus, BFL, Ztex, driver code, copied. Even the code that makes the CM1 work properly, copied. More FUD and lies again, kano? Let's try a table: Code | BFGMiner | cgminer | Scrypt | Copied, known bugs | Original | getwork | Copied | Original | GBT | Original | Original, known bugs | Stratum | Copied, plus many bugfixes because of problems | Original | Share submission and stale detection | Original | Original | RPC API | Copied, useless "features" hidden | Original | Device driver interface | Original | Copied | BFL driver | Original | Copied, about-to-be heavily modified | CM1 driver | Original | Non-existent | Icarus driver | Original | Copied, heavily modified and known buggy | ModMiner driver | Original | Copied, heavily modified | OpenCL driver | Copied, with minor low-level improvements | Original | X6500 driver | Original | Non-existent | Ztex driver | Original | Copied | VCOM USB interfaces | OS-provided | Custom | (Yeah, there's other stuff I left out, but I was only trying to cover the actual topics you mentioned in your FUD.)
|
|
|
|
kano
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 20, 2013, 01:49:56 PM |
|
kanoi lulz at the amount of bullshit in the previous post ...
|
|
|
|
nathanrees19
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 20, 2013, 01:56:16 PM |
|
- There is no guarantees that the USB interface for any given FPGA/ASIC is set and unchanging. It is possible a vendor could change the USB chip in their ASIC/FPGA to another brand to avoid shipping delays, for example.
In practice, this happens approximately never.
|
|
|
|
kano
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 20, 2013, 02:58:28 PM |
|
Firstly note, I'll only waste my time doing this with one source file rather than spending hours sorting through it all. This one shows so well how much bullshit his post it. So ... I just now git cloned his clone miner to a directory on my computer git clone https://github.com/luke-jr/bfgminer.git and then ran this command: git blame driver-icarus.c | perl -n -e '/\s\((.*?)\s[0-9]{4}/ && print "$1\n"' | sort -f | uniq -c -w3 and the clone result right now (that anyone can run if they like) is 5 ckolivas 10 Con Kolivas 526 Kano 381 Luke Dashjr 175 Xiangfu
and in my cgminer git 5 ckolivas 18 Con Kolivas 698 Kano 8 Luke Dashjr 3 Paul Sheppard 180 Xiangfu
The main changes to the clone code he copied from me (why it says he wrote more than 8 lines in the clone, but still less than me) are CM1 code They're not in the cgminer version, the cgminer version only supports a CM1 with an Icarus bitstream and no extra CM1 commands that aren't necessary anyway - but the work division, fpga count, baud rate and timing code necessary for the CM1 were written by me. I'll also point out that there is a file in his git called icarus-common.h that says he wrote every line - but of course I wrote most of the code in there.
|
|
|
|
kano
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 21, 2013, 02:35:09 AM Last edit: January 21, 2013, 03:30:56 AM by kano |
|
A corrected update (all able to be proven by checking git) of Luke-Jr's attempt to yet again claim other people's work as his own. The guy is indeed scum of the earth. Code | BFGMiner | cgminer | Scrypt | Copied, known bugs | Original | getwork | Copied | Original | GBT | Original | Original, known bugsOne reported possible bug | Stratum | Copied, plus many bugfixes because of problemsproblems in his clone, not cgminer | Original | Share submission and stale detection | OriginalCopied, modified, with the share submission code recently done by Kano and ckolivas also copied | Original | RPC API | Copied, useless "features" hidden | Original | Device driver interface | Original | CopiedOriginally committed to cgminer now much modified | BFL driver | OriginalCopied | Copied, Originally committed to cgminer then heavily modified and about-to-be heavily modified again | CM1 driver | OriginalCopied (and modified) from Kano's Icarus code | Non-existent | Icarus driver | OriginalMostly Kano's Icarus code | Copied, heavily modified and known buggyOriginal - Xiangfu's original cgminer code heavily modified by Kano | ModMiner driver | Original | Copied, heavily modified and his cgminer version didn't even work until it was modified by Kano! | OpenCL driver | Copied, with minor low-level improvements | Original | X6500 driver | Original | Non-existent | Ztex driver | OriginalCopied | CopiedOriginal | VCOM USB interfaces | OS-provided with performance problems and reported device sharing problems | Custom |
Edit: and just to repeat ... the file icarus_common.h in his git that claims he wrote it all is mostly written by me and taken out of driver-icarus.c as you can prove by checking driver-icarus.c (or earlier versions depending on which git) ... Edit2: and in case anyone was thinking that was a once off ... driver-cairnsmore.c also include some amount of code I wrote and is attributed to him in his git.
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 21, 2013, 04:07:03 AM |
|
Ignoring Kano's lies... here's an example of how cgminer corrupts shares:
2013-01-21 03:58:19,492 JSONRPCHandler ERROR Error during JSON-RPC call (UA= b'cgminer 2.10.4', IP=::ffff:94.126.178.1): doJSON_submitblock['0200029c37a0ed5 1c08f04a41ff31b95581438905341a3330bcfc50b129051afc3ea4a420&w0000000100000000000 00000000000000000000000000000000000000000000000000000ffffffe52e15d40d233bcdb5ea bcb610800000000000000002f503253482f00eb710000ffffffff2058790c04000000001976a914 b9a295c6d524539bc1697c88b5924e0ca93e804b88acfc490aa2f3e1e0eb5dbe230141dcc6d55d4 dbbebff388acd9471404000000001976a9144099b9412742931608242dd3dfe14f339a2664e988a c6b681d04000000001976a9141b8a3702070457f7acf88acebb80704000000001976a91452e1efd 5379f772621ebf578ebd7bc33dc48a33d88acdc770104000000001976a9148d8a9e208fcac0ad56 6b7507719e6e8699e72e3f88ac4facbf559b9d1f02508a448e28891395d8a143f26fb88ac8c9201 04000000001976a914572265f6ea74c123d20a37fb10fb3abebb56dbf688ac39026b04000000001 976a9147487fe51c0a63ae9bb788acf7e20e04000000001976a9146ad47e26a21e5c5521b76eb11 a3378d5528a436988acf2376e04000000001976a914e971351d1df56266005b1a79cb1b91282fd2 13ae88aca141fed5b3bffd76ecc742257286befccf4a561ac6788acc68d2a05000000001976a914 6f319511eff679bf972518d810cab0532df9200388ac83df6a04000000001976a9143dfcf9866eb d3c98b6888acc6256105000000001976a91494e5178f3cfc56b77f9f1c508b74ed9ff3b558ad88a c11eaa404000000001976a9144ebf00154078a5ee78599adb4a82ce3b75709f5688aa91403d984b 4a0f1251370a86abb66ddaa61f67bb2bc88ac4b777807000000001976a9149465fdac29b5c47b99 c8d17379d0fc6d99c1e4a688ac849b2a08000000001976a9143f0c4ffe8626e3705ca88ac8993a8 04000000001976a914365fb3bc7793c8ffde2eccf0e0db7076a8fcc5b388ac27fb3304000000001 976a91444fae3395cdfbca7b8fcd7ab8d97f0e58bdb7beb876a9146ba1807121fdcb390db917b4c e84b0dc8e70883e88ace0fd1c00000000001976a9145399c3093d31e4b0af4be1215d59b857b861 ad5d88ac00000000', {}] Traceback (most recent call last): File "/home/bitcoinpool/eloipool/jsonrpcserver.py", line 200, in _doJSON_i rv = getattr(self, method)(*params) File "/home/bitcoinpool/eloipool/jsonrpc_getmemorypool.py", line 85, in doJSON_submitblock data = bytes.fromhex(data) ValueError: non-hexadecimal number found in fromhex() arg at position 162
|
|
|
|
|