本人使用的是Red Hat Linux9.0 开机后启动时 启动到starting sendmail 这里就会停留2~3分钟 有的时候会更长时间,等的人很着急 请问我该怎么解决这个问题才能启动快点? 是不是我安装软件的时候安装错了... 请教!!!
本人使用的是Red Hat Linux9.0 开机后启动时 启动到starting sendmail 这里就会停留2~3分钟 有的时候会更长时间,等的人很着急 请问我该怎么解决这个问题才能启动快点? 是不是我安装软件的时候安装错了... 请教!!!
拥塞发生时－－>会调用慢启动算法 过程实现 1：一个连接，cwnd 初始化为1个报文段，ssthresh 66535 个字节 2：发送方，发送时的输出不能超过cwnd 和接收方通告窗口的大小。MIN（a,b ）? 3:当拥塞发生时(超时或重复确认),ssthresh 设为当前窗口一半 [1/2（MIN）],若是超时cwnd =1,这是慢启动。 4：当新的数据被确认后，就增加cwnd , cwnd < ssthresh 慢启动 指数增加 1 2 4 8， ...
如果A->B连续发送了10个包(即1-10),此时出现网络拥堵,1-10这10个包都没有收到确认， 那么这时发送窗口的大小为这10个包大小，接着慢启动发生,cwnd变为1,并重传了第1个包 问题： 此时A的发送窗口大小应该还是原来的10包大小吧，如果这样的话，那么只有当cwnd>10时(假设不考虑B的接收缓冲区情况) ，A才能发送新的数据包(即11开始的包)？ 上面举例的意思是想搞明白： 在一段时间正常数据传输后，接着慢启动，那么慢启动是怎样影响滑...
本帖最后由 chenzhanyiczy 于 2010-09-05 23:52 编辑 如果A->B连续发送了10个包(即1-10),此时出现网络拥堵,1-10这10个包都没有收到确认， 那么这时发送窗口的大小为这10个包大小，接着慢启动发生,cwnd变为1,并重传了第1个包 问题： 此时A的发送窗口大小应该还是原来的10包大小吧，如果这样的话，那么只有当cwnd>10时(假设不考虑B的接收缓冲区情况) ，A才能发送新的数据包(即11开始的包)？
这两天换了一台机器，突然发现启动urxvt好像变得很慢的样子，于是又试了一下原来的机器，这才觉得不过是五十步与百步的差别罢了。在网上查了一下，说是和imput method有关的设定，只要在resource里面加上 urxvt*preeditType:Root 就行了 本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/8091/showart_109467.html
开机自检慢的解决方法 需要检测或者修复磁盘： 右击磁盘（如C盘） 属性 工具 开始检查 自动修复文件系统错误 和 扫描并试图恢复坏扇区 打钩 开始 把每个分区都修复一下。 另：进入系统后 chkdsk c: /f （c换成DEFG 一个个来）
