无忧启动论坛

标题: 为什么ZIP时map时读U盘的速度会这么低？求解 [打印本页]

作者: 幸运的草 时间: 2011-10-28 08:24
标题: 为什么ZIP时map时读U盘的速度会这么低？求解
不确定是否BUG，在这里提出来，看能否解决。
当UD格式为ZIP或BIOS将HDD的格式识别为ZIP时，g4d在map时，速度非常的慢。此时，根据U盘灯的亮度判断是以非常低的速度在读取U盘，而加上--mem参数时，速度将大大的提高，此时，U盘灯非常亮，说明读取U盘的速度很高。
如果是HDD时，有无--mem参数，map时读U盘数据的速度无变化，都能以高速去读取。所以HDD格式时map的速度很高。
不知zip与hdd对map的影响何以这么大？难不成g4d真把zip当成了软驱，以软驱的速度来读盘？
这种现象，在burg中却没有问题，zip与hdd，map时读U盘速度没有区别。

我想知道的是，为什么zip时map读U盘的速度何以会这么低？
举个例子：hotdll修改的tangope.iso native版，zip时 map启动进桌面要2分钟。而hdd时map启动进桌面30秒钟。
杏雨梨云A版普通PE，内核30M，ZIP时，map进桌面12分钟，而map --mem，2分钟进桌面而hdd时map与map --mem速度并不大。

大家如果空，可进行ZIP格式的测试：
以同一个U盘的ZIP格式，同一台机子，同一个内核的PE，按杏雨梨去A版里的PE为测试基准，分别记录一下map 与map --mem该PE进桌面的时间。
http://bbs.wuyou.net/forum.php?m ... &extra=page%3D1

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

作者: hotdll 时间: 2011-10-28 08:32
标题: 回复 #1 幸运的草的帖子
我测试的结果是
fbinst启动，u盘被识别为ZIP或者FD的时候，
无论是map还是Map --mem 速度都是很慢

作者: rockrock99 时间: 2011-10-28 08:34
标题: 回复 #1 幸运的草的帖子
不做UD，ZIP与HDD速度是否也会有差别？

作者: chenall 时间: 2011-10-28 08:54
使用FBINST启动时读取速度是根据FBINST的探测结果比如一次读一个扇区或N个扇区,取决于FBINST的检测结果.

READ 0X82B8 第一个字节的值就是读取速度.

作者: HB天意 时间: 2011-10-28 08:57
加mem参数，我的PE在865的机器上1分25秒进桌面。不加MEM参数，卡死在加载镜像处。所以我一直都是加MEM启动的。

作者: HB天意 时间: 2011-10-28 08:57
补充，我说的是UD版，zip模式。

作者: Plantsoot 时间: 2011-10-28 09:13

原帖由 chenall 于 2011-10-28 08:54 发表
使用FBINST启动时读取速度是根据FBINST的探测结果比如一次读一个扇区或N个扇区,取决于FBINST的检测结果.

READ 0X82B8 第一个字节的值就是读取速度.

fbinst一般默认读取速度是0x3f，如果不是这个值，修改成这个值不知道行不行。

@幸运的草

你那有这个情况，查下识别为zip的时候0X82B8的第一个字节，也就是read 0X82B8 得到结果的最后两位数是啥。
HDD的一般是0xff3f803f

作者: pseudo 时间: 2011-10-28 09:20
后期改下0X82B8处的读取速度值，是否可行？

作者: zxw 时间: 2011-10-28 09:24
改0x82B8处的读取速度值，有条件的可以测试一下，估计不行。

作者: hotdll 时间: 2011-10-28 09:32

原帖由 chenall 于 2011-10-28 08:54 发表
使用FBINST启动时读取速度是根据FBINST的探测结果比如一次读一个扇区或N个扇区,取决于FBINST的检测结果.

READ 0X82B8 第一个字节的值就是读取速度.

楼主测试的时候，并不是fbinst启动的时候
而是g4d接管控制权后，
map iso文件的速度。这个应该与fbinst无关。

