So even after the LTC TX spam fiasco someone release an alt-coin w/ same vulnerability?
I mean I thought in theory the point of alt-coins is to be a learning environment. If scam-coins aren't going to patch the mistakes of prior scam-coins then they aren't even make a token effort to innovate.
Won't get any disagreement from me, lazy coin creator is lazy... but hey, at least he fixed it when I pointed it out to him.  |
|
|
|
Thank you! Also, new update out. It's HIGHLY reccomended you update to v4 or latest github because we added some checkpoints, increased the initial DL of the blockchain, applied a performance fix and changed the fees to a somewhat better value. http://www.mediafire.com/?hv0e5qjlgkpzlzbWhat fees? *checks commit log* Default transaction fee was increased from 0.0005/kB to 0.1/kB. Seems to still use standard BTC rules for which tx don't require a fee. See LTC TX spam fiasco for the reason. |
|
|
|
Reference C implementation slower than optimized asm, news at 11.
As I wrote: "When I wrote it using SSE2 (calc 4 hashes at once) I got 2500 h/s from each GHz of an Intel CPU."See? Tip: Statements like that make me think "oh dear, another crypto kook".
I don't need tips from a guy who is so infantile. I don't know why u think that this topic has something personal against u. Read https://bitcointalk.org/index.php?topic=55670.0 to see results of my implementation. Hashrate was proven by litecoinpool.org statistics and tests were made by other guys. Ur miner is so slow that even simple optimizations give good boost to performance (+200% bonus). --- Starting from this point I put u into ignore list so u won't waste my time. *facepalm* Again, completely avoiding the topic of outrageous claims without *any* proof. Oh wait, the "proof" is writing a miner that's 20% slower than poolers. right. Ignored. |
|
|
|
My implementation of Scrypt is optimized for an Intel cpu and runs faster than ur code.
Reference C implementation slower than optimized asm, news at 11. The 1st step I made was optimization of ur miner and I wasn't satisfied with results, so I moved to original Tarsnap code and then to implementation posted here. I took into account a REAL cpu that has limited cache for code and data, not very clever branch predictor, register stalls and that is able to process 3 instructions at once.
So... exactly what pooler did, except he managed it without big secrecy or talking about boolean simplification and factor 1000 speedups "if it only had worked". Tip: Statements like that make me think "oh dear, another crypto kook". |
|
|
|
Your fear that someone might find a faster implementation by running one instance of it through some magical optimization software doesn't seem that plausible to me. Roughly speaking, scrypt is based on randomly mixing up the results of a large number of SHA256 hashes, so any substantial optimization which didn't also optimize SHA256 would be pretty surprising. Any accurate optimization would still need random access to all those hashes, which forces a very large circuit.
I'm afraid that this circuit won't be large enough for modern FPGAs. ... says the guy claiming +1024 is negative. |
|
|
|
Let's play a game of counting XORs, shall we? for (i=0; i<32768; i+=16)
{
for (j=0; j<16; j++)
uiStorage[i+32+j]=uiStorage[i+j]^uiStorage[i+16+j];
Salsa(&uiStorage[i+32]);
}
for (i=0; i<32768; i+=32)
{
for (j=0; j<16; j++)
uiStorage[i+j]^=uiStorage[i+16+j];
}
for (i=0; i<32768; i+=16)
{
j=((uiStorage[32784]&1023)<<5)+(i&31);
for (k=0; k<16; k++)
uiStorage[32768+(i&31)+k]=uiStorage[32768+k]^uiStorage[32784+k]^uiStorage[j+k];
Salsa(&uiStorage[32768+(i&31)]);
}
first loop is 2048 times 1 16-dword XOR 2nd loop 1024 times 1 16-dword XOR 3rd loop 2048 times 2 16-dword XORs (sorry, a 3-input XOR is still 2 XORs) total # of 16-dword XORs ... 7168 vs. a simple stupid scrypt(1024,1,1) (using 16-dword vectors for X and V to keep things more readable): for (i = 0; i < 1024; i++) {
V[i*2+0] = X[0];
V[i*2+1] = X[1];
X[0] ^= X[1];
X[0] = salsa20(X[0]);
X[1] ^= X[0];
X[1] = salsa20(X[1]);
}
for (i = 0; i < 1024; i++) {
j = X[1].vec_element[0] & 1023;
X[0] ^= V[j * 2 + 0];
X[1] ^= V[j * 2 + 1];
X[0] ^= X[1]
X[0] = salsa20(X[0]);
X[1] ^= X[0];
X[1] = salsa20(X[1]);
}
let's count again... 1st loop 1024 times 2 16-dword XORs 2nd loop 1024 times 4 16-dword XORs total # of 16-dword XORs ... 6144 Congratulations. Your implementation *increased* the total # of 16-dword XORs vs. reference scrypt by 1024... ?!? |
|
|
|
I've had my Sapphire-brand 7970 for a few days now, mining away with diablominer. I seem to have come pretty close to what others are seeing - 630MH/s at 1075/685, 1.125V, 76c at 48% fan - but not all the way:
- I can't downclock my memory below 685, the lower limit in Afterburner (the only software that seems to work consistently, trixx won't let me underclock mem or undervolt). I have tried the "set lowest, restart" trick multiple times with no luck. How are others doing 160 memclock? My card is running bios 113-C3860100-X00, is this the same as everyone else?
- I am monitoring voltages in Afterburner, as neither GPU-Z or GPU Caps Viewer seem to display the correct voltage. Afterburner seems to be displaying a "true" Vcore value, I see it drooping under load and bouncing back to near my setpoint at idle (1.125V set in Afterburner leads to a stable 1.041V under load, 1.115V at idle). I have tried to set my voltage so that the at-load voltage is roughly what other people have been reporting here. When are you guys reporting voltages, which value are you using? I tried running at 925 core, 0.95V like some others have reported here - voltage droops to 0.892v and a TDR follows easily.
Any advice?
I think so far everyone has been using true Vcore under load as AB beta10 displays, so set target 50-70mV higher. |
|
|
|
290MH on a 5870? Seriously? I get over 430 from 5850s.
*6*870. Probably stock clocks or a suboptimal miner with a very mild OC. And 430Mh/s from 5850s? That's ~1GHz core. Wonder how long they'll last... |
|
|
|
If those numbers are correct, these cards are double in term of efficiency.
Not really, more like ~0% stock and ~ +30% undervolted at stock clock vs. my old 5970 numbers here. Guess we'll never know why on earth AMD decided to go with 1.175V core at 925 MHz, so far all cards seem perfectly happy at 0.95-1.05V at 925 core for mining and 3D. While at stock V they seem to OC to 1050-1120 MHz...  Now the big Q: if those aren't cherry-picked chips, what will 7990s be able to reach? |
|
|
|
I thought about that, and I guess the only way to figure out how much power the card draws at idle is to have two identical cards. You wouldn't need two identical cards if you can boot headless. Boot and measure idle w/ no cards installed and with one card installed. Also a logic puzzle would be to figure out the idle wattage of 2 different cards using no other cards and no headless boot (it can be done but involves multiple boots).  Of course this doesn't apply to the 79XX series since it has the ability to hibernate GPUs that aren't currently active, so the MH/J for a multi-card 79XX setup are going to appear unusually low simply because system idle draw of a single 7970 is the same as that very close to that of a quad 7970 setup as I understand it.
The hybernating 7970 uses much less idle power but it isn't 0. I think AMD claim is <3W. With 3x 7970 one could get the exact idle and hibernating wattage. your 2 unknown card idle wattages are A and B, your system is X measure: (X + A), (X + B), (X + A + B) (X + A) + (X + B) - (X + A + B) = X (X + A + B) - (X + A) = A (X + A + B) - (X + B) = B |
|
|
|
Hi
I'm trying to set up a linux based mining rig based on FGPA.
I'm interested in using a Beagleboard to control the FGPAs.
The question is how much RAM do I need to run several instances of a mining software like diablo, phoenix, etc.
Can somebody with a linux mining rig share some numbers?
Thanks!
X for the os + several MB per instance. So for several instances ... about X + several^2 - Y*several (where Y is shared libraries). |
|
|
|
I tried to lower down the memory clock, but it seems can not be controled,
no matter what value I set, the result are always 1375
Check the 3*7970 thread, you have to use MSI AB with unofficial overclocking set to 2 to be able to lower mem clock < bios limits, so far haven't found a way to do it on linux. :/ |
|
|
|
for some reason you have to manually load libXext before libatiadlxx --- a/adl_api.py 2012-01-18 18:04:59.199777656 +0100
+++ b/adl_api.py 2012-01-18 18:05:11.199734821 +0100
@@ -36,6 +36,7 @@
from ctypes import RTLD_GLOBAL
# load the ADL 3.0 dso/dll
+ CDLL("libXext.so", mode=RTLD_GLOBAL)
_libadl = CDLL("libatiadlxx.so", mode=RTLD_GLOBAL)
# ADL requires we pass an allocation function and handle freeing it ourselves
|
|
|
|
System Mining: 235 watts
Card Mining: 605/166mhz, 900mv, 97 watts
550 MH/s (5.67 MH/watt)
Thats pretty damn impressive. I mean BFL yet to ship FPGA only get 10MH/W. I may undervolt my rigs this summer. Keeping the garage cool with cards puking out 4KW of heat during August is tough. ... yet the whole system only gets a measly 2.34Mh/J, why do I have the sneaking suspicion someones "idle" numbers are off? |
|
|
|
Well, let's see...
$60 via board + $10 ram + $220 backplane for 7 cards. $41.43/slot
$50 am3 board + $30 sempron + $10 ram + $10 extender + $220 backplane for 8 cards. $40.00/slot
$80 am3 board + $30 sempron + $10 ram + $10 extender + $220 backplane for 10 cards. $35/slot (and lots of fun with 8 card driver limit)
vs.
$80 am3 board + $30 sempron + $10 ram + 2 $10 extenders for 4 cards. $35/slot.
Meh.
Shouldn't the vs comparison use 7 cards? i.e., $80 am3 board + $30 sempron + $10 ram + 5 $10 extenders for 7 cards. ~$24/slot Which I was hoping would make the standard version look worse. *slaps forehead* edit; I suppose the other benefit would be the ability to use an even cheaper mobo with 1x 16x slot. That's why I put that $60 via board there, cheapest board w/ cpu and a PCIe I could come up with quickly, atom boards w/ PCIe tend to be > $80 and any cheap AMx + sempron is also > $60. Btw, where do you find a AMx board w/ 7 PCIe slots for $80? And yes, I left out quite a few things. But start adding stuff like PSUs, materials/time for custom racks, PDUs, ventilation, ... and the whole thing gets overly complex. and the +$/slot ends up about the same. |
|
|
|
|
Well, let's see...
$60 via board + $10 ram + $220 backplane for 7 cards. $41.43/slot
$50 am3 board + $30 sempron + $10 ram + $10 extender + $220 backplane for 8 cards. $40.00/slot
$80 am3 board + $30 sempron + $10 ram + $10 extender + $220 backplane for 10 cards. $35/slot (and lots of fun with 8 card driver limit)
vs.
$80 am3 board + $30 sempron + $10 ram + 2 $10 extenders for 4 cards. $35/slot.
Meh.
|
|
|
|
Have I been inaccurate anywhere in this thread, Art?
Nope, just factually correct info and helpful suggestions, presented in a professional fashion... Guess there's at least some hope remaining for this forum. |
|
|
|
For OPs mysterious shutdowns... X750 is single-rail, so can't be a problem there. Also, mainboard + stuff + one card on #1; 2 cards on #2 is the way to go. mysterious shutdown points towards #1 or mainboard having some issue (at least one piece of true info, you only get locked up cards if #2 drops out). Now for bad power causing issues... possible, my 4*5970 boxes regularly locked up or powered off on brownouts (got a line voltage monitor/logger, so correlation was easy). Another possible issue... southbridge chipset temp. msi 890fxa-gd70 is *very* iffy there. Oh ,and on that board the CPU voltage regulator phase switching is... problematic. Maybe test if the problem goes away if you disable it, or just keep the cpu at 100% load constantly (no fucking clue why that helps, but it did work here to stabilize a 890fxa w/ 4*5970 and a Athlon2 X2...). Now... long rant: So much misinformation in one thread. But they will all fail prematurely if not loaded.
Quite a strong general statement there. Got any proof to back that up? For a group-regulated design, you want some load on +5/+3.3, due to obvious reasons, and those *can* fail if you don't do it. But for anything that uses DC/DCs to create 5V and 3.3V outputs ... no. And if you had bothered to check out the X750s OP is using... guess what... they *are* 12V + DC/DC based. On a side note:
To say powering the GPU's from two sources will invite problems is to now know the entire truth.
Thats not what I said. I specifically said powering one GPU with 2 PSUs, as that is a recepy for disaster because of voltage regulation. THere is no real problem using multiple PSUs for multiple cards, as long as no single GPU is powered by 2 PSUs P4man is right. Also you don't want to do it because anytime you connect two power sources together you are going to get losses due to voltage mismatch. For similar reasons you shouldn't power graphics cards which have 2 power connectors from different rails of the same PSU as they are going to have differing voltage output. Uhmmm... nope. No problem either. Please find *any* video card that connects the aux connectors together (violates PCIe spec. badly). Or hell, any card that doesn't like one of them at 12.6V with the other at 11.4V. Now why *isn't* that a big problem? Well, modern multiphase DC/DCs as used on any recent graphics card deal it pretty nicely, you get some uneven average current on phases powered from different voltages, roughly the same % mismatch as the voltage mismatch. Read up on theory of operation of synchronous multiphase step-down converters with current-mode control of individual phases and you'll figure out why. So... why on earth can't people stop to check their "facts" or even just think for a bit before regurgitating the same old myths and overgeneralizations? |
|
|
|
|
Well, at least on 7970 it seems not horribly memory limited.
925 to 1125 = +21.6% core gives +17.1% performance (= 80% effective)
even at 1125 core 1375 to 1575 memclock =+14.5% only gets ~ +2.5% performance (= ~18% effective)
That looks a lot more core than memory limited to me.
So if it's *supposed* to be mem limited... that kernel still has lots of room for improvements on 79xx.
|
|
|
|
|
Show Posts
