转自：https://blog.csdn.net/weixin_42882367/article/details/86473188
1. Application-aware IOT camera virtualization for video analytics edge computing
这篇文章的motivation挺有意思的，它讨论的场景是：一个camera会被多种应用服务共享，比如说机场摄像头，首先它要进行异常行为检测，检测到异常行为后，然后它要去识别嫌疑人，最后它还要去跟踪嫌疑人。以上三个应用同步进行，但对视频的要求不一样，如识别嫌疑人希望视频帧的分辨率更高，跟踪嫌疑人希望视频帧的帧数增加，那么此时假如对这些应用不加区分，直接将视频帧上传给三个应用共享，必然导致低效。因此，本文提出根据不同的应用对视频参数的要求，去动态调节给各个应用上传的视频帧。
实现原理其实比较简单，首先构建各个应用对视频参数的要求的模型（knowledge registry），然后在camera这一层创建各个服务的container（iot camera），最后由controller将实际camera采集的数据，根据knowledge registry分发给对应的container。
2. aggio: a coupon safe for privacy-preserving smart retail environments
这是一个智能零售的例子，它的motivation是(a).研究表明当顾客靠近商品时看到商品的优惠，顾客更容易被吸引去购买该商品；（b).目标指向性的优惠更有效地吸引客户，即比如你是这个店的老主顾，那么给你的优惠比新顾客的多一点。看似比较简单的motivation，现在实现起来有什么问题呢？(a).怎么去知道顾客靠近了什么商品呢，顾客可不希望他的行踪完全被商家获取；（b）怎么去指向性地给客户发送优惠券呢，顾客也不希望别人知道他平常都去哪买什么东西。
这篇文章的解决思路就是，顾客在手机上安装一个app，上面记录着顾客的购买记录之类的信息，不需要告诉别人，当顾客购物时，商品会向顾客手机发送各类目标用户的优惠劵，由该app采集这些优惠券，顾客只能解锁和他相匹配的优惠券。好的，上面的隐私问题解决了。
3. CAVBench: a benchmark suite for connected and autonomous vehicles
这篇文章的内容比较扎实，它讨论的是如何给网联车设计个完备的benchmark，去量化不同应用的性能，帮助开发者确定一个已有的计算平台是否CAV的场景。
车载应用分为四大类场景：1. 自动驾驶；2.实时诊断；3.车载娱乐；4.第三方应用。这篇文章选用了6个不同的应用代表这些场景：实时定位导航，物体检测，物体跟踪，电池诊断，语音识别，视频分析；覆盖三类数据种类信息：文本，图像，语音；关注两方面性能：应用自身的性能（输出每个应用模块的延迟，运行深度学习模型的延迟，辅助开发者从应用层面优化平台），系统整体的性能（不同资源分配情况下各个应用的QoS，见图2，定义了一个匹配函数，辅助开发者判别这个平台是否适合这些应用）。这些应用的特点存在三个特点：1.实时性（给实时性要求高的应用赋予更高的优先级）；2.输入数据非结构化（利用硬件加速使非结构化数据转化为结构化数据）；3.广泛应用深度学习模型（减少数据移动的数量和频率，主要是主存和GPU内存）。
首先介绍了为什么异构硬件对网联车的系统很重要
因为不同应用的指令密集性是极化的，如深度学习模型具有高密度的浮点数操作，卷积网络是主要的工作负载；机器视觉应用更依赖于数学模型，浮点数操作密度较低。下图是这篇文章的调研结果：
然后介绍了管理高网络带宽，优化缓存系统
这篇文章继续调研了这些应用对应用在内存方面的行为特征：
带宽占用：
注：最上面那根线代表带宽上限。
结论：这些应用都需要高带宽支持，带宽会成为主要瓶颈。
内存占用：
结论：除了ORB-SLAM2之外，其他的内存占用还是相对稳定的，对内存消耗较少，因此内存占用不会太限制CAV应用的性能。
缓存方面
结论：大体而言，这些应用在CAV的场景下有较好的数据、指令局部性，特点与高性能计算、并行计算领域非常相似。
最后根据benchmark量化分析这样一个平台
首先，从单个应用的角度来看延迟
结论：机器视觉的应用都性能不错，时延很小；但对涉及深度学习的应用就表现较差了，时延不可容忍，尤其在deep speech上，为啥呢，因为他们要大规模的卷积网络，输入的数据还是非结构化的，而这个系统还没有给他们提供专门的硬件加速。
再从整体来看这个系统，
结论：高QoS还少资源消耗的应用更适用于CAV系统。这应该是用来验证它的匹配函数设计的合理性。
4. cooperative-competitive task allocation in edge computing for delay-sensitive social sensing
讨论的场景是：后段用户把一个应用部署下去，后段服务器会希望把这个应用的任务尽可能地分配给边缘的设备执行，实现低延迟。
这篇文章主要是针对以下几个问题，然后提供解决方案，如何去分解调度：
competing objectives: 从应用的角度而言，它希望尽可能缩短时延，提高QoS,但是从边缘设备的角度而言，它只关心他们的开销和报酬。
incomplete information： 现在已有的边缘计算系统调度任务时假设后端负责调度的服务器能够获取边缘设备的所有信息，但是实际上通常不能获取边缘设备的所有信息，一是因为设备的隐私性，二是因为同步信息的开销比较大
constrained cooperativeness: 设备的拥有者没有红利是不会想共享资源的
task and trust constraints: 任务之间的依赖关系和对边缘设备的信赖关系
dynamic availability： 边缘设备的开销和参与执行任务的积极性是动态变化的。
整体架构如图：
5. Costless: optimizing cost of server less computing through function fusion and placement
这篇文章解决的问题是：对serverless computing而言，需要一个全新的定价方式，因为用户只需要部署个人的function，而不是虚拟机，那么用户是根据function实际运行时间付费，付费标准是由内存占用，持续时间及执行工作流的数量决定的。
个人觉得这是一个有意思的数学问题，
首先来看一下，现在AWS Lambda Pricing是怎么收费的：
它分成两部分：一部分是function本身的收费：执行次数✖️内存占有✖️运行时长✖️占有1GB内存1s的单价；另一部分是两个function之间数据传输的收费：每次运行需要传输数据的次数✖️运行次数✖️单次传输数据的费用.
然后，作者注意到以下几点：
有的时候传输的费用占了很大比重，那么能否将几个function合并成一个function，使它减少传输的费用呢，但是这样的话function收费的其他因素就要取几个function的最大值了，如1个function需要1GB，另一个需要2GB，那么最后折合来算就是2GB了，会导致function的收费有所浪费，于是要如何整合function呢？
边缘设备的资源价格便宜但是由于能力有限，所以function执行较慢，那么最好的是将一部分function放到云端，一部分放到edge端，那么就要考虑怎么放置才能使传输时间减少，又能使价格便宜？
AWS不会直接让开发者分配CPU，而是让开发者去配置memory，然后AWS会根据memory按比例去配置CPU。分配的memory会影响执行时间，memory和执行时间不是成一个完全反比的关系，即2倍的memory并不一定就让执行时间恰好缩短一半，因此如何去分配这个memory才能使价格更低呢？
怎么实现的没仔细研究，大致应该就是构建个数学模型，求解最优化问题。
---------------------
作者：刀枪不入的老月亮
来源：CSDN
原文：https://blog.csdn.net/weixin_42882367/article/details/86473188
版权声明：本文为博主原创文章，转载请附上博文链接！