作者: Plantsoot 时间: 2011-10-28 09:44
标题: 回复 #10 hotdll 的帖子
还是让幸运的草给出READ 0X82B8的结果先。

作者: 幸运的草 时间: 2011-10-28 09:58
回复6#、7#、8#、9#。

实际前几天就有这个想法，就是想通过修改某处的值来欺骗G4D，达到和HDD时MAP一样的速度，和ZXW进行过讨论。
经测试，ZIP时，
0x82b8的值为0xff3f003f;;
0x82b9的值为0x3ff3f00
0x8280的值为0x00
在命令行下修改这三处的值为
0x82b9=0x3ff3f80
0x82b8=0x803f803f
0x8280=0x80
然后进行磁盘交换
map (fd0) (hd0)
map (hd0) (hd1)
map --hook
map (hd0)/boot/imgs/tangope.iso (0xff)
map --hook
chainloader (0xff)
boot 测试速度依旧，可见修改这几处的值并不会改变速度。

#10说的对，此时，已经G4D接管，与FBINS无关。

作者: pseudo 时间: 2011-10-28 10:18

原帖由 幸运的草 于 2011-10-28 09:58 发表
...
0x82b8的值为0xff3f003f;;
0x82b9的值为0x3ff3f00
0x8280的值为0x00
在命令行下修改这三处的值为
0x82b9=0x3ff3f80
0x82b8=0x803f803f
0x8280=0x80
...

这样修改自相矛盾，达不到目的。
只需
write 0x82b9 0x3ff3f80
就行了，0x82b8处不用动。

作者: 幸运的草 时间: 2011-10-28 10:22
标题: 回复 #3 rockrock99 的帖子
刚做了一个测试，恢复U盘为普通，用【BOOTICE: 引导扇区维护工具】-（v0.9.2011.0501）写入G4D引导，加载同时一个ISO，速度依然很慢，同时FB没什么区别。
目前可以肯定就是G4D方面的问题，排除FBINST，理由有：
1、非FB时用BOOTICE（v0.9.2011.0501）写入G4D引导，是同样的问题。
2、用FB时BURG引导没有这方面的问题。

作者: chenall 时间: 2011-10-28 10:26
if ((fb_status) && (drive == ((fb_status >> 8) & 0xff)))
max_sec = fb_status & 0xff;
else

这里就是读取速度,每次最多读取几个扇区.在fb_status的第一个字节
即 0x82b8 & 0xff

首先启动后看看这里的值是多少,如果是3F那速度应该会比较快(取决于BIOS和FBINST的检测结果)

人为去修改加大值影响应该不是很大,主要还是因为BIOS的限制.

如果修改这个值为1那读取大文件的速度会明显偏慢的.

作者: 幸运的草 时间: 2011-10-28 10:27
标题: 回复 #13 pseudo 的帖子
也测试过，不行，速度依旧。实际几天前和ZXW讨论时就进行过测试，同一台机，同一个U盘，做成ZIP及HDD进行测试。当时ZXW就进行了否定。但我还是进行了测试。证实了他的结论。

实际修改0x82b9的值后，0x82b8的值也会自动改变。

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

作者: chenall 时间: 2011-10-28 10:28
标题: 回复 #14 幸运的草的帖子
看到很多人喜欢那GRUB4DOS和BURG/GRUB2去比.一点意义也没有

因为BURG/GRUB2有自己的驱动,速度一般情况下都会比较快.

而GRUB4DOS是调用BIOS自身的驱动,速度取决于BIOS.

作者: zxw 时间: 2011-10-28 10:36
标题: 回复 #16 幸运的草的帖子
0x82b9的前三位，就是0x82b8的后三位。你的修改是画蛇添足。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
c大的测试版出来了，你应该测试这个测试版。
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=201647&page=7#pid2327637

