a**n
发帖数: 97 | 1 因为是embedded system, 不能用比如UNIX下的系统函数。而我又需要知道精确的绝对
时间。不知道怎么实现？希望做firmware 的牛人帮忙解释一下。万分感激！ |
|
b******a
发帖数: 215 | 2 用板子上的硬件timer,一般都有两个timer吧，一个高精度的，一个低精度的。直接去读
寄存器好了。 |
|
b******a
发帖数: 215 | 3 这个没有办法吧？
这种timer应该是系统复位后或者达到最大时间后就归零了。 |
|
a**n
发帖数: 97 | 4 谢谢。我觉得也是。要不就是所有其他板子都用主板的时钟/timer 同步。 |
|
j****g
发帖数: 597 | 5 There's a standard called IEEE 1588 |
|
r*********r
发帖数: 3195 | 6 大家都用什么工具？
我用gprof, 但有时候发现它精度不够，小点的函数在毫秒量级都是零。
能不能让它用微秒？
很久没有用VS了，以前记得它是带profiler的，但是在 vs 2005 pro 下没找到。
where did it go? also, what's the profiler's precision? |
|
a****n
发帖数: 230 | 7 目前做一个real time的股票trading book系统,具体就是用UDP协议从市场读进data,然
后unpack,然后做filter,然后构建一个trading book.
data->unpack->filter->make book
其中信息的顺序和完整性很重要,可是可恶的udp会丢失一些数据,只能过后发request要
丢失的数据,来了的又不能让等着(超不多几个微秒一个数据包),其实丢失的概率也就是
百万分之一的机会...,但是关系重大,不能忽视. 代价就是filter要花很长一段时间(
20ms),然后做这个Book也要花~80ms. ( 重建的filter基本干得就是search的工作,我差
不多都用了hash-table 0(n),或者大家有更好的算法....)
我按照上面的箭头每一步做了一个thread,然后之间做Buffer承接,结果可像而知,越到
后面的步骤越慢,buffer过了一段时间就会暴掉memory.难道只能靠多买些physical
memory吗?
第一次开发一个软件,out of memory问题还是无法解决.希望哪位有经验的大侠给点意
见... |
|
x*********h
发帖数: 25 | 8 在数据发送端就应该做好数据流的pack工作，一次传输多个包，不用一个包一个包的传
输，
几微秒一个包，用tcp流的方式传输其实不比udp效率差多少。 |
|
b***y
发帖数: 2799 | 9 ☆─────────────────────────────────────☆
alfven (rik) 于 (Fri Sep 5 15:19:15 2008) 提到:
还是有关udp的问题，Filter的部分已经解决了，现在问题是udp数据很快，不能完全接
收。
我尝试了两个方式：
1。接受数据thread写到deque做的buffer后面，然后让第二个thread读deque的前端，
一天下来能miss1百万条。
2。一接受到数据就直接写到Binary文件里面，一天下来Miss个6000条out of
400million条。
比较了一下两个的时间，第一个插入buffer通常要1微秒，第二个直接写才要～400ns，
觉得有点意外，是不是这个file stream的buffer要更好？
由于以后要加入real time的filter，肯定是要写在内存里面，怎么才能提高速度，不
让数据丢失呢？考虑过增加udp socket的buffer size，但是速度跟不上还是不行的。
考虑提高写buffer的速度，尝试了一下用大数组做buffer，假如不考虑thread safe， |
|
b***y
发帖数: 2799 | 10 ☆─────────────────────────────────────☆
tookoo (tookoo) 于 (Sun Oct 9 20:51:38 2005) 提到:
发信人: tookoo (tookoo), 信区: Linux
标 题: Linux/Unix下时间的精度
发信站: BBS 未名空间站 (Sun Oct 9 20:51:07 2005), 转信
Linux下面的C编程，
想计算一段程序的执行时间，
我现在用time()来取时间，
它的精度太差了，
只能精确到秒，
有什么函数可以取到更高的时间精度吗？
譬如，微秒，毫秒什么的，
谢谢。
☆─────────────────────────────────────☆
openworld (hello!) 于 (Sun Oct 9 22:00:13 2005) 提到:
jiffy
see /proc/jiffy
☆─────────────────────────────────────☆
zjuminnow (swim in the water) 于 (Tue Oct 11 0 |
|
O*******d
发帖数: 20343 | 11 我工作过的几个地方，凡是微米，微秒都用字母u。 我统统给改成μ |
|
xt
发帖数: 17532 | 12 墙街不玩web，玩的是怎样能够把交易速度加快到比别人更快的地步。
GS以前的老把戏就是使用自己的系统，在证交所插单子赚钱。比如
一个单子进来，还没有进入证交所系统之前，他们先率先插入一个
单子，让那个单子买入更高，或者卖出更低，这个用Java只会耽误事。
实际上，NYSE多年以来的一个问题，就是现在里面的server floor已经
没有空间了，所有人都想把自己的服务器挂到证交所，这样他们可以比
别人快几个微秒。 |
|
g*****g
发帖数: 34805 | 13 没有这么夸张。4.x秒的exchange根本没法用。从几百微秒降到100出头。
原来的系统多半到了加硬件也不能降latency的处境，才会重写。
http://linux.slashdot.org/story/10/10/24/207204/lse-breaks-worl
"The London Stock Exchange has said its new Linux-based system is delivering
world record networking speed, with 126 microsecond trading times. The news
comes ahead a major Linux-based switchover in twelve days, during which the
open source system will replace Microsoft .Net technology on the group's
main stock exchange. The LSE had long been criticised on spee... 阅读全帖 |
|
|
x****u
发帖数: 44466 | 15 纳秒级中断不是普通硬件系统应付的了的，微秒级中断也是代价非常大的。 |
|
T********i
发帖数: 2416 | 16 给我这么多钱，要求用quick basic我也能做到。
金钱相关的我也一直在做，都是每天交易上亿美金的系统。运行数年无故障的。
几十台服务器，延迟在个位微秒的实时系统。 |
|
T********i
发帖数: 2416 | 17 这个必须是存储相关的。每个transaction都有log。log后才算数。
其实一个multicast给其他打酱油的待机服务器，然后收到ack。这个log的transaction
就算完成了。
这个过程大约5微秒。但是stream line的through就可以是最大带宽。
因此，我的系统最简单，最安全。每行代码都能被audit。而且可证明是技术的极限。 |
|
T********i
发帖数: 2416 | 18 你忽略的是什么？
你根本没搞清楚春运系统的难点：
1. 全国一盘棋。任意两点任意方向都有需求
2. 读写要同时优化，写数据可能只有那么几亿条。读请求会多几十上百倍。很多人一
直刷屏。
3. 瞬时负载。要做好在几十分钟内每秒几十万上百万请求的准备。
4. 动态规划，要兼顾用户优化和全局优化。比如某路段最抢手，但是还要考虑经过这
个路段的其他长途旅客。
你的那个数据库怎么应付瞬时激增的请求？
我的设计，就是我的核心取代你的数据库和cache，以及transaction manager。
主要针对上述1，2，3点。因为第四点能够分布。
我的核心输入很简单：
1. 查询:
输入： Route List + Constraint filter (时间段， 座位等级 etc)
输出： 没票：
或者有票： 每节点班次和剩余座位数
2. 订票：
输入： 上次查询结果
输出： 是否成功？（其他人可能抢先）
3. 退票： 或者几分钟后银行确认失败取消
输入： 班次座位列表
输出： 永远成功
就是这个server，这个是核心，我的方案比你的处理能力高两个数量... 阅读全帖 |
|
T********i
发帖数: 2416 | 19 两台机器ping pong guarantee两位数微秒内RTT的你听说过么？ |
|
T********i
发帖数: 2416 | 20 咱们先一个个地解决问题。我说这样两台机器，挂在一个switch上，
保证两位数微秒级别的ping pong rtt。你有意见么？ |
|
f****4
发帖数: 1359 | 21 讨论设计方案，必须有个背景才有意义。这个卖春运火车票的网站就是个很不错的例子。
比较方案的时候，可行性是根本，都可行的情况下考虑成本。可行性里面需要考虑到
performance，availability,scalability，工期还有系统的复杂度。这些都是讨论的
基础，你不能简单的说“你这方案比scalability比不上分布式，比响应比不上硬实时
系统”。没有方案是完美的，我们现在只是在给定的案例下面讨论两个不同的实现。如
果背离这个约定，那就又成为毫无意义的口水帖了。
因为有些人根本不仔细看别人帖子，我把2个不同方案的实现，大家提及的疑问及解答
，按照我的理解复述一下，也请魏老师和goodbug指正。当然了，我主要复述一下魏老
师的方案，毕竟分布式的大家多少都了解一点。
主机配置，4个10G/s网卡，全双工80G/s，对CPUS没特殊要求，内存没提，不过现在服
务器上到90+CPUS，36+G内存也就是5万美金，魏老师声称1万的主机还算靠谱。
魏老师在后面的帖子针对availability的问题提到了hot standby server，3zone，多
hot standby ... 阅读全帖 |
|
|
T********i
发帖数: 2416 | 23 任何一个项目，都可以不拘一格。关键你基本功要够硬。
纽约到芝加哥CME的数据专线。为了比别人快那么几个微秒。几家都是几百个million往
上投入。RTT从15.7到14.8到13.4，差一个毫秒每年使用费就差了几个million。
光纤毕竟不走直线，靠折射。有人尝试用微波无线通信。绝对走地球曲线。RTT
降到8以内。一夜之间，NASDAQ旁边一座小山一夜之间布满天线。
下一步是什么？中微子通信？穿过地壳走直线？cern的科学家和加速器可能用得着了。 |
|
T********i
发帖数: 2416 | 24 一个大型系统必须有一个failover的完整方案。近日讨论中发现，网友在这个问题上多
存误解。而且很多错误认识竟然大行其道。
为再次避免谬种流传，不敢自匿，特公诸于众：
其实，这里面每一个事实，我都已经于多天前提到了。
Complete Failover Handbook
废话少说，failover方案一般2种
1. 同步写盘
2. 同步写网络（必须等ACK）
其他还有一些组合，比如异步写盘+同步写网络等等
现在看看同步写盘：
普通磁盘：
这个其实最复杂，为什么。因为我说过，磁头seek 5-8ms，转速4500-15000 RPM。
文件系统不好做就是要为磁盘做优化。因为磁盘的寻道seek太慢，因此尽量让文件水平
放置在磁道上。因为顺序读写sequential最普遍。磁盘转速太高sector扇区的编码还要
隔开。这样读完一个扇区OS发请求的间隔时间内，刚好转到下一个扇区。
同步写盘因为到达时间随机，基本上需要平均等半圈，这样平均按照15000 RPM算就是
15000 / 60 × 2 = 500次每秒。实际上数量应比这个低因为会seek。
当然如果sequential不间断同步写盘... 阅读全帖 |
|
T********i
发帖数: 2416 | 25 发信人: TeacherWei (TW), 信区: Programming
标 题: Re: 写一个Complete Failover Handbook吧
发信站: BBS 未名空间站 (Tue Nov 26 22:15:29 2013, 美东)
好好读一读我的帖子。我的设计和我现在用的不一样。那个是multicast同步复制的。
即使我异步复制，甚至不复制都没有问题。下游多串几台机器串联就好了。那就和现在
用的设计一样了。任何一台挂了，上游下游的机器补足状态。
关键的是latency增加几个微秒。复杂度增加几乎为零。因为代码一样。throughput不
变。
最关键的，我的系统实现简单。throughput高你几个数量级。而且全状态跨区failover。
请注意我的上周五第二贴，消息系统才是理论上最合理的系统。 |
|
T********i
发帖数: 2416 | 26 你丫不可救药了。
不用说主力DC跟下游断了，by design要拒绝服务。
就算主力DC继续处理又怎样？继续接受请求cache请求到QUEUE而已。不和下游通信，没
有下游ACK他又不能和客户确认订单。
再告诉你也个窍门。一般任何时候主力DC写网络，物理连接断了，router会立刻拒绝。
这是微秒级别的。
吧。 |
|
T********i
发帖数: 2416 | 27 成天发贴的那帮，又不是有任务，也不是拿钱发贴的，那么激动地党同伐异为了啥？
有这功夫，好好修炼一下基本功好不好？
双CPU单机的性能，40G全双工没问题，Solarflare 7122F号称每秒2000万messages。我
用6122F每秒500万72 bytes的message，两年从来没丢过一次包。我用的是UDP包。当然
用TCP性能几乎一样，而且更靠谱。
Multicore concurrency，公开资料根本没有，知道的都不会说。
我这里可以透漏一些常识：
1. NIC的socket API是专用的，可以完全Kernel bypass，现有的使用socket IO的程序
甚至不用重编译。参见OpenOnLoad。
2. 系统的网卡不是越多越好，在最新的Sandy Bridge及以后的架构下，每个CPU挂一个
网卡最优。
3. Socket I/O用一个线程操作最优。一个线程的Socket I/O throughput是最大的。道
理是什么，自己去想。但是我可以肯定地讲，本版跳的最起劲那几个Java大牛根本没有
认清这个问题的基础知识。
4. 双CPU一共16个Core (8X... 阅读全帖 |
|
T********i
发帖数: 2416 | 28 你开玩笑是吧？我的latency要保证确定性，是个位数微秒。Node还不够格。 |
|
T********i
发帖数: 2416 | 29 每秒500万次，lock duration都是个位微秒级别的。 |
|
g*****g
发帖数: 34805 | 30 别忘了你一次要锁20个段，联票更多。一个锁微秒级别都不够。 |
|
n****6
发帖数: 570 | 31 几个人微秒不行吧，就算一个微妙，也才一个M,如果五百万至少五个线程这还只是锁 |
|
T********i
发帖数: 2416 | 32 我的方案成本降低了一个数量级，铁道部肯买才怪。
如果我要是傻到做铁道部的生意，那是我自己傻逼，怪不得别人。
不过说到可扩展性，我的方案其实更好。在线数据修改/扩展都是微秒级别的。即使暂
时下线升级程序也可以做到秒级，因此结构太简单了。
至于这个好虫，有确凿的证据证明此人OS和Architecture都不及格。这个是难以想象的
。 |
|
g****t
发帖数: 31659 | 33 不是成本问题。
我说了，你的方案不predictable,太特殊。
如果我有新的需求过来，你可能要重新设计整个东西。
有一种图灵机模型，就是几个箱子挪来挪去。
买票占座位的需求是很可能及其复杂的。说不定是图灵完备的都未可知。
另外还有桥断路垮，首长出巡，冰雨地震，这些情况，在你的那种设计中，
都需要一个个仔细研究。
好虫的方案，估计做起来和填空题类似了。
好虫的方案容易扩展，with respect to 新需求。
而且他懂的折磨屁民提高体系稳定性这个阳光大道。系统不行就加延时。
其实全国分时段订票都可以。
你是把用户当上帝了。这是不对的。
你有你牛的地方。假如你站出来说，给我20万刀，我给你弄个全球最快bitcoin机器，
我会给你。好虫或者赵策等等，我觉得不会作“全球第一”类型的东西。
我的方案成本降低了一个数量级，铁道部肯买才怪。
如果我要是傻到做铁道部的生意，那是我自己傻逼，怪不得别人。
不过说到可扩展性，我的方案其实更好。在线数据修改/扩展都是微秒级别的。即使暂
时下线升级程序也可以做到秒级，因此结构太简单了。
至于这个好虫，有确凿的证据证明此人OS和Architectur... 阅读全帖 |
|
