找回密码
 注册
搜索
系统gho:最纯净好用系统下载站投放广告、加入VIP会员,请联系 微信:wuyouceo
楼主: 幸运的草

[讨论] 为什么ZIP时map时读U盘的速度会这么低?求解

[复制链接]
发表于 2011-10-28 16:49:33 | 显示全部楼层

回复 #29 幸运的草 的帖子

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

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

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

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

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

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

使用道具 举报

 楼主| 发表于 2011-10-28 18:02:19 | 显示全部楼层

回复 #31 chenall 的帖子

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

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

使用道具 举报

发表于 2011-10-28 18:30:12 | 显示全部楼层

回复 #32 幸运的草 的帖子

回复

使用道具 举报

 楼主| 发表于 2011-10-29 08:21:37 | 显示全部楼层
阶段总结:辩论使问题越来越明了。下面分析一下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是先读到内存再启动。
  那么这二者为什么对速度的影响那么大?
回复

使用道具 举报

发表于 2011-10-29 08:38:05 | 显示全部楼层

回复 #34 幸运的草 的帖子

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

使用道具 举报

发表于 2011-10-29 08:40:08 | 显示全部楼层

回复 #34 幸运的草 的帖子

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

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

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

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

使用道具 举报

发表于 2011-10-29 08:59:31 | 显示全部楼层

回复 #36 sratlf 的帖子

把两种情况搞反了,,
回复

使用道具 举报

发表于 2011-10-29 09:01:36 | 显示全部楼层

回复 #37 rockrock99 的帖子

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

使用道具 举报

发表于 2011-10-29 09:07:11 | 显示全部楼层
我前面已经说过了,这两种情况没有办法比...而且已经讨论过多次了..

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

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

关键在于需要加载的文件大小,比如使用
map --mem xxxx

map xxxx
这个XXXX比如是30MB,内核是3MB
来启动一个微内核的PE
肯定是map xxxx的方式比较快.

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

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

使用道具 举报

发表于 2011-10-29 09:59:23 | 显示全部楼层

回复 #39 chenall 的帖子

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

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

使用道具 举报

发表于 2011-10-29 13:57:28 | 显示全部楼层
看了34楼的总结,我总算明白了慢不关G4D的事情,而是关PE的事情。既然G4D已经将控制权交给了PE(象40楼的Loading RAMDISK image),这时候G4D都没控制权了——要想在这时候快,我想得NTLDR及NTDETECT.COM都得支持高速USB 2.0才行。
回复

使用道具 举报

发表于 2011-10-29 14:00:26 | 显示全部楼层

回复 #40 rockrock99 的帖子

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

使用道具 举报

发表于 2011-10-29 14:07:25 | 显示全部楼层
原帖由 hotdll 于 2011-10-29 14:00 发表
我找到了一种变通的方法,一会发新版PE,大家测试下载ZIP机器上的速度。

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

使用道具 举报

发表于 2011-10-29 14:47:56 | 显示全部楼层

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:41 | 显示全部楼层

回复 #36 sratlf 的帖子

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

使用道具 举报

 楼主| 发表于 2011-10-29 19:25:06 | 显示全部楼层

回复 #39 chenall 的帖子

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

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

使用道具 举报

 楼主| 发表于 2011-10-29 19:54:08 | 显示全部楼层

回复 #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:36 | 显示全部楼层

回复 #40 rockrock99 的帖子

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

使用道具 举报

 楼主| 发表于 2011-10-29 20:34:33 | 显示全部楼层
好了,我也不要什么“无懈可击”的解释,直接提建议:

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

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

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

使用道具 举报

发表于 2011-10-29 21:35:59 | 显示全部楼层

回复 #49 幸运的草 的帖子

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

使用道具 举报

 楼主| 发表于 2011-10-29 22:54:06 | 显示全部楼层
总结

在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慢的问题:无解。
  如果我的总结不错,我心中的疑问冰释了,就此封贴。
  谢谢各位的参与及解释。
回复

使用道具 举报

发表于 2011-10-29 23:30:35 | 显示全部楼层
你可以对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应有改进余地。
回复

使用道具 举报

发表于 2011-10-29 23:49:27 | 显示全部楼层
原帖由 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:19 | 显示全部楼层

回复 #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 编辑 ]
回复

使用道具 举报

发表于 2011-10-30 10:29:16 | 显示全部楼层
看样子zip的只能加--mem参数了。
回复

使用道具 举报

 楼主| 发表于 2011-10-30 12:28:51 | 显示全部楼层

回复 #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的方式启动。
  
回复

使用道具 举报

发表于 2011-10-30 15:24:43 | 显示全部楼层
原帖由 幸运的草 于 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:05 | 显示全部楼层
如此看来,G4D对zip的支持还是存在很大改进空间的
回复

使用道具 举报

 楼主| 发表于 2011-10-30 19:44:11 | 显示全部楼层
回复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版。

好了,以上是几句闲话,纯粹的消遣,没什么意思,请不要见外。  X@8}U9MLE}EBUE273)]9PGF.gif

对了,你让我测试的,我结果报上来了,怎么不见你的评论?
回复

使用道具 举报

 楼主| 发表于 2011-10-30 19:51:10 | 显示全部楼层

回复 #58 快雪时晴 的帖子

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

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|手机版|Archiver|捐助支持|无忧启动 ( 闽ICP备05002490号-1|闽公网安备35020302032614号 )

GMT+8, 2026-4-20 08:54

Powered by Discuz! X5.0

© 2001-2026 Discuz! Team.

快速回复 返回顶部 返回列表