- Joined
- Nov 25, 2008
So I was going to do a write up on how various miners use ram differently but in the process of writing it I more or less licked the issue I was having. So here's what I've got now:
PROBLEM: Can't get any miners to run on my mining rig (1gb system ram). Not sure exactly how much ram is required for mining in general.
SOLUTION: Use threads instead of TC. You only need enough physical ram free to load your desired thread size (TC), but you need enough virtual memory to match all of your total gpu ram use.
WORDS:
So, it seems like you need physical ram to shove the threads into GPU ram. In the case of my mining rig, I can't use more than roundabouts TC 3000 or so. However, I can keep throwing threads at it. So 3072 TC and -g 10 gets me 1900mb or so usage. That's way up from the 500mb or so I could get before. Great! But it's not 3900mb. So increase -g right? Nope, maxes out at 10. Solution? Use multiple instances. Two instances of yacminer -g 10 TC 3072 gets me about 3700mb of ram usage. Much much closer to what I need.
So that's ram usage out of the way, but if you just do this you'll quickly find yourself into a wall of HW errors. Why? I'm 90% sure that raw intensity is calculated per thread rather than on a whole. This is a bit of an issue. You can divide whatever rI you want to use by, in this case 20, but then you are losing accurate rI adjustment, which is crucial for max hash rates for yacoin.
Now the other issue here is virtual memory. All of the miners will use up virtual memory ("System Commit") in proportion to however much GPU ram they are using. Now, I'm not sure if you could just increase your swap size to get around this or not. It all depends on if running this in swap/virtual memory makes a difference in hash rates or not. Judging by running UTC/Scrypt with all of my system ram being used (see pastebin), I'd say it doesn't. Honestly the only reason I don't know for yacoin is it's just so darn unresponsive when you try something like that, but that could very well influence hashing speeds.
TL;DR 4gb of ram should be fine but you might need a 20-30gb swap file.
No idea how any of this works for nvidia cards but I imagine it's a pain.
Sorry to anyone I told you might need more system ram, I had my facts mixed up. It might still be a good idea to get 8gb though...
ORIGINAL POST: Thanks silver!
Additions from the thread:
To rephrase that, I did NOT see a drop in hash rates when running with very little free memory. In fact I believe they were the same. Desktop responsiveness is absolutely terrible though.
PROBLEM: Can't get any miners to run on my mining rig (1gb system ram). Not sure exactly how much ram is required for mining in general.
SOLUTION: Use threads instead of TC. You only need enough physical ram free to load your desired thread size (TC), but you need enough virtual memory to match all of your total gpu ram use.
WORDS:
So, it seems like you need physical ram to shove the threads into GPU ram. In the case of my mining rig, I can't use more than roundabouts TC 3000 or so. However, I can keep throwing threads at it. So 3072 TC and -g 10 gets me 1900mb or so usage. That's way up from the 500mb or so I could get before. Great! But it's not 3900mb. So increase -g right? Nope, maxes out at 10. Solution? Use multiple instances. Two instances of yacminer -g 10 TC 3072 gets me about 3700mb of ram usage. Much much closer to what I need.
So that's ram usage out of the way, but if you just do this you'll quickly find yourself into a wall of HW errors. Why? I'm 90% sure that raw intensity is calculated per thread rather than on a whole. This is a bit of an issue. You can divide whatever rI you want to use by, in this case 20, but then you are losing accurate rI adjustment, which is crucial for max hash rates for yacoin.
Now the other issue here is virtual memory. All of the miners will use up virtual memory ("System Commit") in proportion to however much GPU ram they are using. Now, I'm not sure if you could just increase your swap size to get around this or not. It all depends on if running this in swap/virtual memory makes a difference in hash rates or not. Judging by running UTC/Scrypt with all of my system ram being used (see pastebin), I'd say it doesn't. Honestly the only reason I don't know for yacoin is it's just so darn unresponsive when you try something like that, but that could very well influence hashing speeds.
TL;DR 4gb of ram should be fine but you might need a 20-30gb swap file.
No idea how any of this works for nvidia cards but I imagine it's a pain.
Sorry to anyone I told you might need more system ram, I had my facts mixed up. It might still be a good idea to get 8gb though...
ORIGINAL POST: Thanks silver!
Right, so personally I've been having a few troubles relating to not having enough system ram to feed cards with gobs of vram. It seems like some coins require you to have some vram around, and some don't. Here's what I've tried:
8gb system ram:
YAC starting with lots of free ram
The time isn't quite accurate in this gif, it probably took a good 15-30 seconds to refresh showing that it had stuffed all of the stuff into the GPU ram (GPUz), before it does this the system is very unresponsive.
YAC trying to start with <4gb free ram
System was just about entirely unresposive like this. Windows is trying to juggle ram around everywhere and everything is just completely saturated. Even after disconnecting the internet and YACminer running out of work, things were still laggy.
After killing
System after stopping YAC. It seemed like it was moving stuff out of cache and back into physical memory. I did have a BSOD after this while checking the VM's resposiveness but I believe that was due to my GPU clocks rather than ram.
And this is what task manager logged for the whole thing.
UTC with free mem
UTC without enough free mem
UTC (and normal scrypt, for that matter) doesn't give a hoot about ram usage, apparently. Even if you are using a high TC (all of my testing was done between 24k-30k TC, or at least 3gb ram use with all the other settings) it seems happy to run with windows tossing stuff around between caches and swaps and what have you.
Now the problem with this is, UTC and YAC and, well anything using more than 500mb or so of vram will not start on my mining rig (with 1gb system ram). Doesn't matter if it's nvidia or ATI, it just spits out errors like you gave it way too much TC (settings that would be trying to use >4096mb on my other rig) and it doesn't have enough ram to use.
So, since I don't feel like taking ram out of my daily rig, I'm asking you guys to help. Try testing your systems with less ram or with something soaking up all your ram. If you've got a rig with >8gb of vram and 4gb system ram, try running yacminer with a high TC on all of your cards and see if it sticks or spits out errors. Here are my ideas of ram requirements:
1) You need equal or greater system ram compared to your GPU ram. This seems like it might be true with YACoin.
2) You just need enough to shove threads into the GPU, once they are there it's smooth sailing WHILE I WAS WRITING THIS EDIT: This appears to be the case. On my mining rig I tried a low TC in combination with high threads and was able to soak up just under 2gb of ram on my 240. That said, the system is EXTREMELY laggy and I'm not sure if this is yacminer doing it's thang or because the system is using system ram for something and that's getting hammered. It could be both, as this system is running just one stick and bandwidth is probably limited as it is.
8gb system ram:
YAC starting with lots of free ram
The time isn't quite accurate in this gif, it probably took a good 15-30 seconds to refresh showing that it had stuffed all of the stuff into the GPU ram (GPUz), before it does this the system is very unresponsive.
YAC trying to start with <4gb free ram
System was just about entirely unresposive like this. Windows is trying to juggle ram around everywhere and everything is just completely saturated. Even after disconnecting the internet and YACminer running out of work, things were still laggy.
After killing
System after stopping YAC. It seemed like it was moving stuff out of cache and back into physical memory. I did have a BSOD after this while checking the VM's resposiveness but I believe that was due to my GPU clocks rather than ram.
And this is what task manager logged for the whole thing.
UTC with free mem
UTC without enough free mem
UTC (and normal scrypt, for that matter) doesn't give a hoot about ram usage, apparently. Even if you are using a high TC (all of my testing was done between 24k-30k TC, or at least 3gb ram use with all the other settings) it seems happy to run with windows tossing stuff around between caches and swaps and what have you.
Now the problem with this is, UTC and YAC and, well anything using more than 500mb or so of vram will not start on my mining rig (with 1gb system ram). Doesn't matter if it's nvidia or ATI, it just spits out errors like you gave it way too much TC (settings that would be trying to use >4096mb on my other rig) and it doesn't have enough ram to use.
So, since I don't feel like taking ram out of my daily rig, I'm asking you guys to help. Try testing your systems with less ram or with something soaking up all your ram. If you've got a rig with >8gb of vram and 4gb system ram, try running yacminer with a high TC on all of your cards and see if it sticks or spits out errors. Here are my ideas of ram requirements:
1) You need equal or greater system ram compared to your GPU ram. This seems like it might be true with YACoin.
2) You just need enough to shove threads into the GPU, once they are there it's smooth sailing WHILE I WAS WRITING THIS EDIT: This appears to be the case. On my mining rig I tried a low TC in combination with high threads and was able to soak up just under 2gb of ram on my 240. That said, the system is EXTREMELY laggy and I'm not sure if this is yacminer doing it's thang or because the system is using system ram for something and that's getting hammered. It could be both, as this system is running just one stick and bandwidth is probably limited as it is.
Additions from the thread:
To rephrase that, I did NOT see a drop in hash rates when running with very little free memory. In fact I believe they were the same. Desktop responsiveness is absolutely terrible though.
Last edited:
