优化pxe启动过程中tftp的传输速度

2013whoo

一般的pxe启动过程中，tftp的传输速度非常之蛋疼。 不堪其陋，一番捉摸后，找到了有效的改进方法。 虽然不能用完整个网卡的百兆带宽，但有个50，60，跟原来相比也是天壤之别了。

原文较长，发在这儿了。
http://blog.csdn.net/whoo/article/details/8571550

可惜在csdn无人关注，于是跑这儿来特地注册个账号，跟同好分享下。

feifanll

飘过
.飘过
..飘过
...飘过
....飘过
.....飘过
......飘过
.......飘过
........飘过
........飘过
........飘过
.......飘过
......飘过
.....飘过
....飘过
...飘过
..飘过
.飘过
.飘过
.飘过
..飘过
...飘过
....飘过
.....飘过
......飘过
.......飘过
........飘过
........飘过
........飘过
.......飘过
......飘过
.....飘过
....飘过
...飘过
..飘过
.飘过
.飘过
.飘过
..飘过
...飘过
....飘过
.....飘过
......飘过
.......飘过
........飘过
........飘过
........飘过
.......飘过
......飘过
.....飘过
....飘过
...飘过
...飘过
..飘过
.飘过
.飘过
.飘过
..飘过
...飘过
....飘过
.....飘过
......飘过
.......飘过
........飘过
........飘过
........飘过
.......飘过
......飘过
.....飘过
....飘过
...飘过
..飘过
.飘过
.飘过
.飘过
..飘过
...飘过
....飘过
.....飘过
......飘过
.......飘过
........飘过
........飘过
........飘过
.......飘过
......飘过
.....飘过
....飘过
...飘过
..飘过
.飘过
.飘过
.飘过
..飘过
...飘过
....飘过
.....飘过
......飘过
.......飘过
........飘过
........飘过
........飘过
.......飘过
......飘过
.....飘过
....飘过
...飘过内容

2013whoo

如楼上所愿：

        优化pxe网启动时tftp的传输速度 --- 针对pxelinux和bootmgr               
    作为一名IT人士，一般的计算机维护当然不好意思找别人。 于是自己用pxelinux搭了个网络启动环境，可以启动各种WinPE，以供折腾电脑系统，刷新固件的需要。

    只是一般的网络启动都是基于tftp协议的，传输文件那叫一个慢。启动时光是加载映像文件就得几分钟，简直就像活在史前一样。 找了一圈方法，没辙。 好在这东西也就救急时用用，凑活凑活也行。

   于是就这么凑错了几年。。。

   最近升级到win8了，为了维护环境，加了几个win7,win8的PE。 winxp的pe就在启动菜单上无比折腾（要到二进制文件里去改），win7也没好到哪儿去。但是新的bootmgr本身 提供了启动菜单，   为了简单起见，干脆放弃了在pxelinux里集成多个winpe的菜单了，直接单弄一个目录直接启动bootmgr。需要的时候切换下目录就行了，比强行改二进制文件，然后弄到pxelinux菜单上不知道轻松多少倍。

   好了，那就从bootmgr的菜单折腾起。过程比较无趣繁琐，一带而过：随便找个例子教程照着改；结果似乎有时好使有时不好使，原因不明；一怒之下把BCD的规范定义翻了个遍； 问题解决了，原因也搞明白了；顺带着还有个意外的收获。

   这个意外的收获就是发现在BCD的定义中，有两个涉及到TFTP的参数，分别是 windows size 和 block size。当时一看到这两个参数就眼前一亮，要知道TFTP的传输性能弱，关隘全在这俩参数上。
   赶紧把这俩参数仔仔细细的查清楚了，立刻加到bootmgr的bcd里面。
   启动一试， 效果非常显著！！
   默认的网络启动过程，网卡的使用率始终在10mbps以下徘徊，大部分情况下更低，一个3M大小的字体文件，都要拷贝好一会儿。加上参数后，网卡的利用率立刻飙升到40mbps上下，一般都不低于20Mbps。 网络加载速度一下子快乐好几倍，再也不用傻等了，非常之爽。

下面是我的 bcdedit /store bcd /enum all 的部分输出：

