Jump to content











Photo
- - - - -

Grub4DOS AHCI / NVMe speed patch for memory maps

grub4dos ahci nvme

  • Please log in to reply
44 replies to this topic

#1 schtrom

schtrom

    Newbie

  • Members
  • 20 posts
  •  
    Germany

Posted 27 October 2018 - 03:36 PM

Download-Link: sourceforge.net/projects/grub4dosahcipatch

 

Grub4DOS AHCI / NVMe speed patch for memory maps

This package includes the following directories:
- bin -> compiled grldr version 0.4.5c with AHCI / NVMe support
- patch -> ahcinvme.patch for updating stock grub 0.4.5c source code
- src -> all changed and additional source code files used with grub 0.4.5c

The AHCI and NVMe support can be enabled by using the additional grub menu commands "ahci"
and "nvme". We can set the following parameters with the new commands:

ahci --set-drive=DRIVE --set-controller=CONTR --set-port=PORT [--showall] [--showselected]
nvme --set-drive=DRIVE --set-controller=CONTR [--showall] [--showselected]

Using these commands searches PCI configuration space for all present AHCI / NVMe controllers.
After setting this option every read to DRIVE is redirected to the selected AHCI / NVMe
controller. The CONTR and PORT arguments start at zero, where 0 corresponds to the 1st present
AHCI / NVMe controller / port found. If the option --showall is used, all AHCI / NVMe
controllers, ports and connected devices are displayed. If the option --showselected is used,
the selected AHCI / NVMe controller, port and connected device is displayed. The argument
--uninit uninitializes all AHCI / NVMe controllers. This command was implemented to speed up
transfer rates if an image file is loaded from an AHCI / NVMe SSD and mapped to RAM.

The AHCI / NVMe support can not be disabled anymore during compile with the configure command.
We removed this feature to make the code simpler.

The standard read block size is now always 32 MB, because this is the maximum data transfer
size we can get from an AHCI hard disk device at issuing one read command. If an image file
is mapped to RAM we get a speed of 550 MB/s with a Samsung 840 Pro SSD and 3 GB/s for a
Samsung 960 EVO NVMe SSD.

Pay attention that this AHCI / NVMe addition is only useful if you load the images from SSD to RAM.
Loading a disk image directly or using a normal platter HDD does not increase the read speed much.
Use this patch with care on your own risk!

Because we added some parameters to the AHCI and NVMe command line we wanna show you two sample
menu entries for both RAM disk mappings:

title Win10 - RAMDISK AHCI
ahci --set-drive=0x80 --set-controller=0 --set-port=0 --showselected
find --set-root --ignore-floppies /win10.vhd
map --mem /win10.vhd (hd0)
map --hook
ahci --uninit
root (hd0,0)
chainloader /bootmgr

title Win10 - RAMDISK NVMe
nvme --set-drive=0x80 --set-controller=0 --showselected
find --set-root --ignore-floppies /win10.vhd
map --mem /win10.vhd (hd0)
map --hook
nvme --uninit
root (hd0,0)
chainloader /bootmgr

You should always include the new "--uninit" parameter directly after the "map --hook" command.
This stops the redirection of drive 0x80 (hd0) to the AHCI / NVMe read procedure. The drive
number should always match the real BIOS drive number for the system, otherwise the system may
hang.

Many thanks to all the developers and forum members of reboot pro for making it possible to boot
a full-sized Windows from RAM and harddisk image.

Greets
Kai Schtrom


  • Tokener likes this

#2 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 27 October 2018 - 07:08 PM

Hi Kai

Previous version was very good, thanks for sharing this new build.

I´m going test it in the next days.

 

 Regards   T.



#3 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 28 October 2018 - 05:58 PM

Good.news. :)

 

Only to confirm how grumpy and old I am, and for the record, there is however NO such thing as grub4dos 0.4.5c.

 

