CGMiner 2.0.0 stales sample @ Coinotron: - HD6850: 15,270 shares accepted, 30 stale > 0.1964%
 - HD5670: 6,350 shares accepted, 8 stale > 0.1259%
 - GTX580: 4,025 shares accepted, 4 stale > 0.0994%
Stales are higher @ Mt. Red & Ars Bitcoin, but still way lower than with GUIMiner. I look forward to trying out 2.0.3. Keep up the awesome support!  To be fair, don't start quoting numbers until you've hit 10k shares. There is still too large of a statistical instability to give wrong answers. That said, anything below 0.25% is good enough  |
|
|
|
No, it isn't a guideline. 1/3rd core clock for memory clock sits in a zone that on most Radeon 5xxxes it hits the stock memory timings correctly and incurs no speed loss for applications that don't rely on memory bandwidth.
If you're too low or too high, you incur a speed loss or sometimes the card just locks up.
Some kernels require better compliance with this than others.
except it is a guideline, because my 5750 is not stable with memory at 233 mhz my 5850 card is faster as slightly more than 1/3, its core clock is is 725 and 275 is faster than both 242 and 300 you can blame the kernel, but phatk 2.2 is the fastest kernel on both cards and those timings are the fastest timings in practice update: got a new card at 725 core speed, 275 mem clock is faster than 250, and 240 gives artifacts this is higher than 1/3 between 270 and 280 gives the best results Hrm, if the timing is off (ie, for 1200 instead of 1000), it should be closer to 290 is the best. |
|
|
|
Considering I have been mining for about a half a year, I almost feel stupid for having to ask this question....BUT;
Why do some pools produce up to 10-15% stales at times, while other, using the EXACT SAME SETTINGS produce less than 1-1.5% ?
I have no clue what it takes to set up a pool for mining, but I assumed it was pretty standard yet I notice that some mining software is more friendly at certain pools than others.
On my PPS Pool, I am able to get away with about 1% stales (CGMiner kicks ass!), while on a Proportional Pool that I mine on, I get approx 10-14% Stales constantly and the only thing that differs in my settings are the login details......LOL
I used to notice the same while using Guiminer and switching between Phoenix & POCLBM, depending on which was faster on certain pools and generated the least number of stales.
Any comments ?
The short answer is some pools suck dick. |
|
|
|
Geez!
You might wish to remember who the moderator is for this part of the forum. I hope when I hit Report to Moderator it went to the other mod for this subsection and also an Admin per the SMF documentation. theymos has zero problems with how I moderate this board. If you have a problem with me having a problem with the pool I use having a problem with their security in the face of recent security problems then bring the problem up with theymos, and he will probably have a problem with you. Problem? |
|
|
|
Geez!
You might wish to remember who the moderator is for this part of the forum. |
|
|
|
No, its related to the Google Ads that show up for people who don't donate. The AdSense scripts are served over regular HTTP, not HTTPS since they don't have SSL support for AdSense.
Then disable it. Don't compromise the SSL session with stupidity. I disagree. You aren't compromising the secured traffic between you and BTC Guild. Our main webpage has the same error because of a youtube video. Youtube still hasn't added SSL support. There are very complex methods to encapsulated a youtube video in your own flash player, but I decided not to spend 10 hours of time programming that because of a silly warning. Plus, E needs to make money any way he can, his pool is donation only and I'm pretty sure he barely makes a profit after hosting costs. What I said still applies. Don't include foreign elements on an SSL'ed page. Period. I shouldn't have to be teaching security 101 to pool owners. |
|
|
|
PING: Windows Miners (perhaps Win7 x64) ....or anyone who has had VOLTAGE CONTROL problems.I can't seem to get VOLTAGE CONTROL working on any of my cards. Could anyone offer advice ? I am using the latest version of CGMiner w/11.8 Drivers and have a selection of 5770, 6870 & 6950 Cards that do not seem to recognize the voltage flag in my BAT files. I have also tried changing values INSIDE of CGMiner and again, failed....so, same results. I know that a few of my cards will never work properly (Asus 6950 DCU II cards) in terms of voltage control, but most of my 5770 & 6870 cards are all REFERENCE models and SHOULD work....but seemingly, do not. I simply added: --gpu-vddc 1.2 ....along with my regular settings and none of the cards seemed to be affected by the voltage increase as confirmed in CGMiner & GPU-Z. Complete BAT file looks like: cgminer -o http://pool:port -u username -p password -I 8 -Q 10 --auto-fan --gpu-vddc 1.2 --gpu-engine 975 --gpu-memclock 300 --temp-target 70 Everything works EXCEPT for Voltage increases.....Help ? Thanks in advance, Allan You can't change the voltage on non-ref cards that use VRMs that the driver doesn't understand how to talk to. Do not try using RBE to edit the firmware either, you can easily brick or damage a card that way. |
|
|
|
When i'm using this each gpu uses a full cpu core all the time. Is it supposed to or is something wrong on my end?
Driver bug. Any idea how to fix it? Bitch at AMD until they fix it. |
|
|
|
No, its related to the Google Ads that show up for people who don't donate. The AdSense scripts are served over regular HTTP, not HTTPS since they don't have SSL support for AdSense.
Then disable it. Don't compromise the SSL session with stupidity. |
|
|
|
When i'm using this each gpu uses a full cpu core all the time. Is it supposed to or is something wrong on my end?
Driver bug. |
|
|
|
Was this a mtgox session hijack from the forum hack? Were you logged into mtgox when the forum hack occurred?
That would be interesting if it was related. |
|
|
|
It's possible with the recent security lapses at certificate authorities ( a la comodohacker) that someone, for some period of time, was able to do a csrf / mitm attack, no? This is what I implied earlier. It is, in fact, possible. Just very unlikely. |
|
|
|
And for future note, I'm going to treat all future bugs like this: If you're not using Eligius, it is not my problem.
Wait so does this still apply? That was never really true. I test on many of the large pools. But if I can't reproduce it, its not a bug. |
|
|
|
Forging a SSL cert only enables the possibility of a man-in-the-middle attack from being transparently obvious when it's no longer signed properly. However, you still have to accept the change in certificate for the forged-SSL MIM attack to work. Did you log in to MtGox from strange internet connections in shady places? Or did MtGox get their DNS forged as well?
No, a forged cert from DigiNotar would allow to transparently execute a MiTM attack against an end-user, without her seeing any security warning whatsoever. Except in 1 scenario, see below... Is there actually a browser that will remember a certificate and complain if that cert is replaced with a different valid CA-signed cert?
...only 1 browser would warn you: Chrome, because Google hard-coded hashes of the public keys for a small number of high-profile websites certificates keys. This is called public key pinning. Mozilla is considering pinning keys on first site access. So the only way to MITM false certs is during the first access (which makes it same to ssh's flaw on server fingerprint (aka ~/.ssh/known_hosts)). DigiNotar is a clusterfuck, regardless. |
|
|
|
I also do not think it is likely the recent DigiNotar or Globalsign break ins have produced SSL certs to attack mtgox with (which WOULD explain this) because mtgox uses EV certs and as far as I know none of the fake certs were for EV, but DigiNotar and Globalsign both DO issue EV certs. Although I am not ruling this out.
Forging a SSL cert only enables the possibility of a man-in-the-middle attack from being transparently obvious when it's no longer signed properly. However, you still have to accept the change in certificate for the forged-SSL MIM attack to work. Did you log in to MtGox from strange internet connections in shady places? Or did MtGox get their DNS forged as well? The problem is you DONT need to accept the cert since its signed by a CA. Thats why this was so dangerous. All you need is someone at Tux's ISP juping the traffic and bam MITM attack and no one is the wiser. |
|
|
|
I'm not so sure you can completely rule this out. Last month kernel.org was compromized. In order to compromise the kernel, several developement machines would need to be compromized as well. Yes, I'm aware of the kernel.org break in. This does not apply here as the kernel I am running predates the break in and I do not get my kernel source from kernel.org. Mmm delicious git. |
|
|
|
I have to say one more thing. It is not right to bail out some (because they are a staff member on Bitcoin forum etc.) ans let others that get hacked for different reasons get nothing. This sounds to me like what the Federal Reserve did and are doing today, they bailed out friends/banks with trillions of dollars of interest free/low interest money and let "Main street" take the hit.
except that the Fed uses USD it prints up out of thin air at taxpayer expense via devaluation of the USD. MagTux used his own BTC. The principle is the same. If he just bails out some people, the others have to pay for that through higher trading fees, trading fees that in theory could have been lower because bailing out is a cost that in the end has to be taking from somewhere. you're assuming that the tx fees will increase. how do you know that? Study Economics 101. Thats assuming tx fees are not already set high enough to cover projected fraud issues. |
|
|
|
I believe that fraudulent EV certificates were issued.
For reasons unrelated to this, I would like to have this citation notated. I only found one useful article that mentions that EVSSL may have been included in the breach. http://isc.sans.edu/diary.html?storyid=11500I'm assuming that you and MagicalTux checked the IPs used on your account. Anything strange there? See the third post, MtGox emails you the IP that made the request on withdraws. |
|
|
|
i would suggest you change the title of this thread to something much less ominous. you're scaring people.
Changed. But until me or Tux can figure out what exactly happened, the issue remains open. |
|
|
|
I notified MagicTux through his support email, and he sent back a useless form letter as a reply. Recently there has been a large increase in the number of “phishing” attacks that have been made against the users of Mt.Gox.
...
We sincerely apologize for the inconvenience our users have suffered at the hands of phishers, and are doing all that we can to prevent further attacks in the future.
Thanks,
MtGox.com Team I consider this a smoking gun. What about browsing other sites whilst you are logged into mtgox? Due to CSRF attacks - this is something you shouldn't do when you are logged in to an important account. You can argue that the site should be fully protected against CSRF, especially as this has come up before regarding mtgox - but it's possible there is a regression in this area or even that your specific browser version is contributing to this risk. XSRF attacks are largely difficult to perform in many cases. The problem is I would have had to visit the attacker's website at some point inside of the same environment I use to access mtgox to allow it. |
|
|
|
|
Show Posts