[plain] view plaincopyprint?

• 安装程序 Ramdisk 选项
• ---------------------
• 标识符                  {ramdiskoptions}
• ramdisksdidevice        boot
• ramdisksdipath          \BOOT\BOOT.SDI
• ramdisktftpblocksize    40960
• ramdisktftpwindowsize   100

安装程序 Ramdisk 选项---------------------标识符                  {ramdiskoptions}ramdisksdidevice        bootramdisksdipath          \BOOT\BOOT.SDIramdisktftpblocksize    40960ramdisktftpwindowsize   100
其中可以看到 block size 设成了 40K。window size 设成了 100。
block size 设成 40k 是为了配合udp封包的优化，虽然理论上可以到63k左右（64k - 包头结构），稍微留点余量还是比较稳妥的。 实际使用时，block size其实可以更大更随意，比如到1M大小，只是这是程序层的逻辑，到了UDP层还是自动拆分了。 这个地方选40k纯属经验，并没有对比过其他的数值并优化。

windows size 这个值其实比较随意，但只在较小的数值范围时，才满足正比关系（越大效率越高）；超过一定的数值后，再大也没多大的意义了，而且效率有可能更低，甚至伴随更多的稳定性问题。
我一开始设置的是10，效果就很好了；后来为了对比下，就调成了100，发现100的效率跟10的效率，几乎没有啥区别，即便有提升，估计也就 百分之几顶多十几的提升。 其实这个地方10就足够了，我这儿是因为没啥区别，所以测试后没有改回来。


原谅我懒于编排文章结构，就这样吧：  以上是bootmgr的部分
------------------------------------------------ 分割线 ------------------------------------------------
以下是pxelinux的部分



上文说到bootmgr里面有两个很隐秘的参数，解决了网络传输性能的大问题。 但是这仅仅针对bootmgr才起作用；对于 基于 pxelinux 启动的部分，还是老样子。
但是有了上文的成功案例的鼓励，就更加有了改造pxelinux的信心。

过程同样是无趣且冗长波折的，这里直接跳转到结果：
结果就是下载syslinux的源码，修改后重新编译---听起来有点麻烦，其实非常简单，尤其是Linux环境下，直接打make就行（其实还需要安装个uuid-dev的包，我没看README，结果找这个uuid.h找了半天，找到了才发现人README里写的很清楚）。

修改的地方有两处，都在 core/fs/pxe目录下：
对于 pxe.c, 找到 1408 这个字符串，改成 40960. 这是定义blocksize。
对于 pxe.h，找到  PKTBUF_SIZE 的定义，把 2048 改成 (1024*64)。 这里定义的是接受缓冲区的大小。

然后
make
sudo make netinstall
就行了。

其实光make就行了，只是他的makefile写的不怎样，编译出来的文件都分散在各个目录里了，找起来很麻烦。 make netinstall 会把这些编译出来的文件，都拷贝到 /tftpdroot里，找起来就方便多了。由于是在根目录下创建/tftpdroot目录，所以需要sudo，如有已有目录且有权限，是不必sudo的。


说下效果吧：
  一句话，非常棒！！
  pxelinux 的这个部分实现得非常精简，只支持一个 block size参数，不支持window机制。但即便如此，他的效率仍高过了具备window机制的bootmgr。网卡利用率最高可以到60Mbps上下，最低也有20Mbps左右。相对于原来，简直是飞一般的速度！


再多啰嗦句：
  syslinux这里的默认值真的是很诡异 ，1408？？这是数字一眼就让人想起modem的MTU。 问题是这个东东大部分是局域网用的，跟MTU有个毛关系啊。
  pxelinux在他的说明里，一再强调 所设置的 TFTPD服务器一定要支持 tsize 选项，不兼容没有tsize选项的tftpd。言下之意是pxelinux是比较新的，支持比较高级功能的。
但是他所设定的1408的block size，仅仅比最初始的恐龙时代的设定------512，多了一倍多而已，根本就是聊胜于无。
  还是赶紧改了吧。






最后，对于实在不想自己编译的同学，我把我的编译结果放在这儿了。
http://download.csdn.net/detail/whoo/5054668 （40k包大小，兼容性问题较多，留此备注）
http://download.csdn.net/detail/whoo/5150778 （16k包大小，兼容性好些，性能几乎无差异。）


补充下就是：我的各种测试中，pxelinux.0 是没问题的的。  但是gpxelinux.0在vmware中就报错。 经过一段时间的尝试后，我已经放弃gpxe这个东东了，所以未做进一步的测试，不清楚这一问题到底是gpxe在vmware中的兼容问题，还是修改后的传输参数造成的。

[ 本帖最后由 2013whoo 于 2013-3-17 14:59 编辑 ]

2012idle

那何不直接传上来，省得再跳转一次 CSDN

pseudo

有网友反馈tftp+http快于tftp
http://bbs.wuyou.net/forum.php?m ... &extra=page%3D1

2013whoo

http 快于tftp，那是一定的。
tftp的优势是极其简单，容易实现，因此可以内嵌在大部分rom或者boot程序里，兼容性极佳。
http就不一样了，性能好，扩展性佳但是协议栈要复杂得多，很难塞到固件里面。

简单的说，pxe网络启动，天生就支持tftp。但是http得支持，需要在tftp之后，再加在其他的的启动程序来实现http协议。如果这一过程没问题，http起来之后，速度肯定比单纯的tftp快得多。 但是偏偏这一步，兼容性问题最多。

就我的经验来说，只用pxelinux（tftp），pxelinux.0只有20k上下，目前还没碰到不能用的环境。
但如果使用gpxelinux(支持 ftp, http, iscsi, aoe,......)，大小立刻到200k左右，作为一个启动程序，常常碰到无法启动的问题。 如果能正常用的话，gpxelinux无疑是最佳的选择，但是多协议支持带来的兼容性差，立刻让这些优势化为乌有------不能用的话，再多功能也是白搭。

所以说tftp这个古老的东东，慢是慢，但就凭兼容性强（目前还没发现不能用的设备）一点，就足以保证他的存在价值了。

pseudo

这么说您常常遇到gpxelinux兼容性问题？
我现在用ipxe，64KB，未遇到问题（可能是用得少）。


我已经做了封装。在xp/03下把startserver.cmd和0pe.iso两个文件放在一起，运行前者免配置即成服务器，客户端为局域网另一台电脑，或vmware客户机。
您可以对比一下。据说比gpxe有改进。

快雪时晴

能否提取一下，手头的都是旧版了，没跟进是因为维护的都是老机，能用即可

pseudo

0pe.iso可以用别的iso冒名，忘记能否gzip压缩了。
至于未封装的ipxe，直接谷歌就有。

2013whoo

是的，gpxe经常碰到兼容性问题。有一回我测试环境整完，以为搞定就扔哪儿了，结果一段时间后一台笔记本真的要维护时，发现网启不了。不得不又折腾回pxelinux。
虽然不是所有的pe都在所有电脑上好用，但是至少在网启的第一步 pxelinux是可靠的保证，其他我试过的方式都有歇菜的时候（且是我手边为数不多的设备环境下）。

这些不可靠的方式就包括gpxe，还有usb启动盘和usb模拟光盘。 U盘启动和U盘模拟光盘启动，最大的问题就是bios的兼容性，有些机器上可行但换个机器就不一定了。
而gpxe，我估计是他的大小的问题。
我一开始说的gpxelinux.0有200k左右是凭记忆说的（大概跟bootmgr的大小搞混了），我细查了下，发现这一数据有误。旧版是64k，新版是88k。
通常这个大小不是问题，但是如果是设为第一启动文件（即在dhcp中指定的启动文件），这一大小或许就很纠结。 因为这个文件的tftp传输过程，完全是bios的实现。bios通过网络tftp获得这一启动文件后，再将控制权转移到这个启动文件。
关键点在于：启动文件的代码是常常更新的，通常是最新的版本，不会有太原始的限制。而bios的代码，就古老的多了，且一般没啥更新。 而tftp传输协议，在最古老的版本中是有64k的上限限制的。

