l=[RAM in GB]

A forum to discuss mining pools, features, etc.
Forum rules
This forum is a place to discuss mining pools, features, etc. Topics can include but are not limited to PROHASHING pool.

For the full list of PROHASHING forums rules, please visit https://prohashing.com/help/prohashing- ... rms-forums.
Sumoblei
Posts: 64
Joined: Sat May 29, 2021 8:34 am

l=[RAM in GB]

Post by Sumoblei » Thu Jan 20, 2022 9:46 pm

When using this argument is the ram in gb the total sum of the gpu's mining, or the largest gpu's ram?
Alynn
Posts: 116
Joined: Wed Mar 03, 2021 12:40 pm

Re: l=[RAM in GB]

Post by Alynn » Fri Jan 21, 2022 8:03 am

Sumoblei wrote: Thu Jan 20, 2022 9:46 pm When using this argument is the ram in gb the total sum of the gpu's mining, or the largest gpu's ram?
The argument is there so the system knows the maximum dag size it can assign. So you should use it for your smallest GPU RAM size.
Sumoblei
Posts: 64
Joined: Sat May 29, 2021 8:34 am

Re: l=[RAM in GB]

Post by Sumoblei » Fri Jan 21, 2022 7:34 pm

Kew, maybe that'll straighten up a few things ty ty
User avatar
bMeister1
Posts: 51
Joined: Tue Jun 01, 2021 12:41 pm

Re: l=[RAM in GB]

Post by bMeister1 » Fri Jan 21, 2022 8:24 pm

As Alynn said it is designed to tell the server what the largest DAG size it can use on a given GPU. Specifically, you can use the l= arg on each GPU miner to prevent the server from accidentally giving that GPU a coin to mine with a DAG larger than its VRAM capacity. For example, a 2GB GPU would require the argument l=2. However, I would add that it's really only worth using in Eth-LowMemory since it's the only algo that has multiple coins with different DAG sizes. Etherium effectively only works with 6GB+ cards and Eth Classic only works with 4GB+ cards because of their respective DAG sizes, so there's not much point in using the l= arg in those cases.
Last edited by bMeister1 on Thu Jan 27, 2022 8:07 pm, edited 1 time in total.
Sumoblei
Posts: 64
Joined: Sat May 29, 2021 8:34 am

Re: l=[RAM in GB]

Post by Sumoblei » Thu Jan 27, 2022 3:51 pm

So hat happens when the DAG is damaged (from oc too high) and you continue mining?
User avatar
bMeister1
Posts: 51
Joined: Tue Jun 01, 2021 12:41 pm

Re: l=[RAM in GB]

Post by bMeister1 » Thu Jan 27, 2022 8:22 pm

I'm not entirely sure what happens at that point. Every time Gminer tells me the DAG is damaged while I'm testing overclock settings, I just kill it and tweak the settings until it works. My assumption is that if the DAG breaks then any shares submitted will be invalid since the data being used to process solutions is at least partially corrupted.
User avatar
bdm8181
Posts: 7
Joined: Wed Nov 24, 2021 1:33 am

Re: l=[RAM in GB]

Post by bdm8181 » Tue Apr 19, 2022 12:14 am

bMeister1 wrote: Thu Jan 27, 2022 8:22 pm I'm not entirely sure what happens at that point. Every time Gminer tells me the DAG is damaged while I'm testing overclock settings, I just kill it and tweak the settings until it works. My assumption is that if the DAG breaks then any shares submitted will be invalid since the data being used to process solutions is at least partially corrupted.
that happened with mine a few times and i just let it run, see if it did its own thing and it doesnt, it just continues to default to restarting in 10 seconds, the length of time before it registers the damaged DAG does flucuate though which gave me false hope , and then i just did the same as you killed it, i noticed tohugh that if i change my virtual memory paging file size for the drives from 5604 (default) to 14000 i have 16gb of ram to play with so i just threw a number in, and the damaged dag file from OC error hasnt happened since, im pulling 21.9Mh/s from a msi geforce 1650 4gb ddr5 ventus 68w at 52celcius as we speak... most people are getting 14-19.. and higher temps as well, ive also noticed that the damaged dag happens more when i try and increase the clocks just a little more each time by 5-10 that there is the slightest lag for it to register which is when the miner is suspecting the dag is damaged, but if i do 2-4 increments like 2 for clock and 4 for memory i have no issues, im scared to try and get any more out of mine cause shes offering well more then what shes bargained for ,


Total paging file size for all drives
Minimum allowed: 16mb
Recommended: 5604mb
Currently allocated:14000mb
ovrcast
Posts: 2
Joined: Mon Sep 12, 2022 6:56 pm

Re: l=[RAM in GB]

Post by ovrcast » Mon Sep 12, 2022 6:58 pm

Having trouble with Gminer and 6GB Nvidia card. Is is i=, l=, 1= or capital I=? Currently using lowercaser L = 6 and still getting out of memory errors. What am I doing wrong?
User avatar
Sarah Manter
Posts: 639
Joined: Fri Aug 13, 2021 11:15 am
Contact:

Re: l=[RAM in GB]

Post by Sarah Manter » Tue Sep 13, 2022 7:55 am

ovrcast wrote: Mon Sep 12, 2022 6:58 pm Having trouble with Gminer and 6GB Nvidia card. Is is i=, l=, 1= or capital I=? Currently using lowercaser L = 6 and still getting out of memory errors. What am I doing wrong?
Hello. You are correct that it is lowercase L. What algorithm are you mining with your card? If you're mining Ethash, the DAG size is a little over 5 now, and the OS uses some space, so 6 G cards are starting to have issues with it now from what I've heard. At this point, with Ethash going offline at some point tomorrow probably, if this is the case, you may want to try one of our other GPU algorithms that might work better with your 6 G card.
ovrcast
Posts: 2
Joined: Mon Sep 12, 2022 6:56 pm

Re: l=[RAM in GB]

Post by ovrcast » Tue Sep 13, 2022 11:06 am

I did l=6 but still getting the out of memory error with Gminer.
Post Reply