Just a suggestion. A simple overt FYI. And I would think most people download before reading the readme
And that's the problem... Indeed there is only SO MUCH I can put in a readme, link, warning, information, documentation, blah blah blah. Seriously does ANY other bitcoin app have anything like the documentation that cgminer has??? |
|
|
|
hmm.. so I have to keep mining with Eligius in order to get back to expected return. I'm not particularly well versed in the mathematics of probability.. but isn't this a bit like the gambler's fallacy? ie just because I've tossed a run of 10 tails in a row doesn't mean I'm more likely to get a run of heads. Does the maths really say It'll come good for me?
It is possible that you have bad luck "forever" according to gambler's fallacy. Be aware that arsbitcoin had this issue with their payout scheme and towards the end all the miners were out a LOT of btc and the luck slowly got better but never recovered the massive negative state they had reached and then the pool shutdown and the miners never got it back. |
|
|
|
|
For what it's worth, mtred have moved their bitcoind over to 0.6.3rc1 after I pointed it out to them and I have noticed a significant improvement in their block change speed (with much less lag across longpolls) already, even though a lot of the network has not yet changed over to the potentially faster protocol.
|
|
|
|
Ok, We are running 0.6.3rc1 on the main server. Let me know how it looks.
Rejects were running at 2% when I last complained. I restarted after this change. (5s):2795.4 (avg):2646.7 Mh/s | Q:5024 A:13307 R:76 HW:0 E:265% U:36.3/m That's <.6% where .4% is about as good as it gets elsewhere at my distance from USA servers, so that's a significant improvement. I'm actually guessing based on the change that went into 0.6.3rc1 that as more of the network adopts 0.6.3rc1+ the block transmission rate will get faster across the whole network so if anything, it should get even better. Great stuff. Now I can mine here again. |
|
|
|
As far as the miner to use, a large population will tell you to use cgminer, but I prefer phoenix because it gives me about 1-2% more mhash than cgminer (stupid variable intensities. even setting a high intensity is still variable, which is why its slower).
Not debating what you find in hashrate difference, but correction: high intensities are not variable, reporting looks like it is because of the asynchronous nature of the threads reporting back their hashes done. Only the longterm average is accurate and only after enough time has passed since it's an all time average of true hashes done which will include any dips across longpoll etc. There is no variable intensity in anything but dynamic mode in cgminer. |
|
|
|
there was a keylogger in the windows binaries download
That's your antivirus application being retarded. As long as you downloaded it from the official links in the original post, there is no malware at all. I did download it from the original link and I get a keylogger hit when downloading and when I try to open the archive. Could be Mcaffee just being weird but I have the latest defs and it would be nice to know why this download generates the flag as other people might have the same concern McCrappy is useless shit, unfortunately. You could see if there is a way to submit some info to them to tell them that they are wrong. Well I do not know for sure that my virus software, Trend Micro, is wrong (thought it was McAfee at first glance). I trust that you believe that to be the case, but I am passing the information along so it can be looked at from the file hosters end and verified. It's even in the FAQ in the included README.txt The Readme.txt would indeed be instructive if my Virus software allowed me to open the archive file, which it did not because it thought the download was infected - hence the concern PS That was not me you explained it to previously it was stevegee58 thanks David It is also where all the archives are kept here: http://ck.kolivas.org/apps/cgminer/READMEAnd it is posted in the first post of this forum thread here: https://bitcointalk.org/index.php?topic=28402.0sigh... |
|
|
|
there was a keylogger in the windows binaries download
That's your antivirus application being retarded. As long as you downloaded it from the official links in the original post, there is no malware at all. I did download it from the original link and I get a keylogger hit when downloading and when I try to open the archive. Could be Mcaffee just being weird but I have the latest defs and it would be nice to know why this download generates the flag as other people might have the same concern McCrappy is useless shit, unfortunately. You could see if there is a way to submit some info to them to tell them that they are wrong. Well I do not know for sure that my virus software, Trend Micro, is wrong (thought it was McAfee at first glance). I trust that you believe that to be the case, but I am passing the information along so it can be looked at from the file hosters end and verified. It's even in the FAQ in the included README.txt |
|
|
|
|
The lower end of the gpu-engine range is there for a good reason: if cgminer detects overheat that it cannot control with fan alone, it starts clocking down the gpu engine speed (before getting to the hard cutoff speed). Sure 300 is overkill, but it should never get there unless a fan seizes (which one of mine did on a 6970!). I suggest for your GPU2 you drop the speed a little since it's getting hardware errors. As for power consumption, the hardware and OS and therefore software have absolutely no idea about it and only external tools can tell you.
Solo mining is a lousy idea with less than 1% of the total network (lots written about this as to why small solo mining is bad). Yes I am suggesting you currently need 150GH to make it worth solo mining. I suggest you go mine with ozcoin instead. Config file always goes first. Unfortunately it's a curly part of the code which is painful to fix and I don't care enough to do so. Just delete the config file if it's a problem or don't give it parameters...
|
|
|
|
The first poster discovering the client-block-receive to miner-long-poll-receive delay time reveals another factor unrelated to the Bitcoin network block propagation speed - the time it takes for a pool to transmit a new block to all miners. In my past experience, depending on the number of pool miners, the number of pool servers, and the pool software and it's delays communicating with Bitcoin, going through the list of miners and sending each a LP response can take a significant amount of time, generally four, but up to ten seconds from the first to the last miner being notified. This from my own research profiling pool LP times as a predictor of who found the block.
I agree, longpoll notification is slow. I wonder if using a lightweight message queuing system like zeromq would do a better job instead of the http based long polling. ... implement a protocol rather than use something designed for web servers ... longpoll is not the issue, but merely a symptom of other issues. Fix those and longpoll will still suffice... that and I'd be really pissed if I had to support something else after spending months getting longpoll working a treat in cgminer. |
|
|
|
"C:\Program Files (x86)\cgminer\cgminer-2.4.3-win32\cgminer.exe" -S COM4 cgminer -o http://us.ozco.in:8332 -u *** -p *** -I 9 --auto-fan --gpu-engine 900 --gpu-memclock 300 Note that "cgminer" is the same thing on non-windows as "cgminer.exe" is on windows, so it's not meaningful to include it there. Make sure you're not loading a configuration file unintentionally (which it does by default if it finds one) by starting it from a dos prompt instead of a shortcut to see what is happening until you sort things out. If clocks are fixed at some low rate, usually that's an open web browser or something that is fixing the clock speed for fucked up flash usage or youboob or some shit, so closing web browsers usually fixes it. |
|
|
|
The most recent bitcoin/bitcoin.git has "signature verification cache" which should speed up block validation quite a bit.
That's very interesting and if it makes a big difference should be a fairly urgent update for pool owners if the problem is as big as it appears to be. |
|
|
|
Maybe they are testing ASIC's  If their promotion is true, they could just be testing ASIC, no plural... |
|
|
|
This is the Output from configure checking for alloca... yes
checking for pthread_create in -lpthread... yes
checking for json_loads in -ljansson... no
So, it seems so, that the platform has. Pthread create doesn't mean it supports all the pthread features, in this case read write locks the same way. Anyway it appears to be struggling with a pointer to the pthread read write lock typedef. No idea how they implement it on that platform or why it wouldn't like a pointer. |
|
|
|
I am trying do build the CGMiner 2.4.3 for an AT91SAM9G45 (it's an Arm) Hardware. but it fails. configure works fine. i doing it this way. CC=arm-linux-gcc AR=arm-linux-ar RANLIB=arm-linux-ranlib ./configure --build=arm-linux --target=arm-linux --prefix=/usr --host=arm but when i 'make', i get this error: make[2]: Betrete Verzeichnis '/usr/local/src/cgminer-2.4.3'
CC cgminer-logging.o
In file included from logging.c:13:
miner.h:471: error: expected ')' before '*' token
miner.h:477: error: expected ')' before '*' token
miner.h:483: error: expected ')' before '*' token
miner.h:489: error: expected ')' before '*' token
miner.h:494: error: expected ')' before '*' token
miner.h:505: error: expected ')' before '*' token
miner.h:529: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'netacc_lock'
make[2]: *** [cgminer-logging.o] Fehler 1
make[2]: Verlasse Verzeichnis '/usr/local/src/cgminer-2.4.3'
make[1]: *** [all-recursive] Fehler 1
make[1]: Verlasse Verzeichnis '/usr/local/src/cgminer-2.4.3'
make: *** [all] Fehler 2
the miner.h looks good for me. From the looks of that, it appears your architecture does not support read write locks. i.e. it has no pthread_rwlock_t implementation. |
|
|
|
It looks like Ozcoin is processing all transactions, Bitparking is passing along no transactions, and Deepbit has a transaction fee threshold that prunes lower fee and/or free transactions from their blocks.
The question then, is, does this make a difference to them? Are deepbit (and to a lesser extent bitparking) keeping a low orphan rate or is this barking up the wrong tree? I still get the feeling we're missing the underlying cause for this since it predates the abrupt rise in the number of transactions. |
|
|
|
./configure --help | grep modminer
--enable-modminer Compile support for ModMiner FPGAs(default disabled)
How do I compile this for windows. This is already built into the windows binary on the latest release, so if it's not working, it's something else... |
|
|
|
Bear in mind that block generation times can be not remotely accurate with rolltime enabled. cgminer limits rolling to about 10 minutes, so the time could be 10 minutes out from the real local time, but apparently luke-jr has removed all limits on his rolltime on eligius meaning work from there could appear to be from any time in the future. |
|
|
|
Hi guys, I basically had a prophetic dream vision last night, that the BFL Labs ASIC won't be shipped until February 2013 at best.
I don't even want them to ship, they're gonna ruin Bitcoins. I spent ~2000$ on quad 7970's, only the cards, and they're planning to release a "coffee warmer" 3ghs+ ASIC that does more than my cards for 150$? Eff that, difficulty will skyrocket and put a strain on video card miners. Delicious tears No, it won't ruin "Bitcoins" It will ruin your fail investment, only that. And you deserve that. Bitcoin will only gain from ASICs The 7970s will still be worth a LOT if you sell them, and there is no hard timeframe for this vapourware at this stage, so you're in no danger. |
|
|
|
|
Show Posts