而gpxe，或者 ipxe，大小恰好在64k大小的左右，或者其上的。 如果他是通过其他的启动程序加载的(如先启动pxelinux,或者g4d，然后通过这些程序加载gpxe|ipxe)，问题就不大；但如果是直接通过dhcp制定的gpxe|ipxe，那就很有可能在一些bios上根本就无法加载（大小超过64k的话）。

0pe是我常备的pe之一，不过我都是抽出iso，挂在我的pxelinux菜单里。木有用过内置的服务器。
但我看了下ipxe的代码，他的tftp的默认blksize才512，max blksize也才1432, 虽然他的tftp过程实现了参数协商，但是从他的默认blksize可以看出，缺省情况下他的tftp效率甚至比pxelinux还略逊一筹。

pseudo

ipxe只63KB，估计比gpxelinux.0会好些。

内置服务器直接通过dhcp指定启动ipxe，然后ipxe以http协议传送iso；或者直接通过dhcp指定启动（与iso并存的）grldr，然后grldr以tftp协议传送iso。

我一般以grub4dos来引导pe，这样可以利用grub4dos的强大功能。
但grub4dos与pxelinux容易冲突，所以不采用经pxelinux转grub4dos的方式。
如果不涉及grub4dos，pxelinux确实不错。

zqlcchzql

很遗憾地告诉亲爱的楼主，大部分机器对于 boot.sdi 的 ramdisktftpblocksize 最多只能到 4096，高了就不成了。。。。少部分很新机器可以到 16384，那速度简直是飞快。。。。兼容性啊兼容性。
还是用 gpxelinux 从 iscsi 启动快。

2013whoo

>>大部分机器对于 boot.sdi 的 ramdisktftpblocksize 最多只能到 4096
对于这个说法，我很存疑。 愿听其详。
因为按照启动逻辑来说， ntldr只有20k左右，绝对不会有问题。ntldr启动后加载bootmgr并转移控制权。以后的tftp过程都是bootmgr控制的，与bios基本无关了。不应该有机器兼容性问题。



至于iscsi，如果成功的话（解决gpxelinux 的兼容性问题），自然是上上之选。
我试过很多不同方式的iscsi，成功率非常低。反倒是aoe，更简洁清晰，一样的高效。 这两样就是windows下免费好用的服务器不好找。

pseudo

这样搭建一次环境要经历找工具，作配置的过程，还是比较花时间的。
可以封装一下，尽量自动、傻瓜化，下次就省事了。

2013whoo

这个帖子里（16楼）的内容太老了，还是xp时代的PE，改菜单需要暴力修改ntdetect.com，winnt.sif内容。 有了bootmgr之后，pxe启动多个pe已经就变得非常简单了。

首先pxelinux不是必须得。pxelinux是强大的启动器，可以用来启动各种环境，但如果仅仅是需要启动winpe，那么直接用bootmgr就可以了，没必要先启动pxelinux,在从pxelinux的启动菜单上挂载bootmgr。

14楼介绍的就是更简洁的pxe启动winpe的方法（无需pxelinux,g4d,但仅限于启动winpe，且是win7之后的PE）。

sgw888

我想一定有许多人是用 GRLDR (G4D) 做网启的吧?
在用GRLDR做网启的时候,没有碰到过失败的例子.
但我想请教一下楼主,对于GRLDR 网启,该如何优化?

sgw888

默认情况下的GRLDR加载一个101M的文件到内存,需要47秒左右的时间. 大约每秒2M多一点.

bluetooth

原帖由 sgw888 于 2013-3-10 14:04 发表
我想一定有许多人是用 GRLDR (G4D) 做网启的吧?
在用GRLDR做网启的时候,没有碰到过失败的例子.
但我想请教一下楼主,对于GRLDR 网启,该如何优化?

新的主板，好多是uefi的，Grub4dos经常加载不成功。
pxelinux正常。

bluetooth

搂主能不能把pxelinux的附件上传一下啊。csdn没有账号。

2013whoo

早些年选型的时候，选了pxelinux。所以一直下来跟的都是pxelinux，对于g4d没啥关注。也不大会用。
所以没法提供如何配制上的一些建议。

但是我大略浏览了下g4d的代码，发现他是提供了blksize的配制选项的。 也就是在配置文件的某处，你可以指定pxe的blksize大小。

