Hopefully someone over at yPool has noticed that the link to their miner is down and fixes it.

The original set included a full range of AMD/Intel optimised miners, though if anyone knows how to contact yvg1900 you might want to let them know.

Wow, nice work.

Can you post your before and afters including spec?

Don't forget that when new clients come out they might be worth testing (especially if you can squeeze a little extra juice out of the instances)

https://www.dropbox.com/sh/jvp4wwek8jpohj7/RlW6hzYqTz

is an example, though you'd need to change your launch scripts to compensate (eg remove build requirements, wget the relevant package for the instance, untar the archive and so on -- though each archive contains each memory size, it's not a simple argument (eg not -m512)).

It's this one here:
https://www.dropbox.com/sh/jvp4wwek8jpohj7/RlW6hzYqTz

It's optimised to your CPU (I'm assuming it does some instruction stuff above normal) and comes in 8M-1024M flavours for Windows, and 8M-2048MB flavours for linux it seems.

On my machine (Core-i7 (no AVX)) I get ~98Col/min with Tydus on 4096M but this one on 1024 gives me 140col/min.

The linux one run on one of Azure's virtuals (4 thread 1024M) gets 52, whereas Tydus' linux-port was only giving me ~35.

Hello,

I did a search of the forum but unfortunately wasn't coming up with much in way of a question this side of the fence.

(This is mostly a question specifically for the algo designer / developers)

I'm interested to know if there is actually a theoretical (eg, based on the algorithm/code specifically) of running with higher memory usage (eg, default is 512, but while some are working toward lower memory usage there is a mod by Tydus to permit 1024/2048/4096 MB RAM per thread.

I haven't seen a terrible difference in collisions/min when testing between these (in fact running with 2048MB appears to be 1-5% more col/min than 4096MB (Which I assume is a memory bandwidth/latency issue).

Generally speaking however what I'd like to know is - all things being equal is more memory actually better per thread where possible? Is there a larger hash table stored in memory to use as a reference? (Meaning that it may be more likely to find a meaningful collision?) or is the thread only going to operate within a small amount of that hash space?

At the moment I'm trying to do some tests myself (Which is as simple as running the program at different settings at ~24H at a time to see if one gets more shares and/or consistently runs higher col/min) but as far as I can tell those statistics would be completely arbitrary as it could be complete fluke whether or not a collision is valid or if there's a pattern to it.

Overall if I don't make sense feel free to ask (or yell at me if it's been explained already somewhere else, I unfortunately wasn't sure what keywords to search for beyond a couple that didn't seem to get me the answer I was looking for).

Thanks,

@MisO69: Oh and if you've got physical/bios KVM access you might want to see how the performance goes with HT turned off, with this program I expect it's hitting the CPU cores at such a statically high rate there's not much room for HT to actually help (unless you've already done it, then feel free to ignore me)

Plus doing that would then penalise the lower-end users (and undo all of the work people have put in to adding the ability to run it at lower memory requirements -- also the theory work for GPU mining, again because of the memory requirements)