There are a zillion versions of 0.4.5c (105 of them on Chenall's site) of which the latest is 0.4.5c-2016-01-18.

 

If this is the patched one (I seem not being able to understand which version it is, all I can find is "GRUB4DOS 0.4.5c 2018-10-27" which is fine, because of the recompiling after the patch), it would be IMHO a good thing to specify which exact version as before or later there would be some mixup of versions (as an example since the patched one has only grldr and not grub.exe).

 

:duff:

Wonko



#4 schtrom

schtrom

    Newbie

  • Members
  • 20 posts
  •  
    Germany

Posted 10 November 2018 - 08:04 AM

Hi Wonko,

 

you are right we are both old and grumpy! The Grub4Dos 0.4.5c versioning is a mess. Therefore I uploaded my code base of Grub4Dos 0.4.5c to sourceforge. At the past I used the SVN repository with revision number 359 to download the base sources. This source code base is contained in the archive named

 

grub4dos_0.4.5c_svn_revision_359_source.rar.

 

It was downloaded some time ago with the following SVN command:

svn co -r 359 http://grub4dos-chen...e.com/svn/trunkgrub4dos

 

The SVN repository with revision number 359 is no longer present, therefore I uploaded it to make building your own GRUB4DOS loader based on my patches easier.

 

I hope this helps someone!



#5 Sinity

Sinity
  • Members
  • 4 posts
  •  
    Poland

Posted 03 February 2019 - 01:14 PM

Hi. I've got a problem with this patch - in your example, you use 'find' command after switching to nvme. When I do that, grub4dos either hangs or there's a reboot. Grub4dos also hangs on 'ls' command, or even typing '(' and then tab. When I run nvme command with '-showselected' option, it seems to correctly detect the controller & drive(samsung 960 evo).

 

I'm trying to use it to boot windows 10 after kexec - unfortunately interrupt 13h doesn't work after that.

 

Only thing that works so far is having windows 10 partition on another, non-nvme ssd. Then I kexec grub.exe(grub4dos, unpatched), with bootable grub2 in initramfs, and chainload that grub2. Then, I use 'nativedisk' command in grub2 which gives me access to all hdd's and ssd's except nvme. I set root&prefix variables to a partition which has your patched 'grldr' file, and I run "ntldr /grldr".

 

At this point, if Windows 10 is on non-nvme partition, I can map that to (hd0), run "root (hd0,0)", and run "chainloader /bootmgr", "boot". And that works.

 

I've also tried to install only windows bootloader on non-nvme partition, and after mapping that partition as (hd0,0) it can read BCD files and such; but it fails on loading /Windows/system32/winloader.exe.

 

I've also found info that this change in linux: https://git.kernel.o...0ca907e50a53d41 is what causes int 13h to fail. But after commenting out code which does that, it still doesn't work.

 

Any ideas how to get it to work?

 

Maybe problem is that after 'nvme' command grub4dos tries to read... something from non-nvme drive? But grldr is just a single binary, so it should be in ram.

 

Also, it's not because if kexec - if I run patched grub4dos from grub2 after a reboot, it also causes hang or reboot. I've also tried putting grldr onto nvme ssd, rebooting, chainloading that and then running nvme command & find. Also causes reboot.


Edited by Sinity, 03 February 2019 - 01:22 PM.


#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 03 February 2019 - 01:27 PM

NOT at all what you asked, but it doesn't seem to me that the "find" is needed at all.

What happens with (i am assuming that the win10.vhd is on (hd0,0)):

 

nvme --set-drive=0x80 --set-controller=0 --showselected
map --mem (hd0,0)/win10.vhd (hd0)
map --hook
nvme --uninit
root (hd0,0)
chainloader /bootmgr

 

:duff:

Wonko



#7 Sinity

Sinity
  • Members
  • 4 posts
  •  
    Poland

Posted 03 February 2019 - 01:44 PM

I don't have Windows image (*.vhd), it's just Windows installed onto a partition. I'm not sure how to apply this example for my situation. Maybe I'd try rootnoverify (hd0,0) directly after "nvme -set-drive=0x80...." command, or run "nvme --uninit" between "nvme..." and "rootnoverify"?

 

I will try it.

 

Edit: I've tried it, didn't work :(

 

Here's what I did exactly, to maximize chances of success:

 

1. I've copied grldr directly onto the same nvme partition as Windows I'm trying to boot

2. I've rebooted.

3. From grub2(which is also on the same nvme partition), I've ran just insmod fat, insmod ntfs, ntldr /grldr, boot.

4. In Grub4Dos, I've tried:

   a) "nvme --set-drive=0x80 --set-controller=0 --showselected", "nvme --uninit", "rootnoverify (hd0,0)", "chainloader /bootmgr"

   b ) "nvme --set-drive=0x80 --set-controller=0 --showselected", "nvme --uninit", "rootnoverify (hd0,0)", "chainloader /bootmgr"

 

 

