那么如果照这样的做的话会出现什么情况呢?结果相当有趣。在实际运行了一次之后，发现MTU的变更好像是被认为无效，同时MTU被固定在9004Bytes(照片8)。如果要寻找这个部分的数据源的话，应该为linux-2.6.12_lsp.1.10.3.src.tar.gz所包含的Sources￥linux-2.6.12_lsp.4.10.3￥arch￥arm￥mach-mv88fxx81￥LSP￥egiga￥mv_e_main中的egiga_change_mtu()。当你的数据源后运行的话，就可以发现原来由Marvell提供的数据已经经过了玄人志向的修正，这个应该是独有的功能。这时可能会因为在从egiga_change_mtu中提取出来的egiga_change_mtu_internals()中MTU值不同而拒绝接收，此外如果与现有的MTU值不同并且被重新设定了一次的话，在后面如果通过命令行进行变更就无法再实现。

　　在networking.那直接编辑sh，把MTU做为9,000Bytes进行试验。下面是从/etc/netinfo中漏掉了MTU的记录后之后的列表:

　　else

　　mtu=1500

　　fi

　　一部分:

　　else

　　mtu=9000

　　fi

　　前次所说的使用重启的方法似乎比较粗暴，按照这种状态，在前面同样测试的传输速率列在表7-9中，NVIDIA没有发生明显变化，不过很明显Marvell出现了显著的性能下降。这也许是由于JumboFrame的原因，在进行通讯时与配对的MTU大小吻合是非常重要的。首先玄箱PRO在默认状态下使用的是JumboFrame，因此在与Marvell的Gigabit Ethernet网卡进行通讯时其效果是不能令人满意的。不过如果是强制在networking下进行调节的话，那实施起来还是很容易的，因此在使用的时候我们最好还是根据自己的实际情况进行调节。

　　表7

　　FDBench 1.01 综合得分 详细传送速度 详细拷贝回数

　　传送速度 拷贝回数 Read Write Random Read Random Write 2K 32K 256K Variable

　　(KB/sec) (回/分) (KB/sec) (回/分)

　　NVIDIA 12419 7090 15930 9958 14411 9376 13194 10614 3524 1028

　　Marvell 13062 8285 15904 11254 14509 10581 16398 11682 3910 1152

　　Intel 19084 8932 29917 10899 25236 10283 16578 13324 4474 1354

　　表8

　　SiSoftware Sandra XI SP1a NVIDIA Marvell Intel

　　硬盘读取 (MB/s) 13 12 17

　　平均存取时间 (ms) 10 16 15

　　缓冲读入 (MB/s) 16 15 28

　　依次读入 (MB/s) 13 13 20

　　随机读取速率 (MB/s) 12 11 15

　　缓冲写入 (MB/s) 17 14 15

　　依次写入 (MB/s) 14 12 13

　　随机写入 (MB/s) 15 12 13

　　平均存取时间 (ms) 10 16 15

　　表9

　　文件传送 所要时间(秒) 传送速度(MB/s)

　　NVIDIA 本地→玄箱PRO 140.9 16.8

　　玄箱PRO→本地 180.6 13.1

　　Marvell 本地→玄箱PRO 171.0 13.8

　　玄箱PRO→本地 182.0 13.0

　　Intel 本地→玄箱PRO 145.7 16.3

　　玄箱PRO→本地 110.8 21.4

　　虽然是题外话，但是 / etc / 如果设置netinfo固定IP地址话还是有可能的，举个例子:

　　/etc/netinfo:

　　my_ipaddress=192.168.2.10

　　my_subnetmask=255.255.255.0

　　my_dgw=192.168.2.1

　　/etc/host.info:

　　hostname=KUROBAKO-PRO