作者: 幸运的草 时间: 2011-10-28 11:18
标题: 回复 #17 chenall 的帖子
这种比法应该是有意义的。
和BURG比，进一步定位到了G4D本身，排除了BIOS的问题，因为是同一个BIOS。
map 与map --mem对比，进一步定位到了无参数--mem时map本身，因为同一个BIOS，速度肯定也是相同的。

很菜的问题需要弄懂：
1、是不是BIOS有两个模块，HDD模块，ZIP模块，检测到ZIP，就调用ZIP模块，检测到HDD就调用HDD模块，速度是由模块本身来决定的。
2、当G4D接管后，没有MAP时，就已经决定了调用的模块还是MAP时根据8280及82b9的值来决定调用那个模块？如果是后者，能否人为的通过修改该处的值来改变调用模块？
3、加--mem参数map时，为什么没有这方面的问题。ZIP的盘也会高速读盘？而单单是无参数MAP时，按说应该调用的是同一个模块。

为了验证，排除将HDD识别为BIOS的机，没有HDD模块。在可以根据U盘的实际模式正确识别的BIOS的机上试验。
当HDD时，无参数MAP，ISO。速度很快。修改8280值为0x0,82b9的值为0x3ff3f00(原来后两位是80)，并不会因此降速度。
同U，转为ZIP时,正确识别，修改8280值为0x80,82B9的值为0x3ff3f80(原来后两位是00)，也并不会因此增速。

[ 本帖最后由幸运的草于 2011-10-28 11:52 编辑 ]

作者: 幸运的草 时间: 2011-10-28 11:28
注：测试是以第一个修订测试版进行测试的。
用第二个测试版也是一样的结果。

最终问题：

采用G4D引导方式，包括FB、U+，是BIOS给什么模块，G4D就用什么模块还是G4D要什么模块BIOS就给什么模块？
只要这一个答案，其他问题就明了了。

[ 本帖最后由幸运的草于 2011-10-28 11:36 编辑 ]

作者: rockrock99 时间: 2011-10-28 12:07

原帖由 chenall 于 2011-10-28 10:28 发表 <a href="http://bbs.wuyou.net/redirect.php?goto=findpost&pid=2327644&ptid=201709" target="_blank"><img src="http://bbs.wuyou.net/images/common/back.gif" border="0" onload="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open(this.src);}" onmousewheel="return imgzoom(this);" alt="" /></a> 
看到很多人喜欢那GRUB4DOS和BURG/GRUB2去比.一点意义也没有 
 
因为BURG/GRUB2有自己的驱动,速度一般情况下都会比较快. 
 
而GRUB4DOS是调用BIOS自身的驱动,速度取决于BIOS.

chenall说到点子上了，驱动的问题，假如速度慢了，建议加--mem，这样确实会比不加的快

作者: 幸运的草 时间: 2011-10-28 12:16
标题: 回复 #21 rockrock99 的帖子
问题是为什么加了--mem就会快，是不是加--mem与不加--mem调用的不是同一个驱动模块？

主要是不明所以。

加上--mem的问题是如果镜像大了。内存偏小就没法执行。同时也会由于内存方面的冲突也会造成启动失败，有反映加--mem启动失败而不加--MEM成功例子。
当然也可以用加速器，速度也是很快的，但这不属于本贴讨论的范围。

作者: rockrock99 时间: 2011-10-28 12:32
标题: 回复 #22 幸运的草的帖子
用最新版的grldr，plop加速器（包括P大的封装）都失效了，要不没有加速效果，要不死机

作者: 幸运的草 时间: 2011-10-28 13:32
标题: 回复 #23 rockrock99 的帖子
我用22日的GRLDR，P大的USB_ACC.0PE，测试正常。在我的ZIP机上加速明显。

作者: rockrock99 时间: 2011-10-28 14:29
标题: 回复 #24 幸运的草的帖子
我用22日的GRLDR，Plop 5.0.12，联想T4900V（怀疑是USB-ZIP模式）加速效果明显，可以正常启动PE；技嘉EG31-S2加速载入，但导致不能进入PE

