为什么ZIP时map时读U盘的速度会这么低？求解

chenall

在GRUB4DOS下读取的速度和启动的引导软件比如PE的SETUPLDR.BIN是不一样的.

加载到内存后会其它引导程序直接从内存中读取.

如果GRUB4DOS下读取的速度比较快,那最终的结果肯定也快.反之则会变慢.

不过我目前遇到的情况都是使用GRUB4DOS会快一些.

再啰嗦一下,不要把不同的环境拿来对比.

比较需要同样的环境才行.否则怎么比都无效.

幸运的草

好吧，就以同一个U盘的ZIP格式，同一台机子，同一个内核的PE，PE就以杏雨梨去A版里的PE。
http://bbs.wuyou.net/forum.php?m ... &extra=page%3D1

您如果有空时，最好亲自测试一下，分别记录一下用G4D引导这个PE，map 与map --mem启动时间，以进桌面为准。
如果是驱动的问题，两者应该使用的是同一驱动。也应该是同一个BIOS模块。这时环境应该一样了吧。
　大家如果有兴趣，都可以进行一下试验，记录一下各自的启动时间。<br />　看各自的数值后再说

zhuyoucheng

看看这里：http://bbs.wuyou.net/forum.php?mod=viewthread&tid=189420&highlight=
早就有人提过了

幸运的草

阶段总结：辩论使问题越来越明了。下面分析一下map 与map --mem的区别，
1、在命令行下输入map。
map (ud)/tantope.iso (0xff) 回车，执行，没反映，无提示。
map --hook 回车，执行，没反映，无提示。
chainloader (0xff) 回车，执行，有提示，但不影响速度。
到此，没有什么读盘动作，也不影响速度。
boot，当然，在菜单下不需此步，回车时，开始读盘，速度很慢。
2、map --mem (ud)/tangope.iso (0xff)回车，执行，开始读盘，速度很快。读完返回。
map --hook
chainloader (oxff) 此两步同1。不影响速度。
boot开始启动，当然数据从内存加载。
问题：1的最后一步的读盘，与2的第一步的读盘到底有什么不同？按道理，读盘这一动作，无论从调用的驱动或模块来说都应该是相同的。那么速度也应该相同，不同之处是1是边读边启动。2是先读到内存再启动。
　　那么这二者为什么对速度的影响那么大？

rockrock99

这个跟dos的smartdrv原理有点类似，先缓存下来，再运行就会快点

sratlf

1的话只是将整个iso文件读入内存中  是整体复制  如同从u盘读取大文件 iso启动后再需要那个文件就是到内存中去读

2的话是iso启动后需要哪个文件就读取哪个文件  是零碎小文件的读取

这两种情况肯定没办法比较的  u盘的一个特性就是零碎小文件读速度低  

就算是极速u盘（仅对usb2.0，使用slc flash的u盘而言）  小体积文件读取速度也很低  更不用说目前市面上主流都是mlc以及越来越多的tlc flash

rockrock99

把两种情况搞反了，，

sratlf

嗯。。。。。  确实是啊  谢谢提醒  不过反了就反了吧  能看明白  意思一样的

chenall

我前面已经说过了,这两种情况没有办法比...而且已经讨论过多次了..

理论上直接map xxx (yy)
然后启动,读取的速度会慢一些,因为需要经过一层的模拟.

若是要比较PE启动到桌面的速度,那真的是没有办法比.再比下去一点意义也没有.

关键在于需要加载的文件大小,比如使用
map --mem xxxx
和
map xxxx
这个XXXX比如是30MB,内核是3MB
来启动一个微内核的PE
肯定是map xxxx的方式比较快.

如果内核也是30MB,那map --mem的速度会比较快.

[ 本帖最后由 chenall 于 2011-10-29 09:08 编辑 ]

rockrock99

我用的PE内核都是超过30M的，所以还是--mem快，但有时候这样会引起内存冲突
在联想T4900V主板上更夸张：
--mem情况：2分钟可以进到PE桌面
不加--mem情况：4分钟过去了，还停留在“Loading RAMDISK image”，无限等待中（不读U盘了）

