Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
November 17, 2012, 03:08:01 AM |
|
I'm thinking that the dynamic clocking of 2.9.2 and 2.9.3 (using the older bitstream doesn't help, still getting SICK and DEAD later on) is probably more aggressive compared to 2.9.0 and 2.9.1. I don't think SICK/DEAD can be caused by the bitstream or dynclock code. This is something around the FT232R chip; unfortunately, the only change in this that I recall between 2.9.1 and 2.9.2 was a memory corruption bug. There were no changes to the dynamic clocking besides the default frequency.
|
|
|
|
vitruvio
|
|
November 17, 2012, 01:28:02 PM |
|
Stats with --scrypt param still wrong for me in 2.9.3. Is there an issue for this open on GitHub? I download Windows version already comipiled, so nothing to try or check until next w32 binary release. Regards
|
|
|
|
purelithium
|
|
November 17, 2012, 03:33:27 PM |
|
vitruvio, if you have a problem, you need to open an issue in github so the devs can troubleshoot it, as that is most likely where they look for the active issues when they are coding, rather than scouring forum threads.
|
Like my post? 1H7bfRYh7F89mfmFgsRCdn4awDaUHQmYqY
|
|
|
vitruvio
|
|
November 17, 2012, 03:57:15 PM |
|
vitruvio, if you have a problem, you need to open an issue in github so the devs can troubleshoot it, as that is most likely where they look for the active issues when they are coding, rather than scouring forum threads.
I will. Regards
|
|
|
|
JakeTri
|
|
November 18, 2012, 04:40:25 PM |
|
Using latest win32 builds for bfgminer I start seeing virus warnings: Here is the warning for 2.8.6 build: and here is the one for 2.9.3: I do not see any virus warning with previous versions. Last warning that I remember was long time ago and it was about the pdcurses.dll. Thanks, Jake
|
BTC donations always welcome: 1JakeTriwbahMYp1rSfJbTn7Afd1w62p2q
|
|
|
K1773R
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
|
November 18, 2012, 04:47:00 PM |
|
Using latest win32 builds for bfgminer I start seeing virus warnings: Here is the warning for 2.8.6 build: and here is the one for 2.9.3: I do not see any virus warning with previous versions. Last warning that I remember was long time ago and it was about the pdcurses.dll. Thanks, Jake pls just stfu... we dont need AV spam here seriously!
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
JakeTri
|
|
November 18, 2012, 04:59:31 PM |
|
Using latest win32 builds for bfgminer I start seeing virus warnings:
Here is the warning for 2.8.6 build: ... and here is the one for 2.9.3: ...
I do not see any virus warning with previous versions. Last warning that I remember was long time ago and it was about the pdcurses.dll.
Thanks, Jake
pls just stfu... we dont need AV spam here seriously! I see this as a possible major issue if the AV warning prove to be valid ... Seriously! If you do not see it this way then please just ignore it.
|
BTC donations always welcome: 1JakeTriwbahMYp1rSfJbTn7Afd1w62p2q
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
November 18, 2012, 07:13:08 PM |
|
Using latest win32 builds for bfgminer I start seeing virus warnings: Here is the warning for 2.8.6 build: Please read the warning; I agree with it: "This is a potentially unwanted application. These are programs that computer users wish to be made aware of." It's not saying BFGMiner is a virus, merely that users should be aware it's installed. Since some viruses tend to bundle miner programs, this seems quite reasonable. I do not see any virus warning with previous versions. Last warning that I remember was long time ago and it was about the pdcurses.dll. Can you check again? If 2.8.5 really doesn't trigger this and 2.8.6 does, I imagine it should be easy to workaround.
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
November 18, 2012, 07:25:21 PM |
|
It's not saying BFGMiner is a virus, merely that users should be aware it's installed. Since some viruses tend to bundle miner programs, this seems quite reasonable. What exactly you and ckolivas are using which causes AV software to trigger alarms? Miners can't work without those components, or it's just .exe and .dll packing method? AV software looks for miners specifically.
|
|
|
|
JakeTri
|
|
November 18, 2012, 08:16:25 PM |
|
I do not see any virus warning with previous versions. Last warning that I remember was long time ago and it was about the pdcurses.dll. Can you check again? If 2.8.5 really doesn't trigger this and 2.8.6 does, I imagine it should be easy to workaround. Sorry I think I was just lucky and as you said ... I do not use much the windows version but today I was trying to check something (the stats issue with --scrypt) and I jumped from 2.6.6 to 2.9.3 / 2.8.6 and I notice the warnings. As you suggested I retested all versions from 2.8.0 to 2.8.6 and 2.9.0 to 2.9.3. See table below for the results ... Version | Test result | 2.6.6 | No Warnings | 2.8.0 | Same warning as 2.9.3 | 2.8.1 | Same warning as 2.9.3 | 2.8.2 | Same warning as 2.9.3 | 2.8.3 | New warning: "This is a known Trojan/Backdoor. It is recommended that you quarantine this threat." | 2.8.4 | Same warning as 2.9.3 | 2.8.5 | Same warning as 2.9.3 | 2.8.6 | Warning with full description | 2.9.0 | Same warning as 2.9.3 | 2.9.1 | Same warning as 2.9.3 | 2.9.2 | Same warning as 2.9.3 | 2.9.3 | Same warning as 2.9.3 |
AV software looks for miners specifically.
I think this fully explain the warnings... Sorry for the false alarm! Jake
|
BTC donations always welcome: 1JakeTriwbahMYp1rSfJbTn7Afd1w62p2q
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
November 18, 2012, 08:35:07 PM |
|
I do not see any virus warning with previous versions. Last warning that I remember was long time ago and it was about the pdcurses.dll. Can you check again? If 2.8.5 really doesn't trigger this and 2.8.6 does, I imagine it should be easy to workaround. Sorry I think I was just lucky and as you said ... I do not use much the windows version but today I was trying to check something (the stats issue with --scrypt) and I jumped from 2.6.6 to 2.9.3 / 2.8.6 and I notice the warnings. As you suggested I retested all versions from 2.8.0 to 2.8.6 and 2.9.0 to 2.9.3. See table below for the results ... Version | Test result | 2.6.6 | No Warnings | 2.8.0 | Same warning as 2.9.3 | 2.8.1 | Same warning as 2.9.3 | 2.8.2 | Same warning as 2.9.3 | 2.8.3 | New warning: "This is a known Trojan/Backdoor. It is recommended that you quarantine this threat." | 2.8.4 | Same warning as 2.9.3 | 2.8.5 | Same warning as 2.9.3 | 2.8.6 | Warning with full description | 2.9.0 | Same warning as 2.9.3 | 2.9.1 | Same warning as 2.9.3 | 2.9.2 | Same warning as 2.9.3 | 2.9.3 | Same warning as 2.9.3 |
Can you elaborate on the 3(?) different warnings more? Maybe also figure out which was the last/first version to raise the warnings?
|
|
|
|
JakeTri
|
|
November 19, 2012, 12:56:11 AM |
|
Can you elaborate on the 3(?) different warnings more? Maybe also figure out which was the last/first version to raise the warnings?
Luke, here is the full screenshot with the error on 2.8.3: I'll try to find some time tomorrow and check the last good / first bad version.
|
BTC donations always welcome: 1JakeTriwbahMYp1rSfJbTn7Afd1w62p2q
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
November 20, 2012, 06:58:29 PM |
|
can one run bfgminer in windows 8 using a *.bat file?
|
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
November 20, 2012, 08:17:15 PM |
|
can one run bfgminer in windows 8 using a *.bat file?
nvm, i guess you can.
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
November 21, 2012, 04:41:24 AM |
|
start "BFG Miner BFL" bfgminer.exe -c cgminer.conf -S bitforce:\\.\COM3 -S bitforce:\\.\COM4
|
|
|
|
mrb
Legendary
Offline
Activity: 1512
Merit: 1028
|
|
November 21, 2012, 10:43:24 AM |
|
Abstract: getblocktemplate more wasteful than getwork
As a solo miner, I switched one of my FPGA hosts to bfgminer 2.9.3 in order to mine with getblocktemplate against bitcoind 0.7.1. This particular host has 37 FPGA devices (mixture of bfl singles, cm1's, icarus's) and I notice that bfgminer is sub-optimal: every 2-3 minutes, it does about 20-40 getblocktemplate calls in a row (1 for each FPGA device?). These 20-40 getblocktemplate calls amount to about 3-4MB total. So on average, getblocktemplate generates about 1-2 MB of network traffic per minute.
On the other hand, when mining with getwork, these 37 FPGA devices amount to about 15 Ghash/sec, so it generates about 4 getwork calls per second, or about 600 kB/minute as measured by a packet sniffer.
Bottom line, getblocktemplate as it is implemented in bfgminer causes my host to generate more network traffic than getwork (but fewer RPC calls). I haven't taken the time to read the code yet, but, Luke, isn't there something trivial to optimize to reduce the number of getblocktemplate calls?
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
November 21, 2012, 10:50:25 AM |
|
mrb, seriously ... read: https://bitcointalk.org/index.php?topic=14085.msg1349123#msg1349123... and of course it is also way less traffic. I dunno what bugs Luke-Jr was talking about he has in bfgminer, that he was mentioning in the cgminer thread, but try it all with stratum and cgminer and see for yourself. Luke's already been told what the problems are with GBT and how to fix it but his response was along the lines of ... that's just an implementation issue ...
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
November 21, 2012, 01:00:46 PM |
|
Abstract: getblocktemplate more wasteful than getwork
As a solo miner, I switched one of my FPGA hosts to bfgminer 2.9.3 in order to mine with getblocktemplate against bitcoind 0.7.1. This particular host has 37 FPGA devices (mixture of bfl singles, cm1's, icarus's) and I notice that bfgminer is sub-optimal: every 2-3 minutes, it does about 20-40 getblocktemplate calls in a row (1 for each FPGA device?). These 20-40 getblocktemplate calls amount to about 3-4MB total. So on average, getblocktemplate generates about 1-2 MB of network traffic per minute.
On the other hand, when mining with getwork, these 37 FPGA devices amount to about 15 Ghash/sec, so it generates about 4 getwork calls per second, or about 600 kB/minute as measured by a packet sniffer.
Bottom line, getblocktemplate as it is implemented in bfgminer causes my host to generate more network traffic than getwork (but fewer RPC calls). I haven't taken the time to read the code yet, but, Luke, isn't there something trivial to optimize to reduce the number of getblocktemplate calls?
bitcoind is not intended for use of slow networks, and doesn't even attempt to minimize traffic. It also does not currently implement long-polling (though next-test has a patch to support it), so the template needs to be refreshed regularly in case of the old one being stale. As you note, above matters with bitcoind aside, bfgminer does not implement GBT optimally at this time, since it is using code originally built around getwork; cgminer has bypassed the getwork paths for its GBT support, but also intentionally designed the GBT path to use more bandwidth (conman wants to make GBT look bad). Rewriting the pool networking code in bfgminer has been on my todo list for a while (mainly due to other problematic bugs in it), and hopefully I'll get to that before 3.0. But even without it, each template is still able to scale per device, so the problem of ASICs hashing much faster is still dealt with in practice.
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
November 21, 2012, 01:37:27 PM |
|
Abstract: getblocktemplate more wasteful than getwork
As a solo miner, I switched one of my FPGA hosts to bfgminer 2.9.3 in order to mine with getblocktemplate against bitcoind 0.7.1. This particular host has 37 FPGA devices (mixture of bfl singles, cm1's, icarus's) and I notice that bfgminer is sub-optimal: every 2-3 minutes, it does about 20-40 getblocktemplate calls in a row (1 for each FPGA device?). These 20-40 getblocktemplate calls amount to about 3-4MB total. So on average, getblocktemplate generates about 1-2 MB of network traffic per minute.
On the other hand, when mining with getwork, these 37 FPGA devices amount to about 15 Ghash/sec, so it generates about 4 getwork calls per second, or about 600 kB/minute as measured by a packet sniffer.
Bottom line, getblocktemplate as it is implemented in bfgminer causes my host to generate more network traffic than getwork (but fewer RPC calls). I haven't taken the time to read the code yet, but, Luke, isn't there something trivial to optimize to reduce the number of getblocktemplate calls?
bitcoind is not intended for use of slow networks, and doesn't even attempt to minimize traffic. It also does not currently implement long-polling (though next-test has a patch to support it), so the template needs to be refreshed regularly in case of the old one being stale. As you note, above matters with bitcoind aside, bfgminer does not implement GBT optimally at this time, since it is using code originally built around getwork; cgminer has bypassed the getwork paths for its GBT support, but also intentionally designed the GBT path to use more bandwidth (conman wants to make GBT look bad). Rewriting the pool networking code in bfgminer has been on my todo list for a while (mainly due to other problematic bugs in it), and hopefully I'll get to that before 3.0. But even without it, each template is still able to scale per device, so the problem of ASICs hashing much faster is still dealt with in practice. As per the discussion we had in #btcfpga not long ago where you already know the truth, yet you still try to spread lies ... Spreading lies about people I guess is the only way you'll be able to get people to accept your piece of shit, crappy protocol that's worse than the old getwork in it's network usage and certainly no better performance for mining compared to getwork with any single device up to at least a few 100GH/s What ckolivas did was make sure the GBT piece of shit was getting the same number of work requests as Stratum is receiving. If that is called "intentionally designed the GBT path to use more bandwidth" then you seriously should not be allowed to go anywhere near the bitcoind software. You already put botnet support in bitcoind 0.7.x so no doubt I'm not surprised at you telling people to make BTC transaction confirms worse. You made transaction confirm times worse with your piece of crap pool for 5 months so the pool would make more BTC, so yeah it's not surprising. Your above statement directly implies that using GBT means you negatively affect transaction confirm times and using Stratum is better for transaction confirm times since you are directly implying that GBT should be doing fewer work requests than Stratum sends the miner. BTC is about transactions - go read Staoshi's paper if you are so stupid as to not understand that. If no one confirms transactions, then BTC is dead. Since you are directly implying that the GBT implementation in your clone miner negatively affects transaction confirm times compared to Stratum, then you are seriously saying that people SHOULD NOT be using it. Though the argument itself is worse, since you are saying that the GBT protocol requires fewer work requests and thus negatively impacts transaction commit times compared to Stratum, and thus the protocol itself is to blame.
|
|
|
|
TAiS46
|
|
November 23, 2012, 02:14:02 PM |
|
Hey, I have connected 8 BFL Singles. With bitminter I can mine without any problems. But if I use bfgminer, there will be only one of 8 used. Also I cant access the menu of bfgminer. any idea? running on ubuntu bfgminer -o http://pool -u user -p password
|
|
|
|
|