[ 本帖最后由 rockrock99 于 2011-10-28 14:37 编辑 ]

作者: zhuyoucheng 时间: 2011-10-28 14:33
标题: 回复 #25 rockrock99 的帖子
只要用PLPBT加速成功，启动后都是USBHDD了。

作者: 幸运的草 时间: 2011-10-28 15:09
标题: 回复 #26 zhuyoucheng 的帖子
是的，加速后，查看8280及82B9的值，确实是HDD。

这也给我们解决ZIP MAP速度慢带来了一线希望。也就是PLBPT如何修改使ZIP变成了HDD?，这是关键的，至于加载了2.0的驱动是另外的问题。

也就是在G4D下是可以改变ZIP为HDD的。

[ 本帖最后由幸运的草于 2011-10-28 15:14 编辑 ]

作者: hotdll 时间: 2011-10-28 15:56
标题: 回复 #27 幸运的草的帖子
加载plbpt是加载驱动的过程。
加载plbpt的时候，grub4dos将系统控制权交给plbpt，plpbt加载usb2.0驱动后又把系统控制权交个指定的引导设备。

这个过程,内存中的设备信息被更新了。所以g4d获取的设备是usb-hdd。

除非有人开发grub4dos的usb2.0驱动，否则无解。

作者: 幸运的草 时间: 2011-10-28 16:27
标题: 回复 #28 hotdll 的帖子
如果是驱动的问题导致ZIP格式MAP速度慢，是可以理解的。也是正常的。但为何加参数--mem就会很快。难道加了--mem参数就有了驱动？

有空时可以找个内核为30M左右的普通PE。（内置式的，不是外挂的那种）就以杏雨梨云A版中的那个PE。
将U盘做成ZIP格式，分别测试下单map时与加参数--mem时的启动速度，以进入桌面为准就知道了。
我测试加参数1分钟多一点，不加参数要12分钟。内核如果更大，两者的速度差就更大了。当然根据机型的不同，差异也不同。以同机同U盘为例对照。

少驱动应该这两种方式差别不会很大吧。MAP慢一点也是正常的。

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

作者: 幸运的草 时间: 2011-10-28 16:35
以你修改的tangope.iso native版为例，不加参数map 进桌面2分钟。加参数67秒进桌面（我增大了二级内核，ISO体积由23M增大到30M，不增大是57秒）。
HDD加参数与不加都是30秒。

都是ZIP格式，加与不加参数，何以速度差异那么大？

[ 本帖最后由幸运的草于 2011-10-28 16:38 编辑 ]

作者: chenall 时间: 2011-10-28 16:49
标题: 回复 #29 幸运的草的帖子
在GRUB4DOS下读取的速度和启动的引导软件比如PE的SETUPLDR.BIN是不一样的.

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

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

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

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

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

作者: 幸运的草 时间: 2011-10-28 18:02
标题: 回复 #31 chenall 的帖子
好吧，就以同一个U盘的ZIP格式，同一台机子，同一个内核的PE，PE就以杏雨梨去A版里的PE。
http://bbs.wuyou.net/forum.php?m ... &extra=page%3D1

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

作者: zhuyoucheng 时间: 2011-10-28 18:30
标题: 回复 #32 幸运的草的帖子
看看这里：http://bbs.wuyou.net/forum.php?mod=viewthread&tid=189420&highlight=
早就有人提过了

作者: 幸运的草 时间: 2011-10-29 08:21
阶段总结：辩论使问题越来越明了。下面分析一下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 时间: 2011-10-29 08:38
标题: 回复 #34 幸运的草的帖子
这个跟dos的smartdrv原理有点类似，先缓存下来，再运行就会快点

作者: sratlf 时间: 2011-10-29 08:40
标题: 回复 #34 幸运的草的帖子
1的话只是将整个iso文件读入内存中  是整体复制  如同从u盘读取大文件 iso启动后再需要那个文件就是到内存中去读

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

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

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

作者: rockrock99 时间: 2011-10-29 08:59
标题: 回复 #36 sratlf 的帖子
把两种情况搞反了，，

