Jump to content











Photo
- - - - -

preramloading and booting times


  • Please log in to reply
34 replies to this topic

#26 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 18 June 2019 - 05:19 AM

Well, at least we can say we are agree on majority of the items, at least all that really matter:

 

1 - Is Rambooting from a LZ4 compressed fixed size VHD a real improvement compared with an expandable VHD or not?

 

Agree it is faster.

 

Your timing improvement (4 seconds) is better than mine since your VHD is on a SSd and mine on a HDD and also your Ram speed is faster than mine, this also probes I was right on my suspect: I reached the speed limits of reading the HDD and writing to Ram of my PC, reason why I only got about 1/3 of a second of improvement. 

2 - Is the time consumed to build a LZ4 compressed VHD a valid investment or not?

 

Agree it is faster, also agree the smaller the faster.

 

Also you save valuable space if booting from a fast USB 3.0 stick or fast microSD (32 GB) connected to a USB 3.0 adapter (the last was also used on my own tests).

 

 

3 - From my tests I know 1.5 GB is good size for PCs with a minimum of 4 GB of Ram, but is there a way to find a size that fits better in accordance with the Ram available on each PC?

 

Agree the smaller the better.

 

My only comment here is we need to have enought free space on the VHD to let Windows and the programs we will run (as an example browsers) write to their profile an cache (both located on C:) as they do on any OS.  So free space required on VHD seems to vary a lot according with user prefered programs (as an example Chrome require more free space on C: [the VHD loaded on Ram] than FireFox), also if you are planning to watch pictures (let's say using Netflix) we will need additional free space for this. So IMHO the total size of VHD should be determined for the user by means of his own test, I suggest start with a 1.5 GB size wich is close to max size (1.7 GB on my tests, but may vary) for PCs with 4 GB Ram and if required just make a new 1/2 GB bigger size Wimboot VHD in a few minutes, I don't think you will have to go bigger than 4 GB in any case.

 

JFYI I allways try to have about 1 GB free space, but once again each install and user preferences is different.

4 - Is Rambooting from a LZ4 compressed fixed size VHD better for?:

   - Booting from HDD.

   - Booting from SSD.

 

Agree. It is the best option on any case.

5 - Is Rambooting from an expandable VHD better for?:

   - Booting from HDD.

   - Booting from SSD.

 

Agree, Rambooting from a LZ4 compressed fixed size VHD is better.

 

And about the other things you also answered, they were not questions to try to optimice settings from comparing with other people system, those were only some additional comments I made about my own opinion of certain things.  Of course everybody is free to have his own opinion and do things in a different way.
 

alacran



#27 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 18 June 2019 - 08:47 AM

one caveat on browsers: I particularly like maxthon, which is bulky, but I found a portable version that runs on d:\ and holds all password records; of course its cache will be on c:\users...\temp, but I can assure u that if u leave it windows managed, windows manages temp space better than primoramdisk (which I owe to u and is the reason for my getting rid of primoramdisk); if c:\ space ever went red, u could still make c:\ 500megs larger and boot this one from then on. it has never happened to me yet, but it is too early to cry for victory.

one question I have about 64gb vs 32gb ram: would it be any faster with only 32gb? if so, I would spare the wear and tear of 2 sticks of ram.

another question is about svbus.sys: what is the difference between the automated preinstalled version by misty (dism...) and the bios testsigning in terms of speed and practicality?

yet another question is about the automation of persistence when installing things on the vhd without having to recompress it in lz4: has misty managed to make persistence across changes possible? if so, how?

nino 



#28 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 18 June 2019 - 09:29 AM

one question I have about 64gb vs 32gb ram: would it be any faster with only 32gb?

64 GiB RAM!!!! Bloody hell!!!!! I know some people will say that more RAM is better, but how much is actually in use? And given that you are using a compressed .vhd file for RAM Booting, I'm going to assume that this is purely to improve speed of mapping the image to RAM? What about any performance hit with decompressing files in the RAM disk?
 

another question is about svbus.sys: what is the difference between the automated preinstalled version by misty (dism...) and the bios testsigning in terms of speed and practicality?

There is no "automated preinstalled version by misty". The signed drivers referred to in my recent post in the SVNBus topic (here) use the signed drivers from tinybit's post (here), who in turn obtained them from here. The drivers were signed by yamingw and uploaded to bbs.wuyou.net - tinybit very kindly attached them to his post for convenience and access.

I have no idea whether there are any differences in terms of speed. Give it a go and test on your own system.
 

yet another question is about the automation of persistence when installing things on the vhd without having to recompress it in lz4: has misty managed to make persistence across changes possible?

No Misty has not. If you read the post properly then you will see that any changes required for persistence are made to the OS running on a FILEDISK rather than a RAMDISK. I have not even tested using a compressed .vhd file. Changes made to the OS booted from a FILEDISK are persistent. Running from an SVBUS file backed disk (FILEDISK) is not really that different from Windows Native Boot VHD.

:cheers:

Misty

#29 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 18 June 2019 - 10:01 AM

thanks misty for pointing that out, but I still do not understand what the "revert" action is for. I normally make changes persistent on filedisk and recompress the vhd, thus getting a new *.vhd,lz4. 

back to the lots of ram kinda thing, I already tried what u suggested, and I can tell u that even then, smaller has proved to be better (negligible gain in speed for uncompressed (less than 1sec) vs. significant gain in space for compressed (almost half the size, which will be expanded on deployment, as u know). so what is the lots of ram for ...? remember system hangs on previous versions of windows? at that time ram got cheaper, so I decided to have as much ram as possible, even to avoid pagefile. this tradition has lasted so far, and the result has been satisfactory I must say. anyway since I realized only 5% of the ram was regularly used, I once decided to use that space somehow, so I had primocache manage  all disks (I have 4 of them). a few days ago I realized the optimal primocache size is 4096megs (read and write speeds significantly higher than without it), so I reduced cache size from 8192 to 4096. now my question is should I go back to 32gb of ram (the amount of ram I had a decade ago or so) and save 2 of the 4 sticks? would the system be faster in booting and suffer no hindrance in ordinary performance? I do not do any video editing and I do not wanna use a pagefile.

as for svbus.sys, I have used the version u suggested for quite some time now, so whether pre-automated or bios-engineered would not make any difference, would it?

nino



#30 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 18 June 2019 - 03:00 PM

Talking about LZ4 compressed VHDs, only weak point I see in this approach is: It only let you Ramboot (by means of grub4dos 0.46a + SVbus driver), so your LZ4 VHD is inmutable, wich has a lot of advantages when thinking in malware, Disk wear, booting time, etc.

 

Unfortunatelly at the moment the decompression  (-d parameter) on LZ4 is not working fine, even if you get a file with same Sha1 Hash as the source VHD, you can't attach it on Windows or boot from it, for more info see: http://reboot.pro/to...or/#entry211633

 

Today just got an answer about this issue on LZ4 page, and I will try it to see if the suggestion works fine or not, and make public my findings.

 

Also Erwan.l new feature on Clonedisk for LZ4 compress/decompress it is not working fine for Ramboot yet (it only works in legacy mode), also can't decompress LZ4 files created with new format/program.

 

EDIT: Issue decompressing VHD.lz4 files is fixed on new lz4_compressor-190618 See: http://reboot.pro/to...e-2#entry211750

 

alacran


Edited by alacran, 19 June 2019 - 09:30 PM.


#31 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 18 June 2019 - 04:53 PM

well, I have taken 2 of the 4 stick of ram out and rebooted and rambooted. 

so,

as filedisk 17secs, no difference between 32gb and 64gb of ram

as ramdisk 3secs for preramloading and 15 for the booting proper (18secs total), no appreciable difference between 32gb and 64gb.

nino



#32 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 18 June 2019 - 08:03 PM

well, not so well, actually. I have experienced a few system hangs that I thought would be gone forever. I remember experiencing them a decade ago. I am afraid 64gb of ram are necessary for a full multitasking system. I am going to put the 2 sticks back onto my mobo.

nino



#33 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 18 June 2019 - 09:15 PM

At least another law to add to the smaller the better applied to mass storage. well, when it comes to ram, whether u see it or not, whether u like it or not, the greater the better.

nino



#34 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 19 June 2019 - 04:20 AM

At least another law to add to the smaller the better applied to mass storage. well, when it comes to ram, whether u see it or not, whether u like it or not, the greater the better.

nino

 

Be careful with what you say, some people may think you start sounding as a ........., well, I think you understand what I mean. HA, Ha, Ha.



#35 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 19 June 2019 - 04:52 AM

hahahahah, the funny thing is that it looks totally inexplicable. if u look at the ram involvement in resmon.exe, u will see 15-16% with 64gb, as opposed to the 30-32% with 32gb, but the system jerks, especially when playing videos, things typical of the past. I was even forced to reboot once, which is what u would call "anacrónico". I would say my pc started acting .... u know what I mean. I sometimes think programs under windows benefit even from the mere presence of big amounts of ram, probably owing to the lack of that software-->hardware engineering which is possible in the mac world.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users