Quote from: XScrypt on March 29, 2014, 12:35:57 AM

Quote from: Reggie0 on March 28, 2014, 04:50:08 PM

Quote from: XScrypt on March 28, 2014, 02:21:11 PM

Quote from: Reggie0 on March 28, 2014, 08:09:26 AM

Quote from: XScrypt on March 28, 2014, 04:33:30 AM

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 isn't what the results indicate so far. If you're running at 1000 MHz, you should be hashing at around 420 kh/s. The stats so far indicate that even with no errors the performance isn't noticeably better than an unmodified unit. There could be a number of reasons for that.

That being said, you can't make the claim that there are no other issues when overclocking without knowing how every part of the system works. If any part of the system is being saturated or starved, increasing chip speed isn't going to help (and may even make things worse depending on the software/firmware/architecture).

Again, hashrate does NOT equal performance. Hashrate is a measure of how fast the chips are hashing, not how much work is actually being done. That's why you need to look at the whole system when you're trying to improve performance. More hashing power is pointless if the problem is actually IO, for example.

If after another 24 hours elapse and the performance is still about the same, then other parts of the system may need to be investigated for potential bottlenecks.

Again, there are no bottleneck or performance issue.

You keep saying that. However so far the reports from the modified miners don't back that up.

I can overclock my unmodified miner to get 500 kh/s, but that doesn't mean I'm getting 500 kh/s worth of completed work. Due to rejects/HW errors I'd be getting a lot less than that. You posted a screenshot showing 500kh/s but you had 429 HW errors over the course of about two days. For the same period of time, I have 9 HW errors. Those HW errors hurt and lower your effective hashrate.

It doesn't matter what hashrate your miner is reporting. What matters is how much work the pool sees you are doing. If, as we've seen, your miner is reporting 450 kh/s but the pool is reporting a 24 hour average of 350 kh/s then something is off.

We need OBJECTIVE tests to verify how effective the mods are. Testing shouldn't be run against pools or solomining anyway. There's too much variance. A real test would be run against test blocks. Remove the pools and coins from it entirely. Send the same workunit over and over again. Take the stats from that and calculate the effective hashrate. I think cgminer has a test mode that does something like this.

I whole heatedly agree with everything you've said thus far, XScrypt! I've said the same thing in different words on here.
I'd be very interested in knowing how to get cgminer to perform the tasks you mention re: re run the same work unit over and over again in order to gain a true benchmark of actual real time performance.
This just might be the thing that finally makes me transition over to cgminer Wink

I am liking it more and more, the more I read about it vs other mining programs out there. I still love cpuminer though! It was my first! Cheesy

Peace!
Wolfey2014