作者: sratlf 时间: 2011-10-29 09:01
标题: 回复 #37 rockrock99 的帖子
嗯。。。。。确实是啊谢谢提醒不过反了就反了吧能看明白意思一样的

作者: chenall 时间: 2011-10-29 09:07
我前面已经说过了,这两种情况没有办法比...而且已经讨论过多次了..

理论上直接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 时间: 2011-10-29 09:59
标题: 回复 #39 chenall 的帖子
我用的PE内核都是超过30M的，所以还是--mem快，但有时候这样会引起内存冲突
在联想T4900V主板上更夸张：
--mem情况：2分钟可以进到PE桌面
不加--mem情况：4分钟过去了，还停留在“Loading RAMDISK image”，无限等待中（不读U盘了）

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

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

作者: hotdll 时间: 2011-10-29 14:00
标题: 回复 #40 rockrock99 的帖子
我找到了一种变通的方法，一会发新版PE，大家测试下载ZIP机器上的速度。

作者: HB天意 时间: 2011-10-29 14:07

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

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

作者: rockrock99 时间: 2011-10-29 14:47
标题: 40#的后续
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 编辑 ]

作者: 幸运的草 时间: 2011-10-29 19:10
标题: 回复 #36 sratlf 的帖子
你的解释我是知道的，但如果是HDD格式的话，速度则会非常快（相对于ZIP格式来说是几倍到几十倍不等，视内核大小不同），这时U盘是同一个，而U盘中的文件大小及零碎程序也是一样的。只是MBR记录不同。
　　根据你的解释为何HDD格式这两种格式速度差异不大呢？

作者: 幸运的草 时间: 2011-10-29 19:25
标题: 回复 #39 chenall 的帖子
根据你的建议，测试的环境统一了。不知你测试过吧ZIP格式的map ，map --mem启动ISO的时间差？同时如果你测试过，那以再将你的U盘转成HDD格式，在同一台机上测试map 和map--mem这两种方式加载ISO的启动时间，你亲自做过这两种测试，你再下定语，好不好？
　　其他，我真的无语。

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

作者: 幸运的草 时间: 2011-10-29 19:54
标题: 回复　＃41　xianglang (风中老狼)
其实你还是没明白怎么回事，我倒推按你的理解是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 编辑 ]

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

作者: 幸运的草 时间: 2011-10-29 20:34
好了，我也不要什么“无懈可击”的解释，直接提建议：

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

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

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

作者: 快雪时晴 时间: 2011-10-29 21:35
标题: 回复 #49 幸运的草的帖子
很佩服你执着的精神
其实我也有类似疑问
抱着能用就行不深究
希望有解决

作者: 幸运的草 时间: 2011-10-29 22:54
总结

在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 时间: 2011-10-29 23:30
你可以对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 时间: 2011-10-29 23:49

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

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

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

作者: 幸运的草 时间: 2011-10-30 10:23
标题: 回复 #52 pseudo 的帖子
按你的建议，做如下测试，测试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天意 时间: 2011-10-30 10:29
看样子zip的只能加--mem参数了。

作者: 幸运的草 时间: 2011-10-30 12:28
标题: 回复 #55 yidawpf 的帖子
呵呵！
暂时的变通解决办法：
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 15:24

原帖由 幸运的草 于 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中比较慢的，但也不会慢不到哪里去，所以不大关注速度了。

作者: 快雪时晴 时间: 2011-10-30 18:27
如此看来，G4D对zip的支持还是存在很大改进空间的

作者: 幸运的草 时间: 2011-10-30 19:44
回复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版。

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

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

作者: 幸运的草 时间: 2011-10-30 19:51
标题: 回复 #58 快雪时晴的帖子
这一点是无容置疑的，关键是能不能改进，开发者愿不愿改进。
本帖的意义就在于，让大家注意这个问题，共同促进改进这个问题。

欢迎光临无忧启动论坛 (http://wuyou.net/)