Result from a): read error 25 or something like that.

Result from b ): reboot directly after running "chainloader /bootmgr".

 

 

I've also tried to enable debugging; only thing of note is that after initializing nvme '(' + tab caused many messages to appear(too many to fit the screen). Something about mismatch between sector count of BIOS and actual sector count, drive geometry etc. These errors also showed after "nvme --uninit".


Edited by Sinity, 03 February 2019 - 02:00 PM.


#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 03 February 2019 - 02:22 PM

Then I don't get it (really I don't get it :frusty: ).

 

The nvme patch is intended to make the loading to RAM faster.

 

If you are NOT loading to RAM it makes no sense whatsoever to use it, just use "normal" grub4dos.

 

The generic  idea is AFAICU:

1) open a "special", "faster", "temporary" channel between nvme and RAM

2) copy (faster) from nvme to RAM

3) close the channel and resume normal operation

 

For *some reasons* in your particular setup the opening (or closing, or both) of this "privileged channel" doesn't work properly, but since you are not copying anything to RAM, you simply don't *need* it.

 

Or am I missing (or you are not telling) something? :dubbio:

 

:duff:

Wonko



#9 Sinity

Sinity
  • Members
  • 4 posts
  •  
    Poland

Posted 03 February 2019 - 05:57 PM

I understand that this patch is intended to do something else, but I'm trying to use it as a nvme driver - an int 13h replacement. Essentially the same thing as grub2's "nativedisk" command - which works for AHCI. Unfortunately grub2 doesn't have nvme driver.

 

"normal" Grub4Dos doesn't work - if I boot it via kexec, then it doesn't detect any drives. Because int 13h doesn't work.

 

I think it is supposed to work. I will try to compile it with some additional logging, to see where it fails.



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 03 February 2019 - 06:15 PM

I understand that this patch is intended to do something else, but I'm trying to use it as a nvme driver - an int 13h replacement. Essentially the same thing as grub2's "nativedisk" command - which works for AHCI. Unfortunately grub2 doesn't have nvme driver.

 

"normal" Grub4Dos doesn't work - if I boot it via kexec, then it doesn't detect any drives. Because int 13h doesn't work.

 

I think it is supposed to work. I will try to compile it with some additional logging, to see where it fails.

Yep, but It is not that it is intended to do something else, it is that it only does something else, which actually prevents its use as a nvme driver, from what I understand, the sheer moment you --uninit it, the nvme loses *everything*.

 

If - for whatever reasons - your kexec kills int 13h (or more loosely BIOS interrupts/services) then grub4dos simply won't work (as it relies on int13h or more loosely on BIOS interrupts/services).

 

In the old times kexec did work by using a passed configfile directive to grub.exe:

http://reboot.pro/to...-kexecgrub4dos/

 

but it may also depend on specific motherboard/BIOS:

http://reboot.pro/to...hat-runs-win10/

 

:duff:

Wonko

 

P.S.: tinybit did start something about the matter, but it wasn't ever followed/it never evolved, so it is a JFYI:

http://reboot.pro/to...exec-l-grubexe/



#11 Sinity

Sinity
  • Members
  • 4 posts
  •  
    Poland

Posted 03 February 2019 - 09:53 PM

Yes, it couldn't work with --uninit. But without uniniting, from the description, it seems like it should just replace the int 13h - like for example grub2's nativedisk.

 

