a****n
发帖数: 230 | 1 目前做一个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问题还是无法解决.希望哪位有经验的大侠给点意
见... | l***g
发帖数: 1035 | 2 tcpip takes how long?
【在 a****n 的大作中提到】
: 目前做一个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
| a****n
发帖数: 230 | 3 We did not try tcp/ip, since I got this project after they decide to use the
udp.
It is fast, but painful for me....
【在 l***g 的大作中提到】
: tcpip takes how long?
| a****n
发帖数: 230 | 4 according to the microsoft website, its Dictionary search time is 0(n). Do
you know any other container that can do the job faster? thanks... | T*******i
发帖数: 4992 | 5 no. because the data from the market is broadcasted with udp.
the
【在 a****n 的大作中提到】
: We did not try tcp/ip, since I got this project after they decide to use the
: udp.
: It is fast, but painful for me....
| a****n
发帖数: 230 | 6 Actually they offer tcp/ip also, but I guess it is slower compared to udp,
right?
You have experience with udp before? thanks.
【在 T*******i 的大作中提到】
: no. because the data from the market is broadcasted with udp.
:
: the
| b***y
发帖数: 2799 | 7 你要好好研究一下,瓶颈在哪里, 是在UDP纠错,还是在后面MAKEBOOK慢.
如果在UDP,那MAKEBOOK是非要等待吗?完全正确的包,是不是可以先算.
如果在MAKEBOOK,那就要改进算法,升级硬件.
如果你的硬件是瓶颈,再多线程也没用.
【在 a****n 的大作中提到】
: 目前做一个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
| g*****g
发帖数: 34805 | 8 单个包很重要，就不该用udp，udp主要用在音频，视频这种
可以容错的应用上。
【在 a****n 的大作中提到】
: 目前做一个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
| p*u
发帖数: 2454 | 9 为了减少context switches，没办法，而且是doable的。
【在 g*****g 的大作中提到】
: 单个包很重要，就不该用udp，udp主要用在音频，视频这种
: 可以容错的应用上。
| m***t
发帖数: 254 | 10 the original post does not make much sense to me. so
udp connection -> unpack -> filter -> makebook,
so if there is error in udp packet, you donot clear the buffer till the new
response comes in to correct the error? then thread stack overflow happens
at unpack stage?
if i were you i will test first part first. given If that does not give you
problem, i think it might be you are not dequeing thread buffer incorrectly
at latter stages. | | | s******e
发帖数: 431 | 11 后面的应该比前面的快，这也是一般使用buffer的原因。
但是你这个后面的比前面的慢，解决方法要不让前面慢点，要不就得想办法加快后面的
处理速度。看看make book或者filter能不能用多个thread 并行处理。
【在 a****n 的大作中提到】
: 目前做一个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
| a****l
发帖数: 8211 | 12 所以说,"一将无能,累死千军"。数据的顺序和完整性（好象还有时间限制？）都很重要
还用UDP？我真怀疑你们的Architect是不是不知道UDP和TCP的区别。至少在设计上早就
应该考虑到丢包的解决方法了。
【在 a****n 的大作中提到】
: 目前做一个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
| n******t
发帖数: 4406 | 13 路子不对。。。
【在 a****n 的大作中提到】
: 目前做一个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
| x*********h
发帖数: 25 | 14 在数据发送端就应该做好数据流的pack工作，一次传输多个包，不用一个包一个包的传
输，
几微秒一个包，用tcp流的方式传输其实不比udp效率差多少。 | a****n
发帖数: 230 | 15 这两天发现udp接受过程中经常一段时间收不到任何数据，但是理论上market是在不停
地Broadcast的。
导致很多错误。。。。
大侠知道可能是什么原因导致的吗？谢谢
【在 x*********h 的大作中提到】
: 在数据发送端就应该做好数据流的pack工作，一次传输多个包，不用一个包一个包的传
: 输，
: 几微秒一个包，用tcp流的方式传输其实不比udp效率差多少。
| a****n
发帖数: 230 | 16 你可以稍微具体展开说一下吗？谢谢
。。。。。
【在 n******t 的大作中提到】
: 路子不对。。。
|
|
