修改windows拥堵控制,让百度云上传更快

最近用百度云,常常发现发现上传只有几百K,但如果开多个上传线程,每个都可以有几百K,总速度最多试过有一两m。就是说其实总带宽是不止几百K的,当时猜测是校园网出口的控制策略。

但到了后来用FTP上传文件到校内服务器也发现了这个问题,就是每个上传线程最多只有1.1m/s的速度,五个同时上传也好,只有一个上传任务也好,每个任务都是1.1m/s。

然后就觉得可能是本机的TCP拥堵控制有问题。

在cmd输入

可以看到以下的返回

可以发现附加拥堵控制提供程序是none,根据这里(https://technet.microsoft.com/en-au/library/bb878127.aspx)的指引,只要以管理员身份运行cmd,然后输入如下指令

即可把拥堵控制换为更为先进的CTCP。然后再次运行

就会看到

现在上传的瓶颈变成硬盘了(不是说上传速度真的比硬盘传输速度快,而是百度云比较蠢,居然会同时对在同一个硬盘上的文件进行哈希…导致数据吞吐率下降,最后硬盘追不上网速。)

GPS_UBX_OLED_Arduino

 

3-2

WaypointMobility是好的,起码Update是好的,但不知道为什么getvelocity会返回000。

 

SUMOmobility里面,用了WaypointMobility,实际上用的(真正装在Node上的)是ConstantPositionMobilityModel,然后由sumomobility里面的FORCEUPDATE周期性更新。

forceupdate里面由WaypointMobility得到新的地址后,通过setposition传回给ConstantPositionMobilityModel。对Node上的mobility调用GetVelocity,最后的是调用了ConstantPositionMobilityModel::DoGetVelocity,返回0,0,0。

3-1, 1

不知道为什么,m_ntmap会丢失,明明在Set阶段,m_ntmap的大小是不断上升的,而到了Create阶段,m_ntmap大小变为0。

而与其几乎相同实现方式的m_interfaceExclusions则不会有这个问题,有可能是Map的性质问题。其实是CopyConstructor忘记实现了。

 

之前遇到报错说,RoutingProtocol没有Constructor,其实要在SetTypeID时把constructor加进去。

2-29, 2

现在的问题是如何确定MainAddress。

发现NodeType也要事先确定。

现在NT通过Helper中的SetNodeTypeMap传递,并在Helper中的Create传递给RoutingProtocol.

21:49 已经将SDN.CC中的传递实现

SetMainAddress应该要根据NodeType执行,

2-29,1

ipv4routinghelper 在调用Create时,会传入Node,如果在调用ipv4routinghelper之前Node已经安装好mobility,路由算法可以在ipv4routinghelper中的Create时,取得其mobility,就不用另外实现一个输入mobility的过程。

 

一开始的想法是,SDN的指令信息运行在CCH,而数据信息则运行在SCH,那么这样路由协议就需要知道各个节点的“真实ID”。

HelloMessage内含ID,应该是车辆SCH的IP,而不是CCH的IP,因为RM下发时,是广播的,车辆只需要判定下发的RM中,ID是否和自己的SCH ip相同即可。

而由于LC理应只工作在CCH,所以只有CCH ip,LC的ID就是他的IP。