请教一个信号发生的问题 - 未名空间MITBBS历史存档

请教一个信号发生的问题# EE - 电子工程

w*n2008-03-25 07:03

1 楼

还刚说着赏秋，居然下雪了。
才看到这新闻，联合国于10月20日至31日在纽约举办中国美食节，无奈只是工作日，
周末没有。。。
http://www.mitbbs.com/article/NewYork/31208503_3.html

a*n2008-03-25 07:03

2 楼

目前做一个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*e2008-03-25 07:03

3 楼

有一个信号源，可以产生某种频率的正弦信号，现在我想把这个正弦信号加一个DC
offset让它都变成positive的，应该怎么弄？
谢谢。

s*32008-03-25 07:03

4 楼

嗯看过菜单口水直流啊
纽约就是爽啊有戏看有饭吃

【在 w*****n 的大作中提到】

: 还刚说着赏秋，居然下雪了。
: 才看到这新闻，联合国于10月20日至31日在纽约举办中国美食节，无奈只是工作日，
: 周末没有。。。
: http://www.mitbbs.com/article/NewYork/31208503_3.html

l*g2008-03-25 07:03

5 楼

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

r*e2008-03-25 07:03

6 楼

串联一节电池

【在 l****e 的大作中提到】

: 有一个信号源，可以产生某种频率的正弦信号，现在我想把这个正弦信号加一个DC
: offset让它都变成positive的，应该怎么弄？
: 谢谢。

x*k2008-03-25 07:03

7 楼

西海岸痛哭着飘过

a*n2008-03-25 07:03

8 楼

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?

z*n2008-03-25 07:03

9 楼

op-amp

【在 l****e 的大作中提到】

: 有一个信号源，可以产生某种频率的正弦信号，现在我想把这个正弦信号加一个DC
: offset让它都变成positive的，应该怎么弄？
: 谢谢。

a*n2008-03-25 07:03

10 楼

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...

c*u2008-03-25 07:03

11 楼

电池可能会有电阻，或者电容，高频是不行的，时间长了这个电阻还会变化，电压也
不可调。
用一个运放即可，

【在 r*****e 的大作中提到】

: 串联一节电池

T*i2008-03-25 07:03

12 楼

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....

r*e2008-03-25 07:03

13 楼

oh, thanks

【在 c*u 的大作中提到】

: 电池可能会有电阻，或者电容，高频是不行的，时间长了这个电阻还会变化，电压也
: 不可调。
: 用一个运放即可，

a*n2008-03-25 07:03

14 楼

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

f*02008-03-25 07:03

15 楼

using an opamp is one approach.
another is to use a tl431-based bias generator.
or an emitter follower.

b*y2008-03-25 07:03

16 楼

你要好好研究一下,瓶颈在哪里, 是在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

b*m2008-03-25 07:03

17 楼

用两个cap不就完了吗。
信号输出接一个大一点的cap，DC source接一个小cap。

【在 l****e 的大作中提到】

: 有一个信号源，可以产生某种频率的正弦信号，现在我想把这个正弦信号加一个DC
: offset让它都变成positive的，应该怎么弄？
: 谢谢。

g*g2008-03-25 07:03

18 楼

单个包很重要，就不该用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

f*02008-03-25 07:03

19 楼

a battery if very non-ideal due to its poor high frequency response.
depending on the application, a dc source with a resistor and fast capacitor
(ta or polyester capacitor) can do it.

【在 b*****m 的大作中提到】

: 用两个cap不就完了吗。
: 信号输出接一个大一点的cap，DC source接一个小cap。

p*u2008-03-25 07:03

20 楼

为了减少context switches，没办法，而且是doable的。

【在 g*****g 的大作中提到】

: 单个包很重要，就不该用udp，udp主要用在音频，视频这种
: 可以容错的应用上。

m*t2008-03-25 07:03

21 楼

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*e2008-03-25 07:03

22 楼

后面的应该比前面的快，这也是一般使用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*l2008-03-25 07:03

23 楼

所以说,"一将无能,累死千军"。数据的顺序和完整性（好象还有时间限制？）都很重要
还用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*t2008-03-25 07:03

24 楼

路子不对。。。

【在 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*h2008-03-25 07:03

25 楼

在数据发送端就应该做好数据流的pack工作，一次传输多个包，不用一个包一个包的传
输，
几微秒一个包，用tcp流的方式传输其实不比udp效率差多少。

a*n2008-03-25 07:03

26 楼

这两天发现udp接受过程中经常一段时间收不到任何数据，但是理论上market是在不停
地Broadcast的。
导致很多错误。。。。
大侠知道可能是什么原因导致的吗？谢谢

【在 x*********h 的大作中提到】

: 在数据发送端就应该做好数据流的pack工作，一次传输多个包，不用一个包一个包的传
: 输，
: 几微秒一个包，用tcp流的方式传输其实不比udp效率差多少。

a*n2008-03-25 07:03

27 楼

你可以稍微具体展开说一下吗？谢谢
。。。。。

【在 n******t 的大作中提到】

: 路子不对。。。