 Show Posts
|
|
Pages: « 1 2 3 4 [5] 6 »
|
Same here. My unmodified miner gets poolside results of anywhere from 250-500 kh/s. Using the 500 kh/s spike to make any claims doesn't make a lot of sense. My average rate is somewhere around 360-370.
As has been said many times in this thread, a faster hashrate does not necessarily mean better overall performance. The rest of the miner needs to be taken into account. I can think of several issues off the top of my head that would prevent improved performance (and even worse performance) with overclocking. Even the firmware could become an issue (ever played an old DOS game that didn't have an FPS limiter on a modern machine?).
I'm waiting to see what the numbers look like after another 24 hours.
There are no problem or performance issues at higher frequencies, except if HW error rate is increased. I'am using 230400 serial baudrate and the hashrate/freq ratio is constant. |
|
|
|
That's 505KH/s overkill pool side. And that figure changes almost by the minute! And I am quite sure this is not the case for every miner mining pool side. Especially not my mining miners miningnesses.......  That 505KH/s means 132% in your terms. Almost 150%. WoW such magic. Anyway.....so what?  ? It's a GPU, not an ASIC...quit tryin to be right...it ain't workin  It doesn't matter. The pool is unable to discriminate ASIC and GPU generated shares. What ever my miners are showing pool side now, it is at least 150% more now than before! Put that in your pipe and smoke it....  Yeah it is an inaccurate, shitty pool. I will put it  |
|
|
|
Not interested in semantics.
Facts are facts, no matter how you try to rationalize them, REAL results speak for themselves.
Nuff said...
Wolfey2014
The fact is, you have no REAL results, only unverified, wrong results. Sorry. I appreciate your skepticism. Believe me, I have better things to do than start unnecessary and untrue rumors. In any case, I do not apologize for the claims I am making. They are indeed true claims! I promise you! Please READ the posts in this thread and in the tuning thread. There are a few on here who have already achieved the same increase. The evidence is adding up in favor of my claims and Sandor's claims who started this adventure in the first place with his mods and claims. And, more favorable evidence is on the way! Anyway..... That is what you call, "verification". Wolfey2014 LOL. Then here is your next evidence:  Yes 2 pieces R9 290 @ 882kH/s each reported by pool as 2269 kH/s fast. Do not trust in pool reports! (Specially in this shitty one.) |
|
|
|
Not interested in semantics.
Facts are facts, no matter how you try to rationalize them, REAL results speak for themselves.
Nuff said...
Wolfey2014
The fact is, you have no REAL results, only unverified, wrong results. Sorry. |
|
|
|
The results I speak of and have been speaking of ALL ALONG are POOL SIDE!
I don't care what local hash rate says, I can't see it anyway using cpuminer. It's pool side that matters! AND That is where the money is made!
And by your own calculations / admission , it IS A 150% increase - client side - AT LEAST - moron!
SEE THAT! It's RIGHT IN YOUR FACE!!!
Wolfey2014
1. Pool hashrate reports are inaccurate and its have high variance. You reported a peak hashrate, not an average. Maybe try it on ghash.io, there are 6 hour, 12 hour and daily average values. 2. There are a theoretical problem: you will never get higher average pool hashrate than local average hashrate in long term. Cgminer's hashrate calculation based on how many jobs are finished in a second, whatever its result(you got a share or it has no solution). Pool calculation based on how many shares are submitted in a second. It depends on luck, but as Law of Large Numbers says, in long term it has to be same as your local hashrate(in an ideal environment: no network latency, no stale share, no rejected share, etc.). |
|
|
|
Hey yall! Just a quick update. I modded the rest of my 6 miners this afternoon, after work. I am seeing at least a 150% increase in hashing power out of my 6 pods right now. I just stated a fresh 24 hour test using litecoinpool.org at around 2015hrs tonight. So far, LOOKIN GOOD! REAL GOOD!  As of 2015hrs tomorrow night, I'll have a 24hr avarage per unit to look at. I'll post those results, with screen shots, then. Far out! I have 6 miners doing the work of 9.sthng non-modified default clock miners. Fukkin eh, man! Very good increase. Very good, indeed! Wolfey2014 It didn't happen. If you double the frequency, then you get double hashrate. At 1050MHz you will get 425kH/s. There are no magic... |
|
|
|
|
It is sad, but I have to tell You: There is a fixed ratio between hashrate and frequency, which is approx. 0.425(kH/s)/MHz.
You will never reach 600kH/s.
|
|
|
|
Red wire (+) intentionally connected to the tiny fuse (FB25) as it's easier to solder to than any other point.
FB25 is a Ferride Bead, which is a high frequency filter. |
|
|
|
I am giving out 0.6BTC to the first to get his Gridseed miner stable at 1100 MHz (<10 HW error in 24h) and post the steps to mod the miner. So far I have managed to get it stable at 1013 MHz, but I feel we can push it further.
Are there rewards(donation) for higher frequencies? |
|
|
|
hi, total newbs here. just wanna ask since i got this fpga for free (my friends bought it and decide not use it for whatever reason), could i use this for BTC mining? Genesys™ Virtex-5 FPGA Development Board http://www.digilentinc.com/Products/Detail.cfm?Prod=GENESYSthank you for your kind answer. regards, Probably you can use it, but it will be slow, because 50k logic gate is not enough to use fully unrolled pipes. As i know Spartan-6 LX90T produces 90MH/s, and it has almost twice gates. |
|
|
|
|
fpgaminer: is there any advantage using "{a,b,c}<={x,y,z};" instead of "a<=x;b<=y;c<=z;" ?
(My opinion is it only helps to make more readable code.)
|
|
|
|
-3 speed grade?
Whatever the highest speed grade available is I would assume. I haven't asked what the speed grade of the kit was. OK, i've checked the link. It is assembled with -2 speedgrade. "AC701 evaluation board featuring the XC7A200T-2FBG676C FPGA" |
|
|
|
Problem is that XST ALWAYS reports shit hot timings for the simulation, but once the design is mapped into the actual device, then the timings go to pot because of the way the interconnects work.(some of the XST tools just look at the 'pure logic' chains for timing).
Yes, but the xst reported max. clock and par reported max. clock ratio will not change a lot. |
|
|
|
Sorry, I thought you were talking about scrolling down in the list of files. I got the file from the download section. Now I see what section you were talking about...
No problem. |
|
|
|
I'm not familiar with the site. All can find is some firmware (mostlyJava) and the only HDL I can find is for memory tests etc. and some references to the Leon open source design. They seem to have lots of documentation so it's most likely hidden somewhere one the site.Anybody knows where?
Maybe try to scroll down:) Download a source package, extract it, and you can find it in "fpga" subdirectory. |
|
|
|
Correct, something like that. I was thinking on-die memory segments could be used. But anything that would separate the hasher clock from the software communicator should be a good thing. I hadn't seen that code as I was working on the altera branches. They must be doing something right to achieve 200mh/s per chip on a spartan lx150 which in this thread (and on the hardware comparison page) topped out at 100mh/s on other boards (unless I missed some updates somewhere). The ztex design seems to be clocking 1 core at 200+mhz versus the other designs without hasher/controller separation clocking at 100mhz with 1 core. Would be amazing to double the clock rate of my altera chips from 220 to 440 w/ 3 cores! Separating clock will not help for you(i've tried on xc6slx150). The frequency is limited by carry chains, not by the clock network delays. As i know, ztex design allows 190MHz generally(probably calculated by xilinx at 85 celsius) , but voltage/temperature derating allows to increase frequency. I've tried to compile ztex's source, and xst reported 230 MHz maximal clock freq. . I made some modifications, so i hope it will reach 190MHz after par, because Xst reported 316.312MHz. |
|
|
|
|
When PGP was published first, they tried to vanish it. Similar story...
|
|
|
|
|
