- == 系统问题，暂停聊天功能。==
- 【征集】西西河的经济学，及清流措施，需要主动参与者，『稷下学宫』新认证方式，24年网站打算和努力目标
主题：谁能给个估算 -- ppw
一台pc机从读取到传送一个tcp/ip 包, 要做多少次浮点运算?
定点计算应该足够了。
从IP层到应用层，各层的各个字段用整数就足够了。
cpu 100%利用的时候, 单位时间能传送多少.
除非是很老的CPU，否则传输数据本身不会导致CPU的高度繁忙，因为拆包打包的计算量并不大，多的只是磁盘IO。
举个例子，我的个人机器是AMD2500+，内存512M，使用High speed下载东西，网速平均500KB/S，CPU使用率不超过5%。
目前主流的快速以太网，实际数据传输率最多2-3M字节/秒，你可以算出这种情况下的CPU使用率。
比如100M/bits 的流量一个 塞杨1.4G 能不能支持.
它每秒也就做1.4G 浮点, 如果平均送一个bit需要十个cycle的话,
将将够, 这十个cycle 算不算多? 没概念...
用你给的数据, 1G的CPU, 5*5%=25%
4*500=2M
一G的机器最多能支持2Mbit 的传送..如果你当时没有在同时做其它事情的话.
我的意思是，需要处理的应该以包为单位。
有些处理工作也不需要中央处理器的参与，
可以是下面设备驱动部分完成,
详细的估算应该同机器的体系结构有关系，
感觉bottleneck可能还是在磁盘I/O。
Athlon 500 和 P4-1.6G ， 100MBit 传输毫不成问题。
可以达到 10MByte /s 的速度，几乎到了 80MBit /s 了。
这里面和 CPU 关系并不大。否则的话 P166MMX 当年可以
不用活了。过去的企业级服务器也就是 Pentium Pro 也不用活了。
在这个传输过程中，明显硬盘在哗哗响，网卡在拼命读写，
但 CPU 其实并未那么吃紧。因为大部运算并不全靠 CPU 完成。
IDE 还是有点儿依赖 CPU ，但 500 以上 CPU 肯定是够了。
如果改用 SCSI ，那么对 CPU 的依赖就更少了。估计高速
局域网传输和 super Pi 运算都可以同时完成。
一。网络传输是以包为单位而不是以位为单位进行的，包的构成是字段和字节而不是位。CPU所作的工作不过是发指令读取数据、打包和发指令发送数据或者是接指令接收数据，拆包和发指令存储数据，并不是包揽所有工作，而只是拆包/打包和等待设备处理完毕，因此并不是很繁忙。
二。现代的IDE设备和网卡都有简单的独立运行能力。前者在接到读取数据的指令以后可以自行从磁盘读取数据然后以DMA方式传送到内存，这个是不需要CPU的介入的；后者在接到收送数据的指令以后可以自行从网络上接受/发送一定数量的数据然后再通知CPU，这样CPU的压力并不很大。另外，SCSI可以做到比IDE更好的并发度和性能，而高级网卡甚至带有独立的CPU和内存，这样它们可以进一步地降低CPU的压力。
三。CPU一般是用它的定点处理能力而不是浮点处理能力来处理非浮点计算型的任务（例如涉及网络数据传输的拆包/打包行为），原因是定点处理能力的开销/性能比要比浮点处理能力的开销/性能比经济的多。浮点处理能力一般是用在科学计算和图形处理方面。
四。网络中各层的数据包大小并不一致，但是数据包都是以字节流的方式来构成。CPU对处理字节流有特定的指令，很少几条指令就可以处理很长的字节流了。具体的指令（机器语言指令）记不清楚了，但是一般都是由确定源地址、目标地址、长度和传送指令这几条指令来构成，也就是所谓的设定ds:si源地址、设定es:di目标地址、设定cx长度、传送指令movb/movw。上面所列的是十六位指令，三十二位指令有一些变化，但是原理是一样的。指令的长度一般是固定的而传送的数据量则可以随意变化（当然还是有一定限制的，例如字长和内存可用量），因此不存在指令的长度和传送的数据量的直接关系。
五。目前的快速以太网卡标称是100M/bits，但是实际使用时在两台机器通过交换机直联，没有任何碰撞的情况下实际传输率只有2-3M字节/秒（这个数据是我用两台IBM小型机（配备快速以太网卡）、一台CISCO交换机、直联和用FTP传输1G的数据文件情况下得出的）。这里请注意位和字节并不是简单的除以几的关系，因为网卡工作在链路层，数据一般是从应用层下来，途经的每一层都有加各种字段的打包过程。100M/bits是指链路层的理论传输速度，而2-3M字节/秒是用户数据的实际传输速度，二者之间有着巨大的区别。
六。我给的数据并不意味着那5%是用足的了，而是说不超过5%，而且下载速度500K字节/秒是指的用户数据的实际传输速度。我不知道塞杨1.4G和AMD2500+是如何比较的，但是AMD2500+基本相当于Intel P4 2.5G，这里假定Intel P4 2.5G比塞杨1.4G快上一倍（前者的主频、结构和高速缓存均优于后者），那么可以算出两个因子：CPU相对处理能力指数是2，网络传输速度可用空间指数是6（3M字节/秒对500K字节/秒，同时假定对CPU处理能力的需求也同步增长，虽然我很怀疑这一点），这样塞杨1.4G所对应的CPU利用率将是2*6*5%=60%。这里假定你可以用足网络传输速度、CPU相对处理能力指数是2而且其它参数都是一样的。也就是说，塞杨1.4G应该可以充分利用目前的快速以太网卡的100M/bits 的流量指标了。
七。但是我很怀疑你能否用足网络传输速度，因为目前的快速以太网还依然是碰撞抢先结构，多台机器的以太连接所造成的碰撞会相当程度地降低实际的数据传输速率的。根据我的经验，实际速度能够接近2M字节/秒已经很不错了。
结论：塞杨1.4G的机器应该能够支持100M/bits 的流量要求。
本帖一共被 1 帖 引用 (帖内工具实现)
朝闻西施啊...
的总平均啊, 这个主要是方便计算成本. 大家对我这么算意见都很大么, 呵呵.
主机租用, 一般最重要的指标就是什么cpu,多少M带宽, 多少钱.
不想买个不般配配置.
十几块钱的Consumer级Router每秒handle几百兆的traffic一点问题没有，而这些Router计算能力是很低的，无法和计算机比。
比较好的Network Card在Network IO中对计算机的要求很低，所以CPU基本不是问题。还记得早些时候的VCD Card吗？在486的机器中就可以流畅回放VCD，VCD Card上专用芯片完成了绝大部分视频解压工作，对CPU压力极小。现在的Network Card，好的SCSI卡是同样的道理，他们专用的芯片几乎可以完成各自的工作。
加精不毕嫌么.. 加..加
记得以前用赛扬500的时候，用flashget开上八个任务，每个任务再来十个线程，然后再用netants开上几个多线程的任务，机器就明显地不行了，感觉就是摇摇欲坠了，那时候CPU的利用率经常是70%以上。关键就在于多线程拼的是CPU，而网络传输拼的是网络设备（例如网卡），只要后者过得去，前者可以很轻松的。
尤其是Scalability issue。所以好的server program现在都使用Thread pool模型。高级的Thread pool可以根据当前硬件情况来动态改变Thread数量，以期达到最优化效果。Thread太多了，消耗内存不说，并且CPU时间都用来做thread context switch了，干不了什么“正经”事儿。
我一哥们号称Visual C++ 天下独步，曾经跟我吹牛，说他那个程序一但运行起来，上千条Thread，复杂的不得了云云。
其实他这个程序设计得非常有问题。最常规的做法应该是将那些任务放到一个或几个Task Queue里，然后一定数量的Thread不停的从中Take task，来异步完成。（他的C++功力总体上我还是比较佩服的）
.NET的Thread pool 就是这个概念。QueueUserWorkItem就是前台将任务放到Task Queue里，后台Thread pool会自动接管这些个任务来异步完成。.NET的Thread pool比较智能，会根据任务以及硬件情况（CPU数量和Memory）自动伸缩。比我当年写的“半自动”Thread pool又前进了一步。不过.NET每一个Process只能有一个Thread pool，有时候不是非常灵活。
Java现在也提供了类似的Thread pool，只是我一直没有试过！
一般应用程序员是做不好这类事情的。即使有一些很不错的高手，也会受限制于自己的职责范围和对系统的掌握能力，而使得设计出来的软件模型不尽完美。