@zhongdao 2019-12-16T15:39:44.000000Z 字数 9728 阅读 2800

BFT传输时间计算公式及中间节点分析

未分类

传输公式推理过程

定义与实际情况假设：

服务器，中间节点（具有上传下载带宽和能力），终端节点（只有下载能力无法上传).
中间节点是N个，终端节点是M个。
服务器的上行带宽是400Mbps。

为了简化，假设中间节点，终端节点的的上传和下载速率都是100Mbps, 所以理论计算与实际有一定误差，可以根据实际时间调整经验值，然后套入公式得出与实际接近的传输时间。
公式的比例关系是 (2M+N)/2(4+N)

如果调整了中间节点的上传下载带宽，也就是中间节点各个的带宽不同，则需要按照西格玛的公式进行累加计算。

推理过程

p2p传输时间计算1.jpg-99.7kB

p2p传输时间计算2.jpg-124.2kB

p2p传输时间计算3.jpg-109.8kB

p2p传输时间计算4.jpg-97.4kB

含公式markdown文档

定义

$u_s$ 服务器上行带宽速率
$u_i$ 对等端peer上行带宽速率
$d_i$ 对等端peer下行带宽速率
$F$ 文件长度
$N$ N个对等端peer
$D$ 分发时间其中 $D_{cs}$ 表示cs架构下的传输时间，同理 $D_{p2p}$ 表示p2p架构下的传输时间
$C_i$ 终端节点的下行速率
$M$ M个无上传能力的终端节点。

C/S架构时传输时间

服务器Server向N个peer传输，时间是 $\frac{NF}{U_s}$
$d_{min} = min\{d_1,d_2,...d_N\}$ 传输时间至少是 $\frac{F}{d_{min}}$
所以
$D_{cs} {>=} max\{ \frac{NF}{U_s}, \frac{F}{D_{min}} \}$

P2P架构时传输时间

分发开始，服务器server有文件 $F$ , 为使对等方peer得到，需经过上行带宽发送至少一次。时间至少为 $\frac{F}{U_s}$ , peer收到后可再发送。
$\frac{F}{d_{min}}$
系统总体总上载能力等于服务器的上行加上每个peer的上行速率e， $U_{total} = U_s + U_1 + U_2 + ... + U_N$ 系统必须向这个N个对等方每个都传输F比特，即共 $NF$ , 不能以快于 $U_{total}$ 的速率完成。最少时间为 $\frac{NF}{U_s+U_1+...U_N}$
所以
$D_{p2p} >= max\{\frac{F}{U_s}, \frac{F}{d_{min}}, \frac{NF}{U_s + \sum_{i=1}^Nu_i } \}$
即为p2p架构的最少分发时间下界，作为近似时间。

P2P+CS架构传输时间

因为外围的终端节点没有上传能力，缓存节点和中心服务器可以认为是对外提供传输源文件的服务器，所以可以看做是一种特殊的p2p+cs的架构。
忽略掉从一开始Server到p2p架构以及终端节点的共同分发过程对系统分发的影响。（p2p结构本身对上传者的奖励机制决定了文件资源的分发向具有上传能力的节点倾斜）

传输时间上限

可以简化为先完成p2p的分发，然后整体再作为服务器分发给没有上传能力的终端。两步完成文件分发。多个服务器每台都有文件 $F$ ,一起向M个客户端传输。
$C_{min} = min\{ C_1, C_2,... C_M \}$

传输时间下限

LaTeX 公式示例与参考资料链接

$ 表示行内公式：

质能守恒方程可以用一个很简洁的方程式 $E=mc^2$ 来表达。

$\sum_{i=0}^n i^2 = \frac{(n^2+n)(2n+1)}{6}$

$$ 表示整行公式：

$\sum_{i=1}^n a_i=0$

$f(x_1,x_x,\ldots,x_n) = x_1^2 + x_2^2 + \cdots + x_n^2$

$\sum^{j-1}_{k=0}{\widehat{\gamma}_{kj} z_k}$

实际中间节点的流量分析

总分析与结论