I've noticed that ls (hd0, 3)/ works correctly. Which is my Windows system partition. So I've installed windows bootloader onto that, and I was even able to run chainloader /bootmgr. But after boot it just rebooted my PC. So I think that maybe it doesn't really replace int 13h - just replaces calls to int 13h inside grub4dos itself. Or windows boot loader tries to access partition 0 for some reason.

 

Anyway, I think I've confused myself during all these tests - "nvme" always fails after kexec, grub4dos immediately hangs after issuing it even without any parameters. I thought it worked, but apparently not.

 

I think the only reasonable solutions are somehow patching int 13h so it doesn't fail after kexec, or writing nvme driver for grub2 :(



#12 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 February 2019 - 08:32 AM

If you can "reach" (hd0,3) but the bootmgr in it fails, you may try to use a "Vista boot floppy", i.e. a floppy image containing BOOTMGR and the \boot\BCD that you can store on (hd0,3) and map --mem.

Maybe it works. :unsure:, since it can "find itself" and when the BOOTMGR switches to protected mode and re-enumerates the devices it may find the actual Windows install volume.

 

Anyway, you are also using an additional layer that is GRUB2, which may (or may not) complicate the matter.

 

It is not clear to me if you actually tested exactly the methods in the posts I linked to (that again may or may not work) :unsure:.

 

The only reasonable solution is IMHO to correct the kexec so that it works as it should (and as it used to work, as said).

 

:duff:

Wonko



#13 quarky42

quarky42

    Member

  • Members
  • 38 posts
  •  
    United States

Posted 08 October 2019 - 03:24 PM

I tried using this Grub4DOS AHCI/NVMe version to boot to ramdisk faster using a Vantec USB-C / Thunderbolt 3 NVME Enclosure.   So far I've only been able to achieve 32 MByte/sec and after trying a number of things.

 

In Windows, the enclosure and the M.2 drive that I'm using (Samsung Evo 970) are able to read at 900 MByte/sec.   I am guessing here that the AHCI/NVMe speed patch somehow doesn't apply to NVMe drives connected via the Thunderbolt 3 interface?

 

In Windows, the device is detected as if it were SCSI attached.    I am tryng a new M.2 drive today (and not expecting any different results):  "HP SSD E X950 2TB SCSI Disk Device" is how it shows up in Windows.  Since I do have a different M.2 available, I figured I'd at least give it a try and see if it behaves in a similar manner.

 

Does anyone have any suggestions on how to get faster performance out of booting to ramdisk via a device like this?   My best guess at this point is it is coming down to the USB support in Grub4DOS itself?

 

I may be asking in the wrong thread here; I was hoping that this was related enough that I might get some help in figuring out the best place to ask about this?

 

 



#14 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 08 October 2019 - 07:01 PM

title try
nvme --set-drive=0x80 --set-controller=0 --showselected
map --top --mem (hd0,0)/vhd.vhd (hd0)
map --hook
nvme --uninit
root (hd0,0)
chainloader /bootmgr
 
I have just tried this menu.lst on mine, and ... believe it or not... it flies, at least in the preloading stage; I am not sure it is any faster on the loading stage proper, but the preloading is definitely faster than in the case of lz4 on g4d 4.6. BTW, this new version does not seem to recognize lz4s.
Attaboy!!!
 
Ps: I can also confirm that filedisk loading does not work, at least overhere.


#15 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 October 2019 - 06:28 AM

@quarky42

0.4.6 (but NOT 0.4.5) versions of grub4dos have an internal USB stack/driver but - AFAIK - it is only intended as a replacement for flaky/defective/limited BIOS USB driver and I dont think it offers any noticeable transfer speed increase.

 

@antonino61

Good that you can confirm that the thingy works fine.

Maybe, just maybe, if there are enough confirmations, Yaya or Chenall may include the patch in newer releases of the 0.4.6 series (provided that it is - or can become - compatible with them). 

 

:duff:

Wonko



#16 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 09 October 2019 - 11:35 AM

So u think the increase in preloading speed can vanify the effort of making any compressed version (lz4, gz, or whatever else) work? If so, Alacrán won't be that happy about it, I guess.

