Check out the STEP ENBSeries INI Guide for additional information on memory and ENB values (added 2015-01-24)
JawZ has a great guide for ENBs - check it out so you can learn to empower yourself in managing ENB settings and tweaks.
Updated note on Reserved Memory Size settings from Boris - 512 is recommended for x64 for smoother framerates when video memory size is relatively low compared to texture mods installed. For x86 os this value must be small to keep off the game from ctds.
More VRAM and MEMORY quotes from Boris (most recent update 2015-05-22)
Again Boris is reiterating that the forumula for VRAM and Memory that was used in the past is incorrect.
There is no math actually, because amd and nvidia have different amount of shared video memory dependent from os and amount of ram. When i wrote long time ago how to calculate this, information was based on pc with relatively low amount of ram. As i said in previous post, texture memory size is valid value, otherwise it can be seen by some utils. If amount of memory set is too big, mod will work properly, but in the case of no more free memory available it will lead to delays to free some space and this process is repeatable, so stuttering in other words.
Boris was asked if the following was still true from 2013:
ReserveMemorySizeMb is the minimal amount of memory for textures and geometry which will not be used by my memory allocations. For example, you have 6 Gb or memory for textures and meshes, mod use it as much as possible without allocating RAM, but when free memory left less than ReserveMemorySizeMb, mod begin to use allocations in RAM to keep free space for dynamically loaded-unloaded resources. The benefit is in safer work, the downside in performance if value is too low (resources must be moved to and from vram/ram). The problem is that drivers report values not very nice for performance by adding part of system memory to video memory, so if textures and meshes created in RAM by driver instead of VRAM, then performance is awful when rendering them. I don't know how to fix that, because even render targets can be made in RAM actually (at least saw this on gf9600gt).
He said yes:
It still correct. Reserved memory is a last room of free space in video memory. When no vram left, this means resources cannot be created in vram. Windows itself, videodriver, crapware, browsers - all these need vram and reserved memory is the only available for sharing with them and for fast loading/unloading frequently changing resources. It also reduce issues with vram fragmentation, when available vram statistics fails.
He also said the old forumla of VRAM + RAM - 2048 does not work (http://enbseries.enbdev.com/forum/viewtopic.php?p=62060#p62060)
It do not work, was made by me only for certain systems. Total memory available for videocard can be viewed by special tools as summ of vram and some ram (minus os memory and some software, like browsers), so use it (autodetect vram size also compute this, probably i need to write it to statistics window). For stable performance (but stuttering at some conditions), set size a bit lower than vram size.
Recent chats at ENBDEV.COM and with DpSlothKing (who exchanged PM's with Boris) has provided more current memory settings. Thanks to Dpslothking for the updates.
I have since emailed Boris back and forth and he has confirmed:
32-bit & 64-bit users with less than 8 GB RAM [VRAM + System RAM] - 
64-bit users with 8 GB RAM or greater [Total Available Graphics Memory] -  for windows 7 users and [Total Available Graphics Memory] -  for Windows 8 or Windows 10 users.
Results will vary of course depending on hardware, skyrim ini settings and misc other things but these are the most up to date and recommended settings.
Set VideoMemorySizeMb to 0 if you want ENB to automatically adjust a value, however it may not necessarily have good impact on performance (depends on machine to machine). The max value for this parameter is 10 GB or 10240 MB (anything above has no meaning).
SLI/CrossFire's VRAM is dependant on the lower value of VRAM for the card setup: if you have a GTX 670 w/ 4 GM VRAM and another GTX 670 w/ 2 GB of VRAM, you have an effective 2 GB of VRAM to play with. Likewise, ENB will consider 2 GB as your VRAM.
Added 2015-01-24: This thread discusses long loading screens and some general information on unsafememoryhacks and other memory settings: http://enbseries.enbdev.com/forum/viewtopic.php?f=20&t=3658
Ssd or hdd doesn't matter for loading screen times with mod installed, because it do not use io at all. Without memory manager it only increase loading times by recompiling and patching shaders, which is totally cpu dependent and fast even for amd cpu like mine (unless you don't have crapware or antivirus). With memory manager enabled it waste time to move data to enbhost.exe, which is about 1.5-2 times longer loading. When compression enabled in memory manager, this increases in about 1.5 times. And if you don't have enough ram with memory manager enabled, of course loading screens will take much longer.
Hi Boris, when you say 'With memory manager enabled it waste time to move data to enbhost.exe', do you mean when DisableDriverMemoryManager=true?
I mean, should load times be faster with DisableDriverMemoryManager=false?
No, unsafe memory hack parameter only disabling this.
Many of these found by doing a search on parameter names, much of the below came from this thread.
ExpandSystemMemoryX64=true - invalid description. As i don't have x64 OS and heard about 3.1 gb limit (which is 4 gb), couldn't test myself with VMMap, so thought it's bug in game engine when some buffer pointer used in math, so i did this variable to fix issue by using memory range of 3-4 gigabytes. At same time this greatly reduce memory fragmentation, but effective only for x64 systems as they give 4 gb of virtual address space for 32 bit applications (winxp allow to set 4 gb, but it's very buggy mode and not recommended). I don't know how to describe this to users, but seems this parameter always work for everybody, so let it be true always, some users report that even this enough against their problems.
DisableDriverMemoryManager=false - again wrong, this depends from drivers, os and videocard. Fewer chances to get CTD or low performance if driver is bad and if it have own memory manager. But if driver is good, on the contrary it can give stable work and better performance. Also when set to true, d3d will try to do everything to not show any errors, at cost of performance or long freezes, so it's kind of "do or die" parameter, while set to false it's like "you can't? okay, ctd". Replace management of drivers by ENB's. May help for stability, especially in Skyrim. If you used a memory tweak by Boris, it's absolutely needed for AMD config using his memory tweaks as he develops with NVidia GPU. So he made this hack to improve compatibility.
DisablePreloadToVRAM=false - wrong again. Faster loading times because textures and geometry not actually created when game loading, they are creating only when visible in camera. Side effect is stuttering when object not in memory, but very useful when saved game won't load because of too much data in cells (imho simpler just to set lower quality, go to other place to save). Cell transition take longer time only when new cell objects are visible immediately, so not always valid definition.
EnableUnsafeMemoryHacks=false - yes, again. This is for videocards with a lot of video memory, because this mode is if player don't want to have any stuttering, any side effects (except alt+tab issue) or by some reason this set to false not work (reason actually other software). This mode also perfect if user have disbalanced system like 32 bit OS and videocard with 4 gb video memory. This mode don't use dynamic memory reallocation, so no compression, no enbhost.exe. Also it work only when ReduceSystemMemoryUsage=true set.
ReservedMemorySizeMb - this depends too much from 32/64 bit system and vram size. Smaller - less ram usage of the game (fewer CTDs), but bigger in most cases means less stuttering in very heavy areas where many mods used (and ugrid too high). If user have 512 mb of vram, this value 512 is also nice, because entire video memory will be dynamic, it's already small for heavily modded game, so better to not block it by static data. As i understood from posts, lower value also helps to some users with infinite loading screens (perhaps they happen because i'm forcing in cycle to free old memory and try again to allocate for new resources). 2014-03-26: 512 is recommended for x64 for smoother framerates when video memory size is relatively low compared to texture mods installed. For x86 os this value must be small to keep off the game from ctds
Update on RMS 2014-08-16 with some more detail:
ReservedMemorySizeMb is amount of dynamic video memory, which have dublicate in system memory. Bigger value give less stuttering and delays when you don't have enough vram for game, but it also increase ram usage so less stability and effectiveness of enboost code. Value is individual for each pc and game because of too many combinations of mods installed, quality options of the game, hardware and drivers, but if you have sometime extremely huge fps drops, try to change this parameter, f.e. 1.5 times smaller or bigger.
VideoMemorySizeMb - this is very unique for each system. What you wrote is correct, but not for users like Goliatron. Other d3d9 mods, web browsers, many other software want to use vram too and bad drivers add more headache. Almost all systems have vram available greater than physical vram, but some users reporting driver errors when vram is completely filled up with data (above i wrote why). If system is clean and only game is running, this value can be very huge, for example 16384 should work for rig with gf660 2 gb + 16 gb ram. But! If you have 6144 for 4 gb of ram and 2 gb vram, don't even think about running something else while playing, because there is a huge chance that non local video memory (ram actually) size will reduce because of other application and you will get very low performance or CTD.
Update 2014-02-02 (more on autodetect memory):
EnableCompression=true // leave this at true or your game will eat more memory.
AutodetectVideoMemorySize=false // --> only exists for ENB 243 and up. Try setting to true and set ReduceSystemMemoryUsage=true. Will autodetect your memory needs.
AutodetectVideoMemorySize=true set size of VideoMemorySizeMb internally to size of shared VRAM, which is physical VRAM + RAM used by display driver. From Boris: VideoMemorySizeMb is ignored when AutodetectVideoMemorySize=true is set. In this case mod trying to preallocate as much video memory as possible to detect it size, i tried that in some previous versions also, but own d3d memory manager stop working properly after that, because it's not designed for memory above 4 gb, so in 0.243 i starting another device to read that information, then destroy it (how this will affect other software like browsers or Optimus, i'm curious).
What happens is the system is running out of memory and hanging. Any save that has more memory will load better. Afterwards the other saves load as the system has already got a lot of basics loaded. The first load of any game is the worst as it is the most demanding. The memory issue can come from a corrupt game, improper settings in your ENBLOCAL.INI file, to many textures, or some other issue causing the game to take to long to load and creating a CTD or freeze.
When it comes to fixing it well there are a couple of things. The very first thing I would try is the safety load mod which helps a lot with this type of issue:
Next, if you use SKSE, make sure you have the script clean up installed. This just means creating (or editing existing) SKSE.INI file. Go to your "\Skyrim\Data\SKSE" folder (if you don't have an SKSE folder just make it). Then edit (or make with a simple text editor like notepad) the SKSE.ini file and add this line:
Over time that helps keep scripts under control.
Next make sure whatever ENB you use that you always set the MEMORY settings correctly for your PC. In version 243 Boris added a new auto-detect flag for detecting the proper memory settings, however this won't work unless you are using the most current ENB *and* you have enabled the flag for it as it is disabled by default.
Here is a sample enblocal.ini section with the newest flag - if you have an older one then you won't see that line of code.
EnableOcclusionCulling=true // --> only exists for ENB 243 and will increase performance on your PC by 5-10fps in some cases
DisableDriverMemoryManager=false // this flag determines whether the game memory manager is used
DisablePreloadToVRAM=false // if true will reduce stuttering but if false can help with loading large saves.
EnableUnsafeMemoryHacks=false //only really needed by AMD users or Titan users
ReservedMemorySizeMb=256 // 256 seems to be the optimal size unless you have very little video memory then try 128, see quote below.
VideoMemorySizeMb=0 // if 0 game will use default. Best formula is your Video Memory Size - 128 MB
EnableCompression=true // leave this at true or your game will eat more memory.
AutodetectVideoMemorySize=false // --> only exists for ENB 243. Try setting to true and set ReduceSystemMemoryUsage=true. Will try to autodetect your memory needs.
One thing that may help is the "DisablePreloadtoVRAM" flag, Boris says "but very useful when saved game won't load because of too much data in cells (imho simpler just to set lower quality, go to other place to save)." Setting to false can mean faster load times because objects are not created when game is loading - instead they are only made when the camera can see them. Downside is some possible stuttering as you are then loading the objects after the saved game has loaded and started. However it can help with loading saved games due to memory issues because the objects won't be loaded as part of the save and hence not as much memory needed.
ReservedMemorySizeMb - this depends too much from 32/64 bit system and vram size. Smaller - less ram usage of the game (fewer CTDs), but bigger in most cases means less stuttering in very heavy areas where many mods used (and ugrid too high). If user have 512 mb of vram, this value 512 is also nice, because entire video memory will be dynamic, it's already small for heavily modded game, so better to not block it by static data. As i understood from posts, lower value also helps to some users with infinite loading screens (perhaps they happen because i'm forcing in cycle to free old memory and try again to allocate for new resources).
Parameters of sss now work like following:
Amount - amount of sss in general.
EpidermalAmount - it's how much light upper layer use, real life examples hard to enumerate, nothing came to mind except skin itself, because it have brighter semitransparent layer of skin and it differ from bloody meat under it. Defintely wax, milk and similar simple things don't need this variable to be used (but how to do this in skyrim without making special enb only code and changes in models accordingly?).
SubdermalAmount - this is kind of transclusency of material to the light, including back side lighting (i didn't separation to back lighting, it linked to this variable, because back lighting control only reduce realistic look of skin). The main idea to use this to simulate light passed through the bloody flesh, but it also proper for wax. I don't use distance based coloration now, but when will do, this parameter may require to have different value.
EpidermalDiffuseSaturation, SubdermalDiffuseSaturation - these both work the same, they get diffuse texture (albedo) of model and apply saturation to it. Normal skin color turn to red, that's the base idea behind this. Recommended to use SubdermalDiffuseSaturation only as it fit better to skin lighting.
EpidermalMix - this is NOT amount of epidermal sss lighting, it's how it's blended with vanilla skin and subdermal. Important, epidermal applied after subdermal lighting, so bigger values covers subdermal lighting (so bigger SubdermalAmount or SubdermalMix can be set).
SubdermalMix - this is NOT amount of subdermal sss lighting and it not work like EpidermalMix. If value is low, then light is almost completely go through and lit only back sides. When it's bigger, then more light return on to surface. Bigger values give less realistic look of skin (except balls), so better keep realtively low with higher SubdermalAmount as compensation.
Good article on how it works: Human Skin - the Mental Ray Subsurface Scattering Fast Skin shader
Enabling edge antialiasing in enbseries and fxaa in game video options will make twice more blurred image/edges.