在他的代码实现里，定义了blksize的上限 16384（16K）。 而且即便你不指定blksize的大小，g4d也提供了自动检测大小的功能， 所以默认情况下g4d会比pxelinux快些。
根据我的经验，pxelinux默认情况下只有1M每秒左右（也就是10M左右的带宽），g4d得益于他16k的blksize上限和自动检测功能， 达到2M的速度不奇怪。

2M的速度比我调整过的pxelinux还是差多了。


抱歉我对g4d实在是缺乏经验，没法提供修改版。你可以给g4d的作者chenall去信提下建议看看。

[ 本帖最后由 2013whoo 于 2013-3-17 15:01 编辑 ]

2013whoo

原帖由 bluetooth 于 2013-3-10 20:54 发表
搂主能不能把pxelinux的附件上传一下啊。csdn没有账号。

约800多k。超过论坛的限制了。可私信我邮箱，我发给你。

bluetooth

原帖由 2013whoo 于 2013-3-12 19:49 发表


约800多k。超过论坛的限制了。可私信我邮箱，我发给你。

感谢分享，测试了一下，发现速度的确提高了不少，但是不无法加载大于50M的镜像啊，加载到一半左右就死了。
我是这么加载的：
kernel /BOOT/ISOLINUX/MEMDISK raw iso initrd=/BOOT/ISO/WIN8PE.ISO
用原版没有问题。

[ 本帖最后由 bluetooth 于 2013-3-14 15:47 编辑 ]

2013whoo

我只是自己用，所以能用就过了，抱歉测试不够全面。

我重新拿我手头可能的设备都测试了下，虚拟机和笔记本都正常，但是一台上网本不正常。

于是仔细浏览了下相关的代码，发现前面我的理解有个地方是有误的:
我在13楼说系统在转移控制权后，应该就跟bios没关系了。事实上不完全是，启动过程中虽然控制权转移了，但是很多启动程序都没有实现tcp/ip的协议栈（也没必要），换而言之，启动程序尽管可以自己做很多事情，但是涉及到网络访问部分，他还是利用了bios里的网络功能，bios里的pxe实现还是有影响的。


我不是专业的维护着，只是自己用着方便顺便分享下而已。尤其是代码的逻辑没问题，只是兼容性有问题，这个就更不好查了。  我简单的讲blksize从40960改小到了16384, 经测试在我的设备里都正常了， 速度也几乎没有降低（仍有50~60M bps）。

希望这个不大过分的修改兼容性更好些吧。

bluetooth

原帖由 2013whoo 于 2013-3-14 19:37 发表
我只是自己用，所以能用就过了，抱歉测试不够全面。

我重新拿我手头可能的设备都测试了下，虚拟机和笔记本都正常，但是一台上网本不正常。

于是仔细浏览了下相关的代码，发现前面我的理解有个地方是有误的 ...

请问你是哪种方式引导PE的？
我用上面说的kernel /BOOT/ISOLINUX/MEMDISK raw iso initrd=/BOOT/ISO/WIN8PE.ISO加载出现问题。
用kernel /BOOT/STARTROM.0 这种倒是没有问题，但速度没什么提升。

2013whoo

用的也是memdisk。
我给你发了个新的版本，你试过了么？


kernel /BOOT/STARTROM.0  这种方式肯定不行。因为控制权转移给 startrom.0后，就木有pxelinux啥事了。 如果你用这种方式启动win8pe，可以参我我原文里调整 bootmgr参数的方式改进，效果相当。

bluetooth

原帖由 2013whoo 于 2013-3-15 16:37 发表
用的也是memdisk。
我给你发了个新的版本，你试过了么？


kernel /BOOT/STARTROM.0  这种方式肯定不行。因为控制权转移给 startrom.0后，就木有pxelinux啥事了。 如果你用这种方式启动win8pe，可以参我我原 ...

试了新版，还是一样，加载一段镜像就没有反应了。

2013whoo

原帖由 bluetooth 于 2013-3-15 17:01 发表

试了新版，还是一样，加载一段镜像就没有反应了。

能发下详细的环境信息么？ 最好有bios的型号版本，还有tftpd服务器软件。

另外，虚拟机下测试过没？