nino



#17 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 October 2019 - 12:27 PM

So u think the increase in preloading speed can vanify the effort of making any compressed version (lz4, gz, or whatever else) work?

 

Oh, noes, not again.  :frusty:

 

It is several months that the general concept should have become familiar to you.

 

Can an ultrafast transfer rate outperform transferring less data that needs processing to expand?

 

Yes, if it is enough ultra or if the decompression process is too slow.

No, if it is not enough ultra or if the decompression process is fast enough.

 

Results will be different on different machines, different processors, different mass storage devices, etc., etc.

 

So, Yes and No, it depends, and:

 

 

 

 If so, Alacrán won't be that happy about it, I guess.

 

 Alacran will most probably be absolutely fine with both possible outcomes :) , if I have to guess.

 

And you just won a nomination for the reboot.pro "most irrelevant guess" 2019 Award.

 

:duff:

Wonko



#18 quarky42

quarky42

    Member

  • Members
  • 38 posts
  •  
    United States

Posted 09 October 2019 - 03:51 PM

 

title try
nvme --set-drive=0x80 --set-controller=0 --showselected
map --top --mem (hd0,0)/vhd.vhd (hd0)
map --hook
nvme --uninit
root (hd0,0)
chainloader /bootmgr
 
I have just tried this menu.lst on mine, and ... believe it or not... it flies, at least in the preloading stage; I am not sure it is any faster on the loading stage proper, but the preloading is definitely faster than in the case of lz4 on g4d 4.6. BTW, this new version does not seem to recognize lz4s.
Attaboy!!!
 
Ps: I can also confirm that filedisk loading does not work, at least overhere.

 

 

No.  It does not work with a USB-C / Thunderbolt 3 M.2 NVME drive enclosure.   The computer sees that type of disk as if it were SCSI attached, not NVME.   Numerous attempts to use the NVME or AHCI speed improvements on this type of drive have all failed.  Most of them just hang or the drive isn't detected at all.

 

Is your drive connected directly to the motherboard?

 

 

@quarky42

0.4.6 (but NOT 0.4.5) versions of grub4dos have an internal USB stack/driver but - AFAIK - it is only intended as a replacement for flaky/defective/limited BIOS USB driver and I dont think it offers any noticeable transfer speed increase.

 

:duff:

Wonko

 

Thank you, Wonko.   I tried using my old USB memory key which was about 80 or so MB/s and under the 0.4.6 it too appears to be reading at 32 MB/sec.... seems like USB 2.0 speeds.    Based on your answer it sounds like there hasn't been much in the way of speed improvements found.

 

I was able to finally get the VHD_WIMBOOT methodology to work, in so far that the Windows bootmgr is able to boot windows from the VHD+WIM file.  I have attempted to edit the BCD file on the boot drive (fat32 drive) and the bootmgr EFI file on the VHD+WIM file to try and get it to give me a Grub4DOS boot option so that I can do a RAMDISK boot.   So far I haven't been successful with a purely ramboot with this VHD+WIM, but I'm going to keep working on that today.   My BIOS is only showing me the UEFI boot option and I think there might be an EFI file on the boot partition that I haven't tried editing yet.  I'll post back in a more appropriate thread with that if I am still having trouble.  I am really glad to be able to get the VHD+WIM boot working.  Last time I attempted this it failed to boot every time.

 

I am not sure why I can't legacy boot the fat32 partition though.  That is odd.   My Easy2Boot drive boots legacy just fine.  I've used RMPrepUSB to re-write the grub4dos bootloader onto the fat32, as well.  Didn't help.



#19 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 09 October 2019 - 05:09 PM

@quarky42

yes it is. and it reports it at the outset as nvme.



#20 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 09 October 2019 - 05:33 PM

@ schtrom

Any Grub4dos 0.4.5c version is too old and lacks a lot of improvements of the more recent 0.4.6a versions, I'm using for now grub4dos-0.4.6a-2019-08-01 (wich is not the very last one), it would be better if you could adapt your speed patch for memory maps to 0.4.6a-2019-08-01 or newer.

