我正在使用Expression Encoder SDK对我的网络摄像头进行实时录制,将其发布到支持IIS 7.5和Media Services 4的Web服务器,并使用SmoothStreamingClient进行查看.
但是,由于我的目标是实时会议解决方案,我需要大幅减少本地预览和远程播放之间的20秒延迟.
我在某些地方读过可以配置实时平滑流以获得2秒的延迟,但是,我没有找到任何教程解释如何配置这样的解决方案,包括编码,提供和消费双方.
这是我用来编码捕获的视频的代码:
// Aquires audio and video devices
EncoderDevice video = EncoderDevices.FindDevices(EncoderDeviceType.Video).Count > 0 ? EncoderDevices.FindDevices(EncoderDeviceType.Video)[0] : null;
EncoderDevice audio = EncoderDevices.FindDevices(EncoderDeviceType.Audio).Count > 0 ? EncoderDevices.FindDevices(EncoderDeviceType.Audio)[0] : null;
// Create a new device source. We use the first audio and video devices on the system
job = new LiveJob();
LiveDeviceSource deviceSource = job.AddDeviceSource(video, audio);
// sets preview window to winform panel hosted by xaml window
deviceSource.PreviewWindow = new PreviewWindow(new HandleRef(prevWindow, prevWindow.GetHandle));
// Make …Run Code Online (Sandbox Code Playgroud) 似乎所有主要的投资银行都在Unix(Linux,Solaris)中使用C++来实现低延迟/高频服务器应用.人们如何在交易高频权益时实现低延迟?任何书都教会如何实现这一目标?
我目前正在帮助某人进行反应时间实验.对于该实验,测量键盘上的反应时间.对于这个实验,重要的是要知道,由于按键和软件中的处理之间的延迟,可以引入多少错误.
以下是我使用谷歌发现的一些因素:
不幸的是,无法控制实验的低级逻辑.该实验用E-Prime编写,该软件通常用于此类实验.然而,提供E-Prime的公司还提供额外的硬件,他们为精确的反应时间做广告.因此他们似乎意识到这种效果(但不知道它有多大).
不幸的是,有必要使用标准键盘,所以我需要提供减少延迟的方法.
我尝试过一个实验,我在其中构建了一个简单的Producer/Consumer程序.它们在不同的线程中运行.生产者生成一些数据,消费者在另一个线程中获取数据.我实现的消息传递延迟大约为100纳秒.任何人都可以告诉我这是否合理,或者是否有明显更快的实施?
我没有使用锁...只是简单的内存计数器.我的实验在这里描述:
http://tradexoft.wordpress.com/2012/10/22/how-to-move-data-between-threads-in-100-nanoseconds/
消费者基本上等待计数器递增,然后它调用处理函数.所以代码真的不多.我还是惊讶于花了100ns.
消费者看起来像这样:
void operator()()
{
while (true)
{
while (w_cnt==r_cnt) {};
auto rc=process_data(data);
r_cnt++;
if (!rc)
break;
}
}
Run Code Online (Sandbox Code Playgroud)
当生成器有数据时,生产者只需增加w_cnt.
有更快的方法吗?
我有一台通过串行通信(即物理或仿真串行端口的RS-232 / RS-422)与外部设备连接的计算机。它们通过频繁的数据交换(30Hz)相互通信,但是只有很小的数据包(每个数据包少于16个字节)。
通信的最关键要求是低延迟或发送和接收之间的延迟。
数据交换模式类似于握手。一个主机设备启动通信,并继续在客户端设备上发送通知。客户端设备需要尽快回复来自主机设备的每个通知(这正是需要实现低延迟的地方)。通知和回复的数据包定义明确;即数据长度是已知的。并且基本上不允许数据丢失。
我使用以下常见的Win API函数以同步方式进行I / O读/写:CreateFile,ReadFile,WriteFile
客户端设备使用ReadFile从主机设备读取数据。客户端读取完长度已知的完整数据包后,便使用WriteFile用相应的数据包答复主机设备。读取和写入始终是连续的,没有并发性。
通讯速度不够快。即数据发送和接收之间的时间间隔太长。我想这可能是串行端口缓冲或中断的问题。
在这里,我总结了一些可以改善延迟的可能措施。请给我一些建议和更正:)
提前致谢!
我是Java NIO的新手并且已经使用了一点.我有一个通用的查询.如果您正在设计一个超低延迟应用程序与高吞吐量应用程序,那么这两个应用程序中的哪一个明显受益于使用非阻塞IO?
我的理解是非阻塞IO当然应该有助于高吞吐量,因为工作线程没有阻塞,因此不等待响应,并且可以自由地发送新请求,直到之前的请求被提供.一旦我们获得先前激活的请求的响应,工作线程就可以异步处理它们,从而提高吞吐量.
但是,我无法看到非阻塞IO如何直接使低延迟应用程序受益.
我猜"异步行为是避免争用的好方法." 如果是这种情况,低争用意味着低延迟.因此,NIO可能有助于降低延迟.是否有意义?
我正在做一些金融交易工作.我有一组股票符号,但是他们有很明显的模式:它是两个字符AB,AC AD而当月这是一个四位数字:1503,1504,1505.一些例子是:
AB1504
AB1505
AC1504
AC1505
AD1504
AD1505
....
Run Code Online (Sandbox Code Playgroud)
由于这些字符串设计得很好,我希望将每个字符串映射(散列)为一个唯一的整数,这样我就可以使用整数作为数组索引来快速访问,因为我的系统中有很多检索和std::unordered_map或任何其他哈希映射不够快.我有测试显示一般哈希映射是100纳秒的延迟级别,而数组索引总是低于100纳米.我的理想情况是,例如,AB1504映射到整数1,AB1505
映射到2....,然后我可以在里面创建一个数组,以更快地访问与这些符号相关的信息.我试图弄清楚一些哈希算法或其他方法可以实现我的目标,但无法找到.你们对这个问题有什么建议吗?
所以我是 ZeroMQ 的新手,我正在尝试使用 ZeroMQ 发送字节消息PUB / SUB设置使用 ZeroMQ 发送字节消息。
编程语言的选择对于这个问题并不重要,因为我使用 ZeroMQ 进行多种语言之间的通信。
这是我的服务器代码:
import zmq
import time
port = "5556"
context = zmq.Context()
socket = context.socket(zmq.PUB)
socket.bind("tcp://*:%s" % port)
while True:
socket.send(b'\x84\xa5Title\xa2hi\xa1y\xcb\x00\x00\x00\x00\x00\x00\x00\x00\xa1x\xcb@\x1c\x00\x00\x00\x00\x00\x00\xa4Data\x08')
time.sleep(1)
Run Code Online (Sandbox Code Playgroud)
这是我的 python 客户端代码:
import zmq
context = zmq.Context()
socket = context.socket(zmq.SUB)
socket.connect("tcp://localhost:5556")
total_value = 0
for update_nbr in range (5):
string = socket.recv()
print (string)
Run Code Online (Sandbox Code Playgroud)
我的客户只是阻止string = socket.recv()。
我已经做了一些研究,所以显然,如果我要使用PUB / SUB设置发送字符串,我需要设置一些“主题过滤器”才能使其工作。但如果我要发送一些字节消息,我不确定该怎么做。
我正在尝试实现一个 asp.net 2.2 应用程序,以尽可能低的延迟来处理 HTTP 请求(不是吞吐量,它不是用于生产,而是用于某种竞争)。该应用程序应该在具有 4 个内核的 Linux docker 容器环境中运行,并且我的处理程序在每个 0.2..3 毫秒时受到 CPU 限制。连接是预先创建的并保持活动状态,但我目前为空处理程序获得大约 0.6..0.8 毫秒的处理时间(回复 200 OK),有明显的抖动,偶尔会出现 20-50 毫秒的峰值,我不能解释。
是否有任何特定的 Kestrel/Sockets/Threads/CLR 设置可以帮助最小化每个请求的响应时间?或者,如果我想将其降低到 0.1..0.2 毫秒,使用 EPOLL 的 C/C++ 路线是我唯一的选择?
low-latency ×10
c++ ×3
c ×2
hardware ×2
.net-core ×1
c# ×1
hash ×1
iis ×1
java ×1
kestrel ×1
keyboard ×1
linux ×1
nio ×1
nonblocking ×1
pyzmq ×1
serial-port ×1
smooth ×1
streaming ×1
throughput ×1
trading ×1
usb ×1
visual-c++ ×1
winapi ×1
windows ×1
zeromq ×1