[ 本帖最后由 rockrock99 于 2011-10-29 13:44 编辑 ]

xianglang

看了34楼的总结，我总算明白了慢不关G4D的事情，而是关PE的事情。既然G4D已经将控制权交给了PE（象40楼的Loading RAMDISK image），这时候G4D都没控制权了——要想在这时候快，我想得NTLDR及NTDETECT.COM都得支持高速USB 2.0才行。

hotdll

我找到了一种变通的方法，一会发新版PE，大家测试下载ZIP机器上的速度。

HB天意

原帖由 hotdll 于 2011-10-29 14:00 发表
我找到了一种变通的方法，一会发新版PE，大家测试下载ZIP机器上的速度。

建议你把变通的方法贴出来。学习学习。

rockrock99

40#的后续

经过10多分钟后，画面终于有了变化， 最终还是进了PE（不是无限等待，是有限等待）

@hotdll
最好是通用的方法，我有特殊原因不能随便换PE，菜单如下：
title 09. Windows PE
map --mem /BOOT/SCSI.IMA (fd0)
map --mem /BOOT/SCSI.IMA (fd1)
map /BOOT/PE.ISO (0xff) || map --mem /BOOT/PE.ISO (0xff)
map --e820cycles=0
map --hook
rootnoverify (0xff)
chainloader (0xff)

其实0PE 1.3.x已经解决了这个速度慢的问题，而且也不会出现B4蓝屏的问题

[ 本帖最后由 rockrock99 于 2011-10-29 15:01 编辑 ]

幸运的草

你的解释我是知道的，但如果是HDD格式的话，速度则会非常快（相对于ZIP格式来说是几倍到几十倍不等，视内核大小不同），这时U盘是同一个，而U盘中的文件大小及零碎程序也是一样的。只是MBR记录不同。
　　根据你的解释为何HDD格式这两种格式速度差异不大呢？

幸运的草

根据你的建议，测试的环境统一了。不知你测试过吧ZIP格式的map ，map --mem启动ISO的时间差？同时如果你测试过，那以再将你的U盘转成HDD格式，在同一台机上测试map 和map--mem这两种方式加载ISO的启动时间，你亲自做过这两种测试，你再下定语，好不好？
　　其他，我真的无语。

倒是＃36的解释有道理，也就是从U盘“边挑文件边启动，影响了读U盘的速度，因为从内存中挑文件的速度远远高于从U盘挑文件的速度快”，这个过程为什么HDD格式时影响非常小？
　　我又不解了。
　　
　

幸运的草

其实你还是没明白怎么回事，我倒推按你的理解是PE的事，那么好，同一个U盘，同一个ZIP格式，同一台机，同一个PE，换用BURG引导，就没有这方面的问题。可见也并不是PE的事。
　　之所以这么说，问题只出在G4D的引导上。也就是说至少与G4D有关。

C大说环境不同，相比无意义，我认为只有不同角度对比，才能将问题最终锁定。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
用G4D同GURG相比，将问题锁定到了G4D。
用ZIP与HDD相比，将问题锁定到了ZIP，
用ZIP的map与zipr的map --mem对比，将问题锁定到了map本身。
而我＃34的总结，又将问题与chainloader (0xff)这条命令锁定了，或许是这两条命令的共同作用导致了问题？
　　根据测试ZIP,map --mem将ISO装载到内存的速度并不低，也就排除了驱动的问题。如果是驱动的问题，那这了阶段的速度慢才对。
而根据HDD时的map速度也不低（略低于同体积内核--mem时，这是正常的。＃36的解释在这里我认为是合理的），也排除了是U盘文件零碎影响速度的结论。
　　所以说，到目前，所有的解释都不是无懈可击

[ 本帖最后由 幸运的草 于 2011-10-29 19:59 编辑 ]

幸运的草

我测试，30M的内核,不加--mem时，ZIP，要12分钟才能启动进桌面，而加参数则不到两分钟。而内核为56M时，加参数3分钟半，不加参数20分钟了还在"loading ramdisk image"界面"，这也是我为什么发此贴的原因，号召大家来抓BUG，出主意，查找排除该问题的“路数”