@ antonino61

I'm totally agree with Wonko answer to your post.

Basically every PC can get different results depending on its specs and also the specs of the device where the file to load in Ram is located.
 

Oh, noes, not again. :frusty:

It is several months that the general concept should have become familiar to you.

Can an ultrafast transfer rate outperform transferring less data that needs processing to expand?

Yes, if it is enough ultra or if the decompression process is too slow.
No, if it is not enough ultra or if the decompression process is fast enough.

Results will be different on different machines, different processors, different mass storage devices, etc., etc.

So, Yes and No, it depends, and:

Alacran will most probably be absolutely fine with both possible outcomes :) , if I have to guess.

And you just won a nomination for the reboot.pro "most irrelevant guess" 2019 Award.

:duff:
Wonko


And as long as we can load a big file faster to Ram (for ramboot), any procedure to get that sounds fine to me.

But I'm not going to run any tests or use this patch since this approach is based on grub4dos 0.4.5c, a very old version and I will loose all new capavilities when dealing with other files on my menu.lst, as on 0.4.6a for file disk booting, files do not require to be contiguous anymore (no more that big PITA).

alacran



#21 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 October 2019 - 06:06 PM

But I'm not going to run any tests or use this patch since this approach is based on grub4dos 0.4.5c, a very old version and I will loose all new capavilities when dealing with other files on my menu.lst, as on 0.4.6a for file disk booting files do not require anymore to be contiguous (no more that big PITA).

alacran

Owww, come on.
 
How difficult can it be to chainload a 0.4.5c grldr or grub.exe from a booted 0.4.6a (and viceversa)? :dubbio:
You know like typing:
 
 
c
kernel /045/grub.exe
boot
 
or a grldr:
 
c
chainloader /045/grldr
boot
:jaclaz:
 
:duff:
Wonko

#22 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 09 October 2019 - 06:15 PM

want me to try this fast version with a plain 15-20gb vhd (no wim+vhd combo)?



#23 quarky42

quarky42

    Member

  • Members
  • 38 posts
  •  
    United States

Posted 09 October 2019 - 07:21 PM

[...]

I am not sure why I can't legacy boot the fat32 partition though.  That is odd.   My Easy2Boot drive boots legacy just fine.  I've used RMPrepUSB to re-write the grub4dos bootloader onto the fat32, as well.  Didn't help.

 

I was pulling out most of my remaining hair... I checked everything I could think of.  Finally, I noticed that the FAT32 partition wasn't marked as Active.    Fixed that, rebooted, and now there is a Legacy Boot option for that partition and I am in the grub boot loader finally.

 

So I guess neither the RMPrepUSB nor the VHD_WIMBOOT made the partition active.  Could that be added to VHD_WIMBOOT to make sure that the FAT32 partition is marked as active?  (I don't mind doing it manually, but it took me a long time to figure out that is why I wasn't getting an option to boot that partition and it seems like something that would be easy to check for and set when applying the image.)

 

I am now getting an error on the end of the RAM Boot section where it is trying to boot the VHD to RAM.    I'll take that over to the other thread though.



#24 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 10 October 2019 - 01:17 AM

well, I did try the smallest workable no-wim&vhd-combo - a standalone 5.7gb vhd; well, 3secs longer overhere, so it is a lot faster to preramload the combo one, which is almost instant.



#25 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 10 October 2019 - 02:17 AM

well, I did try the smallest workable no-wim&vhd-combo - a standalone 5.7gb vhd; well, 3secs longer overhere, so it is a lot faster to preramload the combo one, which is almost instant.

 

Better edit your post because it is not understandable:

 

 

3secs longer overhere, so it is a lot faster to preramload the combo one, 3secs longer overhere,

 

You said it takes 3 seconds longer than a wimboot combo, so then it means the combo is faster.

 

And latter said:

 

so it is a lot faster to preramload the combo one, which is almost instant.

 

How can it be a lot faster if it takes longer time?

 

Especially compared with something that is almost instantaneous?

 

Or do not drink when writing a post. HA, HA, HA.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users