比管理的5个节点多了一个湖南株洲节点，此节点没有带宽占用和流量。
湖南株洲节点的带宽没有100Mbps,只有大约50Mbps
任务分发之间有时间间隔，没有流量是正常的。有较低的流量占用是因为有窄带宽的终端节点传输时间较长，超出了正常传输时间，应将此部分节点剔除或者提升带宽。
浙江电信的26日到28日的传输，带宽没有充分利用，是因为磁盘空间满，无法传输导致的。需要增加tms的空间存储管理功能。同时此节点硬盘是分别880G，挂载在 /data, /data1 的2个目录下。
关于增加节点的计算，需要明确套入公式的条件，列出具体参数，便于排查。

解决方法：
1. 将节点管理在相关人员中清晰化。确保没有遗漏或者多增加。
2. 检查所有节点是否都是100Mbps，或者符合要求,对于磁盘空间确保/data/dcp 有符合要求的空间大小。
3. 排查所有终端节点，看其下行带宽，是否是100Mbps，若太窄，则劝说影院提升带宽。若是废弃节点，则将其从任务发送对象中排除掉。
4. 安排好影片和影片分发的时间调度，尽可能同时发送，或者一部紧接着一部。
这样就能充分利用带宽和中间节点。
5. 增加TMS的空间管理，避免磁盘满。

详细解释：
124.232.176.10 湖南株洲节点2
这个节点不在管理范围内，没有用户名密码。风行界面6个节点。我们只有5个用户名密码。
所以流量没有满，这是主要原因。
image_1dobs6dcm1lhg1c1b1tek3vtk2n1t.png-56.4kB

其次，流量没有持续跑满的原因是下载一部影片在2-3天传输完成后，带宽占用结束，所以100Mbps的带宽占用就突降（有的个别终端节点，也可能是废弃节点下行带宽太窄，导致传输时间过长，仍有10-20Mbps的带宽占用，但是不是主流），然后因为没有影片分发任务，所以带宽没有占满，当有新的任务启动后，又会重新占满100Mbps，又开始一轮传输。任务和任务之间的带宽占用不充分，这与分发影片任务的时间调度安排相关，少量占用是窄带宽终端节点的占用不是主流。但是就传输本身而言，都是正常的。

佛山电信节点

image_1dobpveab1vl17851m2l19159un9.png-95.5kB
10.20 -- 10.29

分发过程正常，一开始，上传带宽跑满100Mbps, 下载带宽因为源服务器的带宽有限，所以无法提到最高，因为多个临时节点共同分享一个中心服务器的带宽。解决办法是提供中心服务器的带宽，加快从单一到多个的分发。
随着影片的传输完毕，下行逐渐下降。但是上传因为要分发到多个终端节点，所以要持续一阵子。
这里是一部影片从10.21开始下载，争取下载的过程，经过一段时间后，跑满100Mbps, 一直延续到10.24日，分发基本完成。
剩余的带宽，则限于终端的节点下载速度过慢，所以时间较长，属于尾部。

10.26晚上是另外一部影片的下载和同时对外提供上传。到10.28日晚上基本完成上传下载的峰值100Mbps的传输。

正常。
提高中心服务器带宽；协调好影片和影片之间的传输调度即可进行进一步优化，争取占满所有时间端的带宽。

珠海电信

image_1dobqga24cmf10f4v301l7r13jum.png-86.3kB

分析同上。正常。

江苏电信20peers

image_1dobqogcmf3j1qdo50vnsv15eq13.png-83.5kB

这里是一部影片从10.21开始下载，争取下载的过程，经过一段时间后，跑满100Mbps, 一直延续到10.24日
同样，头3天都是100Mbps跑满的。

然后10.26到10.28前2天的带宽都是100Mbps跑满的。

浙江电信20peers

image_1dobr2b771aua107r10sa1aplub31g.png-87.1kB

第一部片子：
10.21晚上22点左右开始，到10.24日4点左右，差不多2天半的时间，都是100Mbps的峰值跑满。

第二部片子：
10.28日14点左右开始，到10.29日18点，不是持续峰值，这个有问题，需要仔细分析，登录本机查看情况。
因为根据其他几个节点判断，影片应该是从10.26日晚上开始的。
登录查看日志，发现从26日早上开始，磁盘空间不足，造成无法创建任务。这是中间节点磁盘空间和任务管理调度的问题,需要TMS端解决。

Sat Oct 26 21:28:38 2019: Query: $VAR1 = {
          'method_name' => 'create',
          'method_params' => {
                               'seedtime' => 168,
                               'torrent' => '/data/dcp/TianQiZhiZi_FTR-CGS_F_CMN-QMS_CN_51_2K_20191021_CGS_IOP_OV.torrent'
                             },
          'message_type' => 'request',
          'message_source' => 'tms',
          'message_id' => 'ebe0d4db-1258-4a2c-89b0-5c10cf20736b'
        };
Sat Oct 26 21:28:38 2019: available spaces 66145 M of /data/dcp is not enough to store torrent files /data/dcp/TianQiZhiZi_FTR-CGS_F_CMN-QMS_CN_51_2K_20191021_CGS_IOP_OV.torrent which is total 146531 M
Sat Oct 26 21:28:38 2019: Response: {"method_name":"create","request_message_id":"ebe0d4db-1258-4a2c-89b0-5c10cf20736b","return_status":"false","return_content":{"desc":"available spaces 66145 M of /data/dcp is not enough to store torrent files /data/dcp/TianQiZhiZi_FTR-CGS_F_CMN-QMS_CN_51_2K_20191021_CGS_IOP_OV.torrent which is total 146531 M."},"message_type":"response"}

查看

 df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             32G     0   32G   0% /dev
tmpfs           6.3G  634M  5.7G  10% /run
/dev/sda2       487G  3.1G  459G   1% /
tmpfs            32G     0   32G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            32G     0   32G   0% /sys/fs/cgroup
/dev/sda1       511M  3.5M  508M   1% /boot/efi
tmpfs           100K     0  100K   0% /run/lxcfs/controllers
/dev/sdb1       880G  758G   78G  91% /data
/dev/sdc1       880G   72M  835G   1% /data1
tmpfs           6.3G     0  6.3G   0% /run/user/1000

株洲电信

image_1dodp8v121ntqpm5h1in1g1jr21m.png-56.3kB
服务器ip: 124.232.176.10
这一台的的服务器ip不在5台节点管理范围内，不在此分析范围内，但是有突发的流量，有可能是流量数据或者是ubuntu的维护性时形成的流量，只占极低的带宽，可以忽略。

image_1dodp0rs585ic2p99t1es3rk89.png-112kB
服务器ip: 124.232.176.12

这个只有峰值50-60Mbps,说明带宽本身有限制。

于2019.10.30下午15:20左右进行带宽测试，基准服务器为联通中心北京节点，最高一次带宽测试是38Mbps。
可以看出，带宽本身可能只有50Mbps. 所以达不到100Mbps峰值。
而从曲线上看，按照业务运行分发调度来看，是占满的情况。

 iperf -c  103.90.190.176
------------------------------------------------------------
Client connecting to 103.90.190.176, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 124.232.176.12 port 36062 connected with 103.90.190.176 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  5.88 MBytes  4.87 Mbits/sec
root@root1:~# iperf -c  103.90.190.176
------------------------------------------------------------
Client connecting to 103.90.190.176, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 124.232.176.12 port 36080 connected with 103.90.190.176 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.2 sec  3.12 MBytes  2.57 Mbits/sec
root@root1:~# iperf -c  103.90.190.176
------------------------------------------------------------
Client connecting to 103.90.190.176, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 124.232.176.12 port 36106 connected with 103.90.190.176 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-11.9 sec  36.9 MBytes  26.0 Mbits/sec
root@root1:~# iperf -c  103.90.190.176
------------------------------------------------------------
Client connecting to 103.90.190.176, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 124.232.176.12 port 36140 connected with 103.90.190.176 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  16.8 MBytes  13.9 Mbits/sec
root@root1:~# iperf -c  103.90.190.176
------------------------------------------------------------
Client connecting to 103.90.190.176, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 124.232.176.12 port 36158 connected with 103.90.190.176 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.5 sec  8.00 MBytes  6.42 Mbits/sec
root@root1:~# iperf -c  103.90.190.176
------------------------------------------------------------
Client connecting to 103.90.190.176, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 124.232.176.12 port 36184 connected with 103.90.190.176 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.3 sec  12.1 MBytes  9.89 Mbits/sec
root@root1:~# iperf -c  103.90.190.176
------------------------------------------------------------
Client connecting to 103.90.190.176, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 124.232.176.12 port 36434 connected with 103.90.190.176 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.4 sec  48.4 MBytes  38.9 Mbits/sec
root@root1:~# iperf -c  103.90.190.176
------------------------------------------------------------
Client connecting to 103.90.190.176, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 124.232.176.12 port 36460 connected with 103.90.190.176 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.2 sec  38.2 MBytes  31.5 Mbits/sec
root@root1:~# iperf -c  103.90.190.176
------------------------------------------------------------
Client connecting to 103.90.190.176, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 124.232.176.12 port 36642 connected with 103.90.190.176 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  46.4 MBytes  38.4 Mbits/sec
root@root1:~# iperf -c  103.90.190.176
------------------------------------------------------------
Client connecting to 103.90.190.176, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 124.232.176.12 port 36660 connected with 103.90.190.176 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  39.1 MBytes  32.7 Mbits/sec

磁盘读写时缓慢的问题分析

结论

因为分500G系统盘和 4T的影片数据盘2个，所以实验了不同的读写情况下的性能，均正常。
文中最后的一种情况是用 dd 对系统盘写，对4T 读。
1. 这种情况在tms实际业务中不存在，因为读写都在影片数据盘上，对系统盘没有高频读写。所以最后这情况在实际中不存在。
2. 这种dd的高频大量的读写操作本身就会占系统资源。实际系统读写程序没这么占资源。
3. BT是C语言编写，高效稳定，具有硬盘的缓存默认16M，降低了io频发占用，对系统资源占用不高。有dd并发时，TMS灰色卡死，这是TMS图形界面的问题。因为系统的浏览器等程序正常，有延迟而已。

所以结论是：这个问题在实际业务中不存在，不需要解决，如果需要解决，需要提升TMS图形界面的程序的性能。

另外，建议下次实验需要提供具体命令参数， DD命令每次的读写的block块大小，是否打开了缓存等信息。

测试数据

T3620大文件传输硬盘性能测试
准备环境：
1、 T3620安装ubuntu 16.04 系统。
2、安装大文件传输tms版本。
测试步骤：
1、用iostat -x 1 10000000命令检测硬盘状态。并生成日志文件。开启tms软件，进行BFT下载。同时反复点击tms各菜单进行观察。同时反复点击communicator 、firefox 等程序菜单进行观察。
结果：正常使用未发现卡顿。

2、使用iostat -x 1 10000000命令检测硬盘状态。并生成日志文件。开启tms软件，进行BFT下载。使用dd 命令对4T硬盘进行读写。同时反复点击tms各菜单进行观察。同时反复点击communicator 、firefox 等程序菜单进行观察。
结果：正常使用未发现卡顿。

使用iostat -x 1 10000000命令检测硬盘状态。并生成日志文件。开启tms软件，进行BFT下载。使用dd 命令对500G硬盘进行读，对4T硬盘进行写。同时反复点击tms各菜单进行观察。同时反复点击communicator 、firefox 等程序菜单进行观察。
结果：正常使用未发现卡顿。

3、使用iostat -x 1 10000000命令检测硬盘状态。并生成日志文件。开启tms软件，不开启BFT下载。使用dd 命令对500G硬盘进行读，对4T硬盘进行写。同时反复点击tms各菜单进行观察。同时反复点击communicator 、firefox 等程序菜单进行观察。
结果：正常使用未发现明显卡顿。

4、使用iostat -x 1 10000000命令检测硬盘状态。并生成日志文件。开启tms软件，不开启BFT下载。使用dd 命令对500G硬盘进行写，对4T硬盘进行读。同时反复点击tms各菜单进行观察。同时反复点击communicator 、firefox 等程序菜单进行观察。
结果：正常使用，但在点击tms软件和communicator 、firefox时会有延迟。

5、使用iostat -x 1 10000000命令检测硬盘状态。并生成日志文件。开启tms软件，进行BFT下载。使用dd 命令对500G硬盘进行写，对4T硬盘进行读。同时反复点击tms各菜单进行观察。同时反复点击communicator 、firefox 等程序菜单进行观察。
结果：反复点击tms菜单，会出现整个tms软件卡死变成灰色。但是点击communicator和系统文件目录、浏览器等都可以正常使用，但是会有延迟。停止dd命令后，tms软件恢复变成彩色，然后可以继续使用。

测试分析：
在tms进行BFT下载的时候，对500G硬盘进行大量写入操作会导致tms软件出现灰色界面卡死情况。