幸运的草

好了，我也不要什么“无懈可击”的解释，直接提建议：

既然hdd 格式时map 与map --mem速度差异不大
那么是否可以修改现有的map 代码，加上一个什么参数，暂定“hdd”，如果加上--hdd参数，map就强制把ZIP盘按HDD格式去加载，就好比是hdd格式一样，而不加这个参数按现有模式加载。

这样，不用去写什么驱动，也可以解决ZIP　map 慢的问题。
不知，可行？

[ 本帖最后由 幸运的草 于 2011-10-29 20:35 编辑 ]

快雪时晴

很佩服你执着的精神
其实我也有类似疑问
抱着能用就行不深究
希望有解决

幸运的草

总结

在HOTDLL的解释下，到此为止，终于弄明白了ZIP　map慢的问题。
　　
　原因如下，不实之处可以探讨：
     1、G4D是工作在实模式下，没有ZIP的2.0驱动，也不能独立完成对U盘格式的判断，完全依赖于BIOS的判断，调用BIOS的相应模块来读盘。实际的说，就是BIOS给G4D什么，G4D就用什么。
     2、当BIOS判断为HDD模式时，他给G4D的是HDD的模块，这个模块自身带有含硬盘及USB2.0的驱　动，那当然速度就快了。
     3、ZIP格式map --mem时，是一次性的向内存读取ISO文件，即一个文件，而当map无参数时，相当于这个ISO是散开的，要向内存一次性读一个文件，然后校验，再读，再校验，而根据U盘的工作原理，读小文件及文件数目多时，速度是很慢的，这是U启动介质的特点。这时读取速度当然就很慢了，因为一个ISO里面的文件是很多的。文件越大，读取的速度越高。这也就是map --mem时速度快的原因。
　　4、这是历史原因也就是开发时对BIOS的依赖造成的，总这原因很多，这方面不够完善；除非G4D有自身的USB2.0驱动，否则要改变ZIP map慢的问题：无解。
　　如果我的总结不错，我心中的疑问冰释了，就此封贴。
　　谢谢各位的参与及解释。

pseudo

你可以对zip格式做这样的实验：
弄一个文件A.iso，里面仅含B.ISO。
iso足够大，使得两个iso体积差异相对于其绝对体积几乎可以忽略。

然后对比：
情形一：
map /A.ISO (hd32)
map --hook
map --mem (hd32)/B.ISO (0xff)
map --hook
情形二：
map --mem /A.ISO (hd32)
map --hook
map (hd32)/B.ISO (0xff)
map --hook

两个情形都要把一个iso全部读入内存。如果结果时间差异很大，g4d应有改进余地。

xianglang

原帖由 pseudo 于 2011-10-29 23:30 发表
你可以对zip格式做这样的实验：
弄一个文件A.iso，里面仅含B.ISO。
iso足够大，使得两个iso体积差异相对于其绝对体积几乎可以忽略。

然后对比：
情形一：
map /A.ISO (hd32)
map --hook
map --mem (hd ...

我觉得这个测试，比较可靠，因为环境还是在G4D下，而没有改变。

幸运的草

按你的建议，做如下测试，测试PE，仍以杏雨的PE，纯内核36M。制作一个名为TEST的非启动型ISO。里面只有XYLY.ISO一个文件，体积36M。
　
TEST　1　菜单如下：
map (ud)/test.iso (hd32)
map --hook
map --mem (hd32)/xyly.iso (0xff)
map --hook
chainloader (0xff)   注：由于TEST2的第二步不加本命令将不会读盘，鉴于测试的公正性，仍以进桌面为准。
boot

TEST　2　菜单如下
　
map --mem (ud)/test.iso (hd32)
map --hook
map (hd32)/xyly.iso (0xff)
map --hook
chainloader (0xff)
boot

结果：test 1 用时14分16秒。
　　　test 2 用时1分27秒。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
同上：其他条件不变，将U盘转换为HDD格式：

test 1 结果：1分27秒。
test 2 结果：1分26秒。两者有1秒的微小差距，排除人为误差约0.5秒，两者的差异不会超过1秒。

到此为止，测试的结果能说明什么问题，请观者自己判断。

[ 本帖最后由 幸运的草 于 2011-10-30 10:40 编辑 ]

HB天意

看样子zip的只能加--mem参数了。

幸运的草

呵呵！
暂时的变通解决办法：
1、如果你用加速器不死机的话，调用加速器，速度飞快。
以前G4D调用加速器会导致PE1.X在加载时卡死，好像8月30日以后的G4D，这个BUG不知不觉的消失了。现在不卡死了。
2、如果是native版，因为BURG目前不支持NATIVE版，可以调用BURG加参数--mem，加载一级内核，然后转G4D，从仿真盘中加载二级内核（不加参数），速度飞快，不过要对PE进行一点小改造并写一个转换菜单，目前HOTDLL已经试验成功。
3、非NATIVE版的PE，可以直接使用BURG引导不加参数，速度飞快。不用转来转去的。
4、使用传统的加参数--mem的方式启动。
　　

pseudo

原帖由 幸运的草 于 2011-10-30 12:28 发表
呵呵！
暂时的变通解决办法：
...
2、如果是native版，因为BURG目前不支持NATIVE版，可以调用BURG加参数--mem，加载一级内核，然后转G4D，从仿真盘中加载二级内核（不加参数），速度飞快，不过要对PE进行一点小改造并写一个转换菜单，目前HOTDLL已经试验成功 ...

借助burg的方法，0PE一直现成支持。

例如，东西放可见区。0pe.iso仅留“一级内核”（体积几MB），其它散开到iso外就行了。
0pe的组件在iso内还是外，在哪个分区，大体上是自由的（个别组件因为偷懒做了限定），大多可直接移动，不需要修改配置或重新安装。
0pe本身不论zip还是hdd都可适应。BURG加不加参数--mem都行，哪种快就哪种吧。

以往也许你没试过BURG加参数--mem启动小体积0pe.iso的情形。

此外，还可以借助syslinux。也是现成的。

非native pe中，比统一pe快的难找。
native pe一般都比统一pe快，接近plpbt加速后的速度。
0PE_NB是native pe中比较慢的，但也不会慢不到哪里去，所以不大关注速度了。

快雪时晴

如此看来，G4D对zip的支持还是存在很大改进空间的

幸运的草

回复P大：

　　你的0PE，从统一PE，到NBPE，我是比较熟悉的，0PE的设计理念不是普通PE所能及的。而native版的也不是普通版所能及的。
　我说的是普通版的native版。burg目前是不能支持的。

　实际你的0PE也并不是因BURG支持进桌面的。打个比喻，burg是门,而门里的东西仍是grldr，只不过是从burg转到grldr再转到dos再转到grldr，最后启动PE。

　目前发现的普通版的native　PE，　我用BURG引导就没有能进桌面的。所以我说BURG暂不支持NATIVE版的PE。具体原因不详。
至于用BURG加载一级内核转grldr 加载二级内核的方法，是解决G4D在zip格式方面慢又不能使用加速器时的变通办法。如果G4D把这个问题解决了。这个办法也就用不上了。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
　　　
　　0PE的优势之处，相对于普通PE来说，理念是无与伦比的，从综合应用上来说它不仅仅是一个PE，而是一个应用平台，而最近又把最新的技术应用的淋漓尽致；

　　所以我的合盘中，共收录了四个PE；普通03PE即杏雨（老水内核）PE，一个0PE1.31-nb 8.30版，一个tangope native版,一个skype native，这其中只有一个经典的传通PE，三个native版。

好了，以上是几句闲话，纯粹的消遣，没什么意思，请不要见外。　

对了，你让我测试的，我结果报上来了，怎么不见你的评论？

幸运的草

这一点是无容置疑的，关键是能不能改进，开发者愿不愿改进。
本帖的意义就在于，让大家注意这个问题，共同促进改进这个问题。