如果是你铁道部12306网站架构师，如何设计网站的软件架构和硬件系统架构
[问题点数：40分，结帖人josph2012]
如果是你铁道部12306网站架构师，如何设计网站的软件架构和硬件系统架构
[问题点数：40分，结帖人josph2012]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
相关帖子推荐：
本帖子已过去太久远了，不再提供回复功能。高频交易软硬件是怎么架构的？
【刘贺的回答(26票)】:
首先，我不是专业搭这个的……所以我基本都是瞎猜的……
其次，不太清楚这一大段问题具体是在问什么……
您是不相信latency能做到1ns？我也不信。如果收发buffer的latency是1ns，假设光纤上跑的是数据包，响应的时候接收器会把整个包存下来，再发一个响应包（store and forward）。那么，40G的光纤，1ns就只有是5个Byte。如果传输latency是1ns，光才跑30厘米……
也就是说，如果你的电脑离交易所的数据中心有几千米远（比如你在东单而它在西单），那么传输的latency也有几个ms，给你一个700ns就能响应的交易系统也帮不了你很多忙，更简单的办法是把电脑搬到交易所旁边去。
不知道问题里说的硬实时是什么……一般说硬实时是说deadline是死的，系统必须在deadline之前完成任务，没有通融。理论上说，deadline在一小时之后的硬实时也是硬实时……
数学模型很少是高度变化的……就是一交易程序，都是人写的，其变化的速度取决于人认识问题和写代码的速度，不取决于计算性能（除非程序是计算机自己写的，而且计算机已经智能到可以在毫秒之内自己写出新的程序，并立刻跑几个毫秒，然后几个毫秒过去之后再写一个新的……不是不可能，但是目前还比较科幻……）。所以短时间内，程序基本是不变的，模型框架基本是不变的，变化的只是输入的数据和模型参数，理论上没什么不能用FPGA实现的。
最后说说现在商用硬件的性能。
首先，你随便找两个机器，网线直连，ping一下，RTT也就200us左右。
如果要更快更稳定呢？
假设你跑Linux，从网络走，10G的光纤接进来，网卡插在PCIE bus上，网卡直接接入user space （比如用类似
的东西），或者直接写个kernel module，bypass掉整个linux的network stack，关掉网卡的interrupt coalesing，pin到一个core上，latency其实挺小的。整个东西warm起来之后，除了接收的数据之外基本不会有cache miss，收发包都没有memory copy，PCIE bus可能会有一些不确定的latency，但总的latency可以做到绝大多数情况下都小于20us。这是全在商用的PC上做，而且完全不用给linux kernel打patch，kernel module都可以搞定。
如果你告诉我这帮做事没什么底线的人完全不走PCIE，自己订做了自己的DMA接口，我也不会很惊讶……那就基本只剩memory了。memory其实还是挺快的。一个cache miss不会多于1us。
如果还要更快的turn-around，那就把memory也省掉，比如可以弄NetFPGA（价钱就贵很多了，但这帮搞金融的可能根本不在乎……），省掉PCIE bus和memory，基本只有调制和解调的latency，响应逻辑做到cut-through也是可能的。700ns在一个200MHz的clock上有140个cycle，parallel起来还是能做很多事情的。
FP是什么？
（我感觉您心里是早就已经有答案了，觉得注定达不到，新闻就是扯淡……所以这时候别人都像是在要说服你，而不是在回答问题。如果不做实验，靠嘴说服是一件很难的事情……所以下面的答案更多的意义是我自己的装逼，您心情不好就别看了……）
我听说的结果是至少在throughput上DPDK可以很轻松地把40G的link用MTU塞满……不知道您那个结果很不妙指的是什么……
10G link上一个1500B的MTU从开始收到检查完CRC，都要1.2us，这基本是速度的下限了。实在不知道为什么还要追求ns级别……
Linux scheduler的overhead，在发送端，在CPU上跑的kernel thread（不自己主动调用schedule()）只会被interrupt打断，在一个空闲的机器上，除了网络IO interrupt之外的其他interrupt密度是极其稀疏的，所以基本上就是dedicated core。没有interrupt时，scheduler根本都没有被执行，哪儿来的overhead？在接收端，NAPI接收到interrupt之后就把interrupt关掉改pulling了，把coalescing关掉之后在10G nic上接受line rate平均5个MTU packet就会pull一次（查interrupt counter能查出来），也就是irq context switch的开销（因为都在kernel里，所以不用刷TLB，只存一下断点就可以了）顶多是6us，平摊到每个packet的接受的latency是3us。几周前自己刚测的。So，您的第一手资料是？
1000个cycle够做一个相当规模的并行FFT的了（并行是O(logn)的，如果没记错的话）……从来没玩过HFT，但我能想象的HFT需要实时响应的也就是到了某个时间点/成交量/价格/指标值的时候赶紧买进/卖出。具体的各种trigger值应该都是早就准备好了并且是随时间连续变化的。另外，NetFPGA的FPGA会放在网卡上，就不走CPU了……
为什么functional language就不会用SIMD？难倒不是该用啥用啥？
总结一下：
(1) 10ns以下或左右的wire-to-wire latency不现实也不需要。10Glink上20个Byte都不到，header还没看全呢，光才跑3米。
(2) 其实没人刻意宣传ns级别的latency（700ns四舍五入一下也应该算1us了吧），ns latency其实是问题作者自己假想的……
(3) 对于其他东西的描述，问题作者很多认识都不是很靠谱。但由于(1)已然成立，所以这些其他东西本来也不怎么相关，所以认识靠谱与否其实是无所谓的事情。
【董龙珠的回答(20票)】:
有几个误区是要先澄清的。
一，HFT不一定是套利算法。事实上HFT做的最多的业务是做市，可以是把商品从一个交易所倒卖到另一个交易所，也可以是在同一个交易所内部提供某种商品的流动性。这两种方式的共同点都是让人们可以特定地点买到本来买不到的商品，所以本身就是有价值的，收服务费就可以盈利。反而是套利算法是投入高风险高的生意，一旦市场环境变化就要重新研发，不是长久的生意。
二，延迟和带宽是不同的概念。低延迟不等于高数据量，事实上大部分时间交易数据流量并不大，一个market一天最多也就几个GB。但HFT系统需要在流量高峰时也能快速响应，所以更看重延迟。
三，一个HFT业务包括从主机到交易所的整条通信线路，在这条线路上有很多段不同的延时，是需要分开讨论的。如果是做跨交易所的交易，首先需要考虑的是两个交易所之间的网络延迟。当数据通过网络到达主机的时候，有一个最基本的tick-to-trade延时，是指主机接收到数据到做出响应所需的时间。但这个东西的测量很有技术含量，根据不同的测量方式，它可能包括或不包括网卡及网络栈的处理时间。所以拿到一个HFT系统的延迟数据时，首先要搞清楚它指的是什么，然后再来讨论。
接下来说说做为一名从业者，我对各个层面的理解。
首先网络架设上光纤肯定是最差的方案。国外几个主要的交易所之间基本上都有微波（microwave/milliwave）线路，比光纤的延迟要低一个数量级，延迟敏感的应用一定要选择这种线路。但微波技术有两个主要的缺点，第一是在空气里传播受天气影响很大，刮风下雨都会导致通信受损，有时直接故障，所以一定需要有备用的光纤线路；第二是带宽太小，如果是跨交易所的业务，不可能通过微波来转移市场数据，只能用来收发下单指令。第二点给网络服务商提供了一定操作的空间，比如可以自己做一点数据压缩和抽样，就可以在微波线路上提供一个微缩版的市场数据，非常有价值。这块网络服务本身就是一个独立的业务了，一般所说的colocation也是由服务商负责的，HFT主要需要的是选择适合自己的服务商。
网络线路确定以后，数据就送到了HFT主机。这时候需要决定网卡的方案，专用的网卡除了自身硬件的设计外，一定需要的是切换掉系统自带的kernel space TCP/IP stack，避免昂贵的context switching。这个层面上FPGA是很有应用价值的，因为可以做一些额外的逻辑处理，进一步解放CPU。
网络部分的问题解决以后，最后就是核心的业务逻辑的处理。这部分也许会用到一些数学建模，但是没有什么神话，不是什么菲尔兹奖得主才能搞的东西（那些人的用武之地更多是去投行那边做衍生品，那才是真正需要高等数学的东西）。很多时候核心的还是延时，这个在计算机内部分两个部分，一是core的使用率，比如irq balance，cpuisol，affinity等，主要是要尽可能的独占core；另一个是cache invalidation，从L1/L2/L3 cache到TLB，memory layout之类都要仔细考虑，这个更多考验的是对体系结构的理解和程序设计的功力，跟语言是C++还是erlang的关系不大。具体选择那种语言，主要是取决于公司的技术积累和市场上的技术人员供给。
对于FPGA，我同意Nil的回答，业务逻辑烧到硬件里的开发，调试成本和周期都是很难承受的，不看好做为长期发展的路线，这个东西其实和套利，数学模型一样是赚外行眼球的东西。但做专用的网络设备却是比较有优势的。
操作系统同样是一个不需要神话的东西，普通的linux已经有足够的空间用来做性能优化。简单说，一个企业级的linux（如redhat）加上通用的架构（intel主流处理器）足以做到市面上已知的最低延迟，不必幻想有什么奇妙的软硬件可以做到超出想像的事情。
最后需要提醒大家注意的是，其实做一个低延迟系统，首先需要考虑的不一定是延迟能降到多低，而是怎么测量系统的延迟？对一个HFT系统来说，所谓的tick-to-trade延迟，一定要有既精确又不影响系统性能的测试方法才有意义。可以想像一下，最理想的测试场景一定是你的系统真正运行在直连交易所，有真实的市场数据传入的情况下，并且测试的代码就是真正的交易算法时，得到的数据才有意义。如何得到这个苛刻的测试环境，以及如何测量系统的各个部分的延迟，是一个非常有技术含量的工程，难度往往并不亚于系统设计本身。
【余天升的回答(6票)】:
中午吃完饭休息一会回答一个问题。文章里面讲了一大堆latency但是没有讲是什么latency，感觉像是墙壁街为了制造一种高大上形象而再向公众夸张的宣传。题主的描述里面讲了很多快啊、时延啊，但是也把一些概念混为一谈。
那个1ns真是太夸张了，我假设他真的能够在1ns内响应并且完成交易吧，并且这1ns内进来和出去都是一个最短数据包64byte，这1秒的通信量就是128GB，上下行都是64GB/s啊！就算墙壁街的工程师能够实现，也没有哪个交易系统能够顶住啊！这流量直接把竞争对手的系统打残可能更方便。
对于性能和实时性要求都很高的系统，我就见过电网的调度系统。也没有他们说的那么神秘和高端，一般的x86服务器也有，小型机和刀片集群也有。至少两个做主备是肯定的，但是不一定是有集群。操作系统用的也是Linux、UNIX甚至Windows也有不少，也并没有用到实时操作系统。要知道，对于一个省的电网调度系统，数据量也是不小的，那些数据即使用磁带库也存不了多久，无非也就是几天或者一个星期的历史实时数据。
时延（latency）是有好多种的，数据在网络上传输就包括了传输时延、排队时延、处理时延等。我相信他说的时延并不是完成交易地时延，我也相信他并不是每一个ns或者每一个us都会发生交易，他说的实时应该和电网的系统类似，实时地监控正在进行的交易数据，并且不断地用新增的数据进行一些增量计算并做出决策，然后时不时地进行一些交易。也就是监控是实时的，发生在us甚至ns的频率，而交易发生的频率则没有那么频繁，可能只在ms或者us量级。
既然是这样，上面的很多事情也可以比较清楚了。
CUDA是通过显卡高性能浮点计算来提高计算速度的，并不能缩短IO产生的时延。恰恰相反，CUDA计算之前需要把计算数据从主存（内存）拷贝到显存中，计算完成之后再拷贝出来，会增加IO产生的时延。也就是通过CUDA不太可能完成如此短时间内从响应到计算完成返回结果的整个过程。
既然交易不是实时的，也不难理解为什么C++、Java可以大显身手了，他们只需要一个一直在进行高性能计算、并且能够良好扩展的集群，另外有一个东西做高实时性的响应为这个集群监控并且输入实时的交易数据，而这个集群并不需要实时产生结果。像Storm不就是这样子，不断地输入数据然后产生结果的框架么？
【知乎用户的回答(5票)】:
提一部分。为了追求速度一般有如下技术要使用。
首先基本都是成规模分布式系统设计。因为一般都是做全球市场，所以要应对成千上万个并发source分布式是必须的。还要考虑模块崩溃，备用模块启用，所以有一定的计算能力冗余。
核心算法为了追求速度，大量写入硬件，即FPGA。
内部网络进行节点间数据交换会使用infiniband。
TOE（TCP offload engineer)是必须的，也即在网卡上安装硬件（比如处理器）来降低核心节点的cpu处理。
RoCE(RMDA over converged ethernet)，基于以太网的远程内存访问技术。这个不必多说。
还有例如基于hadoop的列文件系统，增加读写io速度使用相当多的ssd。内存数据库，减少对硬盘读写。
GPU并行计算一般在后台使用。
【张弛的回答(1票)】:
【zhuxiaojie的回答(0票)】:
个人不是做软件的，觉得硬件上FPGA+直接光纤开关驱动，据我所知几年前投行就有兴趣了。算法上区别不大，再差的算法用NB的FPGA照样跑起来，不过就是多用硬件资源罢了。除非真是烂到极点的算法，把所有LE都用完了，还要pipeline输出的
另外通讯上，PCI-E 级别的latency 在uS， USB 和ETHERNET在10s us，呵呵，还没跑到算法呢，就已经us去了，还要响应输出等等。FPGA简单暴力。
【shangchan的回答(0票)】:
貌似 Q + （KDB+）的高频系统可以做到极高的频率， 现在基本上大银行都在用这个机制（比如美林， 摩根斯坦利， 高盛）， 正在研究中
【Laughingman的回答(0票)】:
作为一个在校生,我对这个不了解,但根据Prof. Dave Cliff的公开性的政府报告.&Technology trends in the financial markets: A 2020 vision&,FPGA确实被评价为当前最流行硬件解决方案.
但我对这个诛心之论存疑,理由如下:
1,要通讯时延低,必须距离交易所物理距离近,这点自从有交易所存在以来,一直都是寸土寸金;
2,要通讯中间节点的处理时延低,都是专业的公司在租赁其专有网络,甚至是重新搭建新的光纤网络,花费自然不会少;
3,要处理时延低,最好采用专用的硬件结构,如FPGA.相对于软件工程师庞大的基数来说,无论是培养对应的硬件工程师,还是雇佣现有的高价值开发人员,难度同样大.
4,若用通用计算机组成高性能计算集群,这个应该是传统的主流方案,正如 提到的,相对于FPGA而言,更易于更新.但可能某些场景,对处理延迟有更高的要求,根据上面提高的报告来看,是软(4)硬(3)结合是其预测(或者当下)的趋势.
5,其实我个人认为,门槛主要体现在监管方面,毕竟涉及金融,波动面大,直接连接交易所的用户还是极为有限的.虽然上面的报告提到未来的交易所肯定会更为开放,但鉴于此行业的特殊性,类似于牌照的门槛应该仍然大于技术门槛.
【蔡磊的回答(0票)】:
不懂这些东西，之前感兴趣了解了一下，感觉所有策略都是非常快糙猛的，完全用不到什么复杂模型（难道我打开的方式不对），所以题主说的“模型比较复杂”恐怕不成立，这些简单的策略完全很容易放到FPGA上实现。
就我的理解HFT完全就是靠“快”所带来的信息不对称来赚钱。
至于它为啥快，搬个小板凳看各路神仙的回答。
【WenguangLiu的回答(0票)】:
latency的单位通常是us，ns是用来评估fpga做的feed handler，risk checker和相对少见的market hitter的wire2wire延迟。
一般说来有两种latency，自己系统的tick2trade或者trade2trade的internal latency，和大家都在拼的order round trip latency。两者通常也是用us来评估。
【项磊的回答(0票)】:
哦，各种理伦优化。理伦上也可以完全替换tcp，把交易系统烧进nic里。纳秒级包处理完全没问题。
顺变说一下，德国去年已经立法监管，限制此类高颖交易，那些拿华儿街钱的政客们还没有表示。
【宓俊的回答(0票)】:
【Nil的回答(2票)】:
重新写下。 问题作者那个把软件写到FPGA里面的思路绝对是错的 理由见下文。。还有你说的那个latency是指的网络传输速度 是信息的速度 和操作系统无关。网速上纳秒是可以实现的 光纤长度短就好 不过一般没人有钱弄纳秒的。。太贵了。
美国现在最快的是这样架构的：
操作系统用linux 我见过的用redhat的比较多。 lightweight
交易服务器在总交易服务器隔壁 通过最短高品质光纤直连 光纤长度10米-50米看你给钱多少。硬件就这样了。。。这是最好的了。再短就犯法了阿啊哈哈。金融交易的科技人员大概看得懂总交易服务器吧。
软件方面语言使用 Scala。这是现在最scalable和maintainable的语言了。新出的nodejs也不错，但是没有Scala那么maintainable。推荐大家看看Scala 谁用谁知道 亲手把30分钟的运算时间弄到了10秒以内 唯一改的只有从到 scala。
前面顺手翻了下其他答案 都是讲FPGA的。其实嘛，那个完全没有必要甚至是错误的方向。写到硬件里面提升的速度完全可以用软件达到。写到硬件里面的的确快了一点点但是这种软件最大的缺点在于很难更新。高频交易每天都会更新算法的 更快的每几个小时就更新算法了。你难道每小时进机房换芯片？一套算法吃到死的时代已经不在了。想像下刚写了个算法 想要试跑市场测试然后发现公司的算法全写在FPGA上是嵌入式的。估计写算法的会哭把阿哈哈哈。
【pigpig的回答(2票)】:
笑喷了，从来没有这么快乐过。
花了半个小时看完了题目以及各种答案，看似各种计算机专业名词、术语堆砌在这里，看似各种仿佛计算机专家般的思路与逻辑，但仔细一瞧，全都是海阔天空地胡说八道。而且整个话题居然还涉及机房建设、硬件、软件系统设计与实现、计算机通信、编程语言、操作系统、编译原理等科目。我的脑海中不禁浮现出一个画面：一堆幼儿园的小朋友坐在地上欢乐地聊着未来的科技发展。
不过，答案里也有明白人，比如
【@张弛，期货+IT】，他用简短的4个字概括了整个问题与答案："一帮水友"。
我记得我关注的是计算机类的话题，不知道为什么知乎会把我引入这个金融圈的话题里。因为我发现，这个话题里的题主，以及大部分答主，基本上都是金融专业的。因此，我想说：隔行如隔山！建议各位金融专业的国家栋梁们，不要对计算机专业进行跨行猜测，因为计算机领域里的东西太复杂，太难！不是你们能玩得转的。最欢乐的是居然有人把FPGA和微波通信扯出来了，笑掉大牙。
如果题主真心想弄清楚这类工程怎么做的，我给你两个建议：
1.去找一份这种工程的真正的需求文档，而不是那种不知道你从哪个小朋友那里听来的“时延为纳秒”的这类动动脚趾都能想清楚是扯蛋的系统性能指标，一看就知道是被中小学科普类文章给洗脑了，因为这类文章最喜欢鼓吹计算机的计算能力如何强大，每秒能运算多少次等等，看看淘宝的系统，不说是中国互联网金融的领袖，但至少也算是一霸，它在2013年双十一每秒订单接近4千时就已经到了崩溃边缘，12306在技术改造使用内存数据库后，连查询功能（还不是订单功能）都只能保证最多每秒1万次左右，每次查询最少也需要20毫秒。
2.拿到需求文档后，带着这份文档，去咨询一下真正做过这类项目的计算机专业的系统设计师或架构师，而不是那些喜欢跨专业的金融人士。因为真正的答案与这个帖子的答案相差十万八千里。
【王磊的回答(0票)】:
据说一个中等规模的HTF商每天成交量几千万笔，如果按每天8小时算，如果按每次只下1个订单算，算下来，每秒要下上千个订单，所以ms级是必须的
FPGA是主流，但未必只用来做算法，比如很多用来做网卡协议的解析等，这些是一次写入就不用变了
GPU不大适合，IO时间浪费很多
一般的HTF商至少2根网线，1根只用来接收数据，1根只用来发送数据，也许这么做会提高一些网速
&&&&&本文固定链接:
【上一篇】
【下一篇】
您可能还会对这些文章感兴趣！
最新日志热评日志随机日志这个链接给出了大量信息。&但问题是这里的信息覆盖了所有可能。从FPGA,GPU到C/C++到Java/.NET到Erlang/Haskell。有意思的是有人在回复中说高盛被偷走的主要是Erlang代码。很显然，不同公司的方案大不相同。但让我费解的是，不同消息来源暗示的关注点完全不同。比如说，有消息来源说只有性能关键的少数部分是C++，而也有消息来源说latency已经达到了nanosecond级别，而且至少都是us级别。latency达到nanosecond级别是非常疯狂的，因为航空航天的realtime只能到几十us的程度。这意味着任何操作系统都将成为累赘，甚至baremetal的软件也达不到此要求，唯一可能是把逻辑全部写在FPGA里。无法想象能用FPGA实现极其复杂而且高度变化的数学模型。好吧，假设有这样的硬件存在并可商用，那么如此辛苦得来的高效如何与C++甚至Java并存呢？别说软件，哪怕是memory bus都将成为瓶颈。而又有消息指出被广泛使用的操作系统是Linux。Linux最多介入下软实时，这还都是得在mainstream上单独打patch才能勉强过关，在比硬实时还高一个级别的场景里不可能用的上。还有些信息来源指出FP的广泛应用，这可以理解为对程序正确性的要求，但在密集浮点计算领域根本没FP什么事，占统治地位的还是FORTRAN。不知道有没有把FP编译成CUDA目标的编译器存在？诛心之论，是高频交易界故意模糊视线并人为抬高门槛。哪怕高频交易中的经济和数学模型再天外飞仙，在软硬件架构上还是得落地，因为目前技术极限在这摆着，再加上相互矛盾的信息来源也暗示了故意搅浑水的可能性。但我的这些想法全都没有确凿证据，隔行如隔山。希望有专业人士指点一二。谢谢。------------------------------update ------------------------------看了几位的回答后，意识到有不少概念没讲清楚，连问题本身也没有明确。遂更新如下。1. 具体在问什么标题其实很清楚，就是想知道一个实际运行的高频交易系统的软件和硬件架构。其中应该包括网络拓扑，硬件资源，软件结构等等等等。但我还顺便掺入了我对HFT报道的怀疑，也就是到底HFT采用的硬件和软件是不是跟广告中说的那么神奇。2. 对latency的定义按原文中的描述，是"ultra low latency trading"，并且是"wire-to-wire"的。我的理解是，一个HFT的计算节点，有能力在几百ns内处理完一个网络上接收到的信息包，并将结果返回到网络上。这个信息包从物理上来说是一个IP packet，所谓的“接受”和“返回”，指的是从直接连接这个计算节点的router的角度来观测的。3. FP指的是Functional Programming。因为那篇文章反复提到了Erlang/OCaml/Haskell/Lisp。我之所以会提到编译器，是因为文章同时反复提到了CUDA，因此我猜测既然又要利用FP逻辑不容易出错的特性，又要利用CUDA的SIMD/SIMT特性，那这个接口工作交给编译器是不是更方便些。4. realtime在这里我语焉不详并混淆了概念。确实，软实时还是硬实时指的是任务完成是否有guarantee或者说上限。我真正要表达的意思是，以我的了解，不用硬件解决方案不可能达到ns数量级。（下面会补充说明）5. 为什么我理解HFT的逻辑是复杂并多变的因为首先做HFT的都是理论物理，数学方面的博士教授甚至菲尔兹奖得主。所以其逻辑肯定是非常复杂的。其次，从文章以及其它描述HFT码农的文章来看，HFT码农面对持续的高压，并且要快速做出修改，甚至是online的修改，所以我猜测软件需要实现的逻辑需要持续的修改。6. 关于现在工业上的network stack能做到多快，我有一些第一手的资料我个人提交了两个feature的补丁给DPDK并被接受，所以我还是比较了解DPDK的。另外我还propose了一些Intel 10G NIC driver的补丁。并且我也实际测试过DPDK+10G PCIE的thruput和latency。结果很不妙。关键不在DPDK或者网卡或者cache或者CPU或者bus，而在Linux。只要是跑在Linux上的-无论usr space还是kernel module，都注定达不到ns的latency，甚至连us都达不到。这都归咎于无处不在的soft irq和sched。是的，我知道affinity和cpuisol，没用，真的。虽然我没接触过连PCIe都嫌弃的方案，连DMA都订制的方案，但我认为瓶颈不在那，根据Amdahl那些改动没有用。另外，这还没考虑HFT自己的逻辑，按那篇文章的介绍，不管是FPGA还是GPU实现的浮点计算，那么光是数据从网卡到bus再到GPU然后再回来，加上GPU计算--这都还没考虑CPU的调度带来的损耗--能在1000个cycle内跑完就算很不错了。ok，废话可能太多了点。总之我想说的是，从文章（SO上也有类似问题及回答）来看HFT有一些不差钱的解决方案，但这些不差钱的方案却又不是整个系统的瓶颈所在，相反，HFT还为了向正确性/可维护性妥协而采用了大量减慢系统的方案。这是怎么一回事？到底是因为HFT就是这样（是的我就是钱多，我吃一碗倒一碗），还是HFT的宣传全是不符合事实的？
>>>>>>支持本博小组的用户 start -->
首先，我不是专业搭这个的……所以我基本都是瞎猜的……
其次，不太清楚这一大段问题具体是在问什么……
您是不相信latency能做到1ns？我也不信。如果收发buffer的latency是1ns，假设光纤上跑的是数据包，响应的时候接收器会把整个包存下来，再发一个响应包（store and forward）。那么，40G的光纤，1ns就只有是5个Byte。如果传输latency是1ns，光才跑30厘米……
也就是说，如果你的电脑离交易所的数据中心有几千米远（比如你在东单而它在西单），那么传输的latency也有几个ms，给你一个700ns就能响应的交易系统也帮不了你很多忙，更简单的办法是把电脑搬到交易所旁边去。
不知道问题里说的硬实时是什么……一般说硬实时是说deadline是死的，系统必须在deadline之前完成任务，没有通融。理论上说，deadline在一小时之后的硬实时也是硬实时……
数学模型很少是高度变化的……就是一交易程序，都是人写的，其变化的速度取决于人认识问题和写代码的速度，不取决于计算性能（除非程序是计算机自己写的，而且计算机已经智能到可以在毫秒之内自己写出新的程序，并立刻跑几个毫秒，然后几个毫秒过去之后再写一个新的……不是不可能，但是目前还比较科幻……）。所以短时间内，程序基本是不变的，模型框架基本是不变的，变化的只是输入的数据和模型参数，理论上没什么不能用FPGA实现的。
最后说说现在商用硬件的性能。
首先，你随便找两个机器，网线直连，ping一下，RTT也就200us左右。
如果要更快更稳定呢？
假设你跑Linux，从网络走，10G的光纤接进来，网卡插在PCIE bus上，网卡直接接入user space （比如用类似 DPDK 的东西），或者直接写个kernel module，bypass掉整个linux的network stack，关掉网卡的interrupt coalesing，pin到一个core上，latency其实挺小的。整个东西warm起来之后，除了接收的数据之外基本不会有cache miss，收发包都没有memory copy，PCIE bus可能会有一些不确定的latency，但总的latency可以做到绝大多数情况下都小于20us。这是全在商用的PC上做，而且完全不用给linux kernel打patch，kernel module都可以搞定。
如果你告诉我这帮做事没什么底线的人完全不走PCIE，自己订做了自己的DMA接口，我也不会很惊讶……那就基本只剩memory了。memory其实还是挺快的。一个cache miss不会多于1us。
如果还要更快的turn-around，那就把memory也省掉，比如可以弄NetFPGA（价钱就贵很多了，但这帮搞金融的可能根本不在乎……），省掉PCIE bus和memory，基本只有调制和解调的latency，响应逻辑做到cut-through也是可能的。700ns在一个200MHz的clock上有140个cycle，parallel起来还是能做很多事情的。
FP是什么？
（我感觉您心里是早就已经有答案了，觉得注定达不到，新闻就是扯淡……所以这时候别人都像是在要说服你，而不是在回答问题。如果不做实验，靠嘴说服是一件很难的事情……所以下面的答案更多的意义是我自己的装逼，您心情不好就别看了……）
我听说的结果是至少在throughput上DPDK可以很轻松地把40G的link用MTU塞满……不知道您那个结果很不妙指的是什么……
10G link上一个1500B的MTU从开始收到检查完CRC，都要1.2us，这基本是速度的下限了。实在不知道为什么还要追求ns级别……
Linux scheduler的overhead，在发送端，在CPU上跑的kernel thread（不自己主动调用schedule()）只会被interrupt打断，在一个空闲的机器上，除了网络IO interrupt之外的其他interrupt密度是极其稀疏的，所以基本上就是dedicated core。没有interrupt时，scheduler根本都没有被执行，哪儿来的overhead？在接收端，NAPI接收到interrupt之后就把interrupt关掉改pulling了，把coalescing关掉之后在10G nic上接受line rate平均5个MTU packet就会pull一次（查interrupt counter能查出来），也就是irq context switch的开销（因为都在kernel里，所以不用刷TLB，只存一下断点就可以了）顶多是6us，平摊到每个packet的接受的latency是3us。几周前自己刚测的。So，您的第一手资料是？
1000个cycle够做一个相当规模的并行FFT的了（并行是O(logn)的，如果没记错的话）……从来没玩过HFT，但我能想象的HFT需要实时响应的也就是到了某个时间点/成交量/价格/指标值的时候赶紧买进/卖出。具体的各种trigger值应该都是早就准备好了并且是随时间连续变化的。另外，NetFPGA的FPGA会放在网卡上，就不走CPU了……
为什么functional language就不会用SIMD？难倒不是该用啥用啥？
总结一下：
(1) 10ns以下或左右的wire-to-wire latency不现实也不需要。10Glink上20个Byte都不到，header还没看全呢，光才跑3米。
(2) 其实没人刻意宣传ns级别的latency（700ns四舍五入一下也应该算1us了吧），ns latency其实是问题作者自己假想的……
(3) 对于其他东西的描述，问题作者很多认识都不是很靠谱。但由于(1)已然成立，所以这些其他东西本来也不怎么相关，所以认识靠谱与否其实是无所谓的事情。
中午吃完饭休息一会回答一个问题。文章里面讲了一大堆latency但是没有讲是什么latency，感觉像是墙壁街为了制造一种高大上形象而再向公众夸张的宣传。题主的描述里面讲了很多快啊、时延啊，但是也把一些概念混为一谈。
那个1ns真是太夸张了，我假设他真的能够在1ns内响应并且完成交易吧，并且这1ns内进来和出去都是一个最短数据包64byte，这1秒的通信量就是128GB，上下行都是64GB/s啊！就算墙壁街的工程师能够实现，也没有哪个交易系统能够顶住啊！这流量直接把竞争对手的系统打残可能更方便。
对于性能和实时性要求都很高的系统，我就见过电网的调度系统。也没有他们说的那么神秘和高端，一般的x86服务器也有，小型机和刀片集群也有。至少两个做主备是肯定的，但是不一定是有集群。操作系统用的也是Linux、UNIX甚至Windows也有不少，也并没有用到实时操作系统。要知道，对于一个省的电网调度系统，数据量也是不小的，那些数据即使用磁带库也存不了多久，无非也就是几天或者一个星期的历史实时数据。
时延（latency）是有好多种的，数据在网络上传输就包括了传输时延、排队时延、处理时延等。我相信他说的时延并不是完成交易地时延，我也相信他并不是每一个ns或者每一个us都会发生交易，他说的实时应该和电网的系统类似，实时地监控正在进行的交易数据，并且不断地用新增的数据进行一些增量计算并做出决策，然后时不时地进行一些交易。也就是监控是实时的，发生在us甚至ns的频率，而交易发生的频率则没有那么频繁，可能只在ms或者us量级。
既然是这样，上面的很多事情也可以比较清楚了。
CUDA是通过显卡高性能浮点计算来提高计算速度的，并不能缩短IO产生的时延。恰恰相反，CUDA计算之前需要把计算数据从主存（内存）拷贝到显存中，计算完成之后再拷贝出来，会增加IO产生的时延。也就是通过CUDA不太可能完成如此短时间内从响应到计算完成返回结果的整个过程。
既然交易不是实时的，也不难理解为什么C++、Java可以大显身手了，他们只需要一个一直在进行高性能计算、并且能够良好扩展的集群，另外有一个东西做高实时性的响应为这个集群监控并且输入实时的交易数据，而这个集群并不需要实时产生结果。像Storm不就是这样子，不断地输入数据然后产生结果的框架么？
你还不是该小组正式成员，不能参与讨论。
最新话题 &(
(阿娇理财)
(今彦析金)
(披沙简金)
(阿娇理财)
(阿娇理财)}