修改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加进去。

国内NTP!

203.195.247.192 / ntp-gz.chl.la

120.24.166.46 / ntp-sz.chl.la