当前位置:首页 > ce
  • Slice 是如何实现1 1

    ic.com/weixin/tr/2021-09/23/971dbuiz942.gif"> 文中涉及的缩略语: BGP(Border Gateway Protocol,边界网关协议)CSPF(Constrained Shortest Path First,基于约束的最短路径优先)DB(Database,数据库)Flex-Algo(Flexible Algorithm,灵活算法)IGP(Interior Gateway Protocol,内部网关协议)LS(Link State,链路状态)PCE(Path Computation Element,路径计算单元)SLA(Service Level Agreement,服务等级协议)SR(Segment Routing,分段路由)TE(Traffic Engineering,流量工程) 5G系列文章回顾 1. 5G,看得见的未来 (总述) 2. 5G无线关键技术总览 3. 5G核心网关键技术总览 4. 5G承载关键技术总览 无线专题 1. 大规模MIMO自述 2. 5G RAN:您的配送服务已升级 3. 5G时代,多址技术何去何从? 4. D2D,让通信的方式简单点 5. MUSA,5G物联网为什么需要你? 6. 是兄弟一起上,5G UDN不负众望 7.上行要想快,还需FAST带 8.5G RAN节能 9.5G时代,你还在手工调天线吗? 10.SSB 1 X:不管你站得多高,都让你的手机信号满满! 11.深度解密5G多接入边缘计算 12.据说只有千分之一的人知道5G玲珑基站 核心网专题 1. 5G切片,切的究竟是什么? 2. SBA,你对5G核心网做了什么? 3. 5G核心网,这次你是真的变了吗? 4. 移动边缘计算,站在5G“中央”? 5. 朋友一生一起走,计算存储要分手 6. 聆听5G的声音! 7. MANO,你凭什么编排我的人生? 8. 云“养”核心网,NFV你准备好了吗? 9. 您的新朋友OpenStack正飞奔而来,请做好准备 10. 当信令网遇上5G 11.5G时代,短信演进之路 12.先理解智能,再谈硬件加速 13.融合计费,为何成为5G新宠? 14.服务化的5GC,由谁来控制? 15.5G分流,为了更好的遇见 16.靠近核心的LMF,让你的定位服务更好用 承载网专题 1. ROADM为承载网带来了什么? 2. 5G时代,是谁撼动了MPLS的江湖地位? 3. 5G是如何传输数据的? 4. 什么是SDON软件定义光网络? 5. 5G时代,是谁为数据中心带来了新的活力? 6. 5G承载网,你的路修好了吗? 7. 是谁让5G光传送网(OTN)变得更灵活及强大? 8. 5G时代,以太网家庭幸福的秘诀是什么? 9. 你以为的北京时间,是真的北京时间吗? 10.堆叠,你能为5G做些什么? 11.No PULL, Just PUSH! 12. 数据中心也要迎战5G了? 13. 原来你是这样的5G电信云! 14.5G电信云数据中心的逻辑组网 15.“云诊断、云课堂、云旅游...”背后的力量 16.5G承载网,你的稳定我来守护 17.5G时代,PON出“新花样” 18.怎样的必杀技让5G网管脱颖而出? 19.5G网络归我管,不服来战! 20.是谁,助力5G时代的品质专线 5G知识抢先看 欢迎继续关注后续精彩 同时真诚欢迎您留言对5G技术的需求我们将竭诚为您服务

    时间:2021-09-23 关键词: ic ce

  • 小知识 | 嵌入式C中#pragma once的作用是什么?

    关注「嵌入式大杂烩」,选择「星标公众号」一起进步!大家好,我是ZhengN。本次给大家分享一个C/C 的小知识——#pragma once。我之前也没用过#pragma once,直到看到同事的代码有用到,所以去了解了一下。分享一篇博文:❝https://blog.csdn.net/fanyun_01/article/details/77413992❞1、#pragma once有什么作用?为了避免同一个头文件被包含(include)多次,C/C 中有两种宏实现方式:一种是#ifndef方式;另一种是#pragma once方式。在能够支持这两种方式的编译器上,二者并没有太大的区别。但两者仍然有一些细微的区别。2、两者的使用方式有何区别?示例代码如下://方式一:#ifndef  __SOMEFILE_H__#define   __SOMEFILE_H__ ... ... // 声明、定义语句#endif//方式二:#pragmaonce ... ... // 声明、定义语句3、两者各有何特点?(1)#ifndef#ifndef的方式受C/C 语言标准支持。它不仅可以保证同一个文件不会被包含多次,也能保证内容完全相同的两个文件(或者代码片段)不会被不小心同时包含。当然,缺点就是如果不同头文件中的宏名不小心“撞车”,可能就会导致你看到头文件明明存在,但编译器却硬说找不到声明的状况——这种情况有时非常让人郁闷。由于编译器每次都需要打开头文件才能判定是否有重复定义,因此在编译大型项目时,ifndef会使得编译时间相对较长,因此一些编译器逐渐开始支持#pragma once的方式。(2)#pragma once#pragma once 一般由编译器提供保证:同一个文件不会被包含多次。注意这里所说的“同一个文件”是指物理上的一个文件,而不是指内容相同的两个文件。你无法对一个头文件中的一段代码作pragma once声明,而只能针对文件。其好处是,你不必再担心宏名冲突了,当然也就不会出现宏名冲突引发的奇怪问题。大型项目的编译速度也因此提高了一些。对应的缺点就是如果某个头文件有多份拷贝,本方法不能保证他们不被重复包含。当然,相比宏名冲突引发的“找不到声明”的问题,这种重复包含很容易被发现并修正。另外,这种方式不支持跨平台!4、两者之间有什么联系?#pragma once 方式产生于#ifndef之后,因此很多人可能甚至没有听说过。目前看来#ifndef更受到推崇。因为#ifndef受C/C 语言标准的支持,不受编译器的任何限制;而#pragma once方式却不受一些较老版本的编译器支持,一些支持了的编译器又打算去掉它,所以它的兼容性可能不够好。一般而言,当程序员听到这样的话,都会选择#ifndef方式,为了努力使得自己的代码“存活”时间更久,通常宁愿降低一些编译性能,这是程序员的个性,当然这是题外话啦。还看到一种用法是把两者放在一起的:#pragma once#ifndef __SOMEFILE_H__#define __SOMEFILE_H__... ... // 声明、定义语句#endif总结:看起来似乎是想兼有两者的优点。不过只要使用了#ifndef就会有宏名冲突的危险,也无法避免不支持#pragma once的编译器报错,所以混用两种方法似乎不能带来更多的好处,倒是会让一些不熟悉的人感到困惑。选择哪种方式,应该在了解两种方式的情况下,视具体情况而定。只要有一个合理的约定来避开缺点,我认为哪种方式都是可以接受的。而这个已经不是标准或者编译器的责任了,应当由程序员自己或者小范围内的开发规范来搞定。为了避免同一个文件被include多次:1、#ifndef方式 2、#pragma once方式在能够支持这两种方式的编译器上,二者并没有太大的区别,但是两者仍然还是有一些细微的区别。方式一:#ifndef __SOMEFILE_H__#define __SOMEFILE_H__... ... // 一些声明语句#endif方式二:#pragma once... ... // 一些声明语句#ifndef的方式依赖于宏名字不能冲突,这不光可以保证同一个文件不会被包含多次,也能保证内容完全相同的两个文件不会被不小心同时包含。当然,缺点就是如果不同头文件的宏名不小心“撞车”,可能就会导致头文件明明存在,编译器却硬说找不到声明的状况。#pragma once则由编译器提供保证:同一个文件不会被包含多次。注意这里所说的“同一个文件”是指物理上的一个文件,而不是指内容相同的两个文件。带来的好处是,你不必再费劲想个宏名了,当然也就不会出现宏名碰撞引发的奇怪问题。对应的缺点就是如果某个头文件有多份拷贝,本方法不能保证他们不被重复包含。当然,相比宏名碰撞引发的“找不到声明”的问题,重复包含更容易被发现并修正。方式一由语言支持所以移植性好,方式二 可以避免名字冲突。本文来源网络,版权归原作者所有。如涉及作品版权问题,请联系我进行删除。往期干货:往期推荐嵌入式项目生成器,了解一下!一个清晰的LCD驱动编写思路(附代码分析)RT-Thread和Freertos的区别?程序如何运行?编译、链接、装入?

    时间:2021-09-17 关键词: ce

  • 吸引住妹子的trace_event技术

    一天,有人报上了一个问题,发现一台服务器上空闲内存不足,slab占用了40多G,想知道什么原因,然后拉我进入在线会议远程看看。 我进入会议常规检测一番,于是想看看哪个slab占用内存比较多,直接上小脚本: while sleep 1; do cat /proc/slabinfo | awk '{name=$1; size=$2*$4/4096; \printf "%s %lu\n", name, size;}' | sort -n -r -k 2 | head -n 20; \ echo "--------------";done; 结果显示类似如下: TCPv6 9347580  (单位:4K, 大约36G) inode_cache 3519 ext3_inode_cache 3427 dentry 2285 kmem_cache 1389 sysfs_dir_cache 832 buffer_head 682 radix_tree_node 675 vm_area_struct 505 size-2048 500 task_struct 496 size-1024 464 ... 可以看到TCPv6占用了36G左右, 然后会议上有个负责业务应用的妹子问,能知道是哪个进程占用的吗? 我装着不忙地喝了一口百岁山,于是派上trace_event出场:(以下操作过程中全场安静,都盯着我的键盘输出) 首先通过/proc/slabinfo 查看到TCPv6 object size=1856,然后: cd /sys/kernel/debug/tracing/echo 'bytes_alloc==1856' >events/kmem/kmem_cache_alloc/filterecho 1 > ./options/stacktracecat ./trace 从./trace中打印出的堆栈信息和进程号,确认是他们的业务进程xxx正在干什么事(已排除内存泄漏) 这时候妹子抢占了会上所有人的讲话,笑着说:"能把history打印出来吗?",连续提醒了我三次,说想学习一下。<真是一个好学的童鞋 :-)> 这个时候本想顺道宣传一下我在阅码场发布的tracers视频课程,视频课程里面各个traces都有很详细的讲解和案例. 但是工作时间要体现一定的专业和严肃性,并没有宣传,如果她有机会能看到这篇公众号之后再去订阅会更好:-) 最后我又喝下一口百岁山, 敲下history | tail -20 之后独自退出了会议... ---end---

    时间:2021-09-16 关键词: ev ce

  • Linux系统噪音统计(osnoise tracer)

    在Linux系统中作为一个普通线程是非常苦逼的。不仅NMI 、硬中断、软中断可以打断它,甚至其它普通线程也可以来打断干扰到它的运行。 如果没有这些打断事件,一个普通线程执行while循环,可以high过天际。这些打断事件对一个普通线程来说,就相当于噪音一样的存在。 从Linux 5.14-rc1开始引入了一个新的tracer---(osnoise tracer)。就是从一个线程thread的角度把这些噪音全部详细统计出来。 上图中 在1秒内普通线程(pid=98) 受到的各个干扰事件的次数和cpu available百分比等都可以显示出来。 统计到这个程度,感觉还是不够详细。 可以打开osnoise对应的trace event. 上面的interference 5说明在一个采样周期内被打断了5次(包括4次中断和一次a.out线程事件产生的噪音),上面的每一次打断都有事件名称和对应的时间统计: 1232 1222 1192 1262 3994882=4000242-452 (~4000242) 统计时间约等于4000242ns 因为包含了检查代码的时间时间。 代码实现: 在以上每个打断事件处理函数中都插上trace event的钩子函数 来统计事件的执行时间,然后在每个cpu上运行一个内核线程进行周期性统计. 这个强大的osnoise tracer使用到的技术仅仅是用到了tracer event提供的基础设施。 我在阅码场发布过一个视频课程,对linux系统中各个tracer的使用和代码实现都有非常详细的讲解: ---end---

    时间:2021-09-14 关键词: os 噪音 ce

  • 小知识 | 嵌入式C中#pragma once的作用是什么?

    关注「嵌入式大杂烩」,选择「星标公众号」一起进步!大家好,我是ZhengN。本次给大家分享一个C/C 的小知识——#pragma once。我之前也没用过#pragma once,直到看到同事的代码有用到,所以去了解了一下。分享一篇博文:❝https://blog.csdn.net/fanyun_01/article/details/77413992❞1、#pragma once有什么作用?为了避免同一个头文件被包含(include)多次,C/C 中有两种宏实现方式:一种是#ifndef方式;另一种是#pragma once方式。在能够支持这两种方式的编译器上,二者并没有太大的区别。但两者仍然有一些细微的区别。2、两者的使用方式有何区别?示例代码如下://方式一:#ifndef  __SOMEFILE_H__#define   __SOMEFILE_H__ ... ... // 声明、定义语句#endif//方式二:#pragmaonce ... ... // 声明、定义语句3、两者各有何特点?(1)#ifndef#ifndef的方式受C/C 语言标准支持。它不仅可以保证同一个文件不会被包含多次,也能保证内容完全相同的两个文件(或者代码片段)不会被不小心同时包含。当然,缺点就是如果不同头文件中的宏名不小心“撞车”,可能就会导致你看到头文件明明存在,但编译器却硬说找不到声明的状况——这种情况有时非常让人郁闷。由于编译器每次都需要打开头文件才能判定是否有重复定义,因此在编译大型项目时,ifndef会使得编译时间相对较长,因此一些编译器逐渐开始支持#pragma once的方式。(2)#pragma once#pragma once 一般由编译器提供保证:同一个文件不会被包含多次。注意这里所说的“同一个文件”是指物理上的一个文件,而不是指内容相同的两个文件。你无法对一个头文件中的一段代码作pragma once声明,而只能针对文件。其好处是,你不必再担心宏名冲突了,当然也就不会出现宏名冲突引发的奇怪问题。大型项目的编译速度也因此提高了一些。对应的缺点就是如果某个头文件有多份拷贝,本方法不能保证他们不被重复包含。当然,相比宏名冲突引发的“找不到声明”的问题,这种重复包含很容易被发现并修正。另外,这种方式不支持跨平台!4、两者之间有什么联系?#pragma once 方式产生于#ifndef之后,因此很多人可能甚至没有听说过。目前看来#ifndef更受到推崇。因为#ifndef受C/C 语言标准的支持,不受编译器的任何限制;而#pragma once方式却不受一些较老版本的编译器支持,一些支持了的编译器又打算去掉它,所以它的兼容性可能不够好。一般而言,当程序员听到这样的话,都会选择#ifndef方式,为了努力使得自己的代码“存活”时间更久,通常宁愿降低一些编译性能,这是程序员的个性,当然这是题外话啦。还看到一种用法是把两者放在一起的:#pragma once#ifndef __SOMEFILE_H__#define __SOMEFILE_H__... ... // 声明、定义语句#endif总结:看起来似乎是想兼有两者的优点。不过只要使用了#ifndef就会有宏名冲突的危险,也无法避免不支持#pragma once的编译器报错,所以混用两种方法似乎不能带来更多的好处,倒是会让一些不熟悉的人感到困惑。选择哪种方式,应该在了解两种方式的情况下,视具体情况而定。只要有一个合理的约定来避开缺点,我认为哪种方式都是可以接受的。而这个已经不是标准或者编译器的责任了,应当由程序员自己或者小范围内的开发规范来搞定。为了避免同一个文件被include多次:1、#ifndef方式 2、#pragma once方式在能够支持这两种方式的编译器上,二者并没有太大的区别,但是两者仍然还是有一些细微的区别。方式一:#ifndef __SOMEFILE_H__#define __SOMEFILE_H__... ... // 一些声明语句#endif方式二:#pragma once... ... // 一些声明语句#ifndef的方式依赖于宏名字不能冲突,这不光可以保证同一个文件不会被包含多次,也能保证内容完全相同的两个文件不会被不小心同时包含。当然,缺点就是如果不同头文件的宏名不小心“撞车”,可能就会导致头文件明明存在,编译器却硬说找不到声明的状况。#pragma once则由编译器提供保证:同一个文件不会被包含多次。注意这里所说的“同一个文件”是指物理上的一个文件,而不是指内容相同的两个文件。带来的好处是,你不必再费劲想个宏名了,当然也就不会出现宏名碰撞引发的奇怪问题。对应的缺点就是如果某个头文件有多份拷贝,本方法不能保证他们不被重复包含。当然,相比宏名碰撞引发的“找不到声明”的问题,重复包含更容易被发现并修正。方式一由语言支持所以移植性好,方式二 可以避免名字冲突。本文来源网络,版权归原作者所有。如涉及作品版权问题,请联系我进行删除。往期干货:往期推荐嵌入式项目生成器,了解一下!一个清晰的LCD驱动编写思路(附代码分析)RT-Thread和Freertos的区别?程序如何运行?编译、链接、装入?

    时间:2021-09-06 关键词: ce

  • Linux内核网络UDP数据包发送(四)——Linux netdevice 子系统

    Linux内核网络UDP数据包发送系列:Linux内核网络UDP数据包发送(一)Linux内核网络UDP数据包发送(二)——UDP协议层分析Linux内核网络UDP数据包发送(三)——IP协议层分析1. 前言在继续分析 dev_queue_xmit 发送数据包之前,我们需要了解以下重要概念。Linux 支持流量控制(traffic control)的功能,此功能允许系统管理员控制数据包如何从机器发送出去。流量控制系统包含几组不同的 queue system,每种有不同的排队特征。各个排队系统通常称为 qdisc,也称为排队规则。可以将 qdisc 视为调度程序, qdisc 决定数据包的发送时间和方式。Linux 上每个 device 都有一个与之关联的默认 qdisc。对于仅支持单发送队列的网卡,使用默认的 qdisc pfifo_fast。支持多个发送队列的网卡使用 mq 的默认 qdisc。可以运行 tc qdisc 来查看系统 qdisc 信息。某些设备支持硬件流量控制,这允许管理员将流量控制 offload 到网络硬件,节省系统的 CPU 资源。现在我们从 net/core/dev.c 继续分析 dev_queue_xmit。2. dev_queue_xmit and __dev_queue_xmitdev_queue_xmit 简单封装了__dev_queue_xmit:int dev_queue_xmit(struct sk_buff *skb){ return __dev_queue_xmit(skb, NULL);}EXPORT_SYMBOL(dev_queue_xmit);__dev_queue_xmit 才是干脏活累活的地方,我们一点一点来看:static int __dev_queue_xmit(struct sk_buff *skb, void *accel_priv){ struct net_device *dev = skb->dev; struct netdev_queue *txq; struct Qdisc *q; int rc = -ENOMEM; skb_reset_mac_header(skb); /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); skb_update_prio(skb);开始的逻辑:声明变量调用 skb_reset_mac_header,准备发送 skb。这会重置 skb 内部的指针,使得 ether 头可以被访问调用 rcu_read_lock_bh,为接下来的读操作加锁调用 skb_update_prio,如果启用了网络优先级 cgroups,这会设置 skb 的优先级现在,我们来看更复杂的部分: txq = netdev_pick_tx(dev, skb, accel_priv);这会选择发送队列。2.1 netdev_pick_txnetdev_pick_tx 定义在net/core/flow_dissector.cstruct netdev_queue *netdev_pick_tx(struct net_device *dev, struct sk_buff *skb, void *accel_priv){ int queue_index = 0; if (dev->real_num_tx_queues != 1) { const struct net_device_ops *ops = dev->netdev_ops; if (ops->ndo_select_queue) queue_index = ops->ndo_select_queue(dev, skb, accel_priv); else queue_index = __netdev_pick_tx(dev, skb); if (!accel_priv) queue_index = dev_cap_txqueue(dev, queue_index); } skb_set_queue_mapping(skb, queue_index); return netdev_get_tx_queue(dev, queue_index);}如上所示,如果网络设备仅支持单个 TX 队列,则会跳过复杂的代码,直接返回单个 TX 队列。大多高端服务器上使用的设备都有多个 TX 队列。具有多个 TX 队列的设备有两种情况:驱动程序实现 ndo_select_queue,以硬件或 feature-specific 的方式更智能地选择 TX 队列驱动程序没有实现 ndo_select_queue,这种情况需要内核自己选择设备从 3.13 内核开始,没有多少驱动程序实现 ndo_select_queue。bnx2x 和 ixgbe 驱动程序实现了此功能,但仅用于以太网光纤通道FCoE。鉴于此,我们假设网络设备没有实现 ndo_select_queue 和没有使用 FCoE。在这种情况下,内核将使用__netdev_pick_tx 选择 tx 队列。一旦__netdev_pick_tx 确定了队列号,skb_set_queue_mapping 将缓存该值(稍后将在流量控制代码中使用),netdev_get_tx_queue 将查找并返回指向该队列的指针。让我们 看一下__netdev_pick_tx 在返回__dev_queue_xmit 之前的工作原理。2.2 __netdev_pick_tx我们来看内核如何选择 TX 队列。net/core/flow_dissector.c:u16 __netdev_pick_tx(struct net_device *dev, struct sk_buff *skb){ struct sock *sk = skb->sk; int queue_index = sk_tx_queue_get(sk); if (queue_index ooo_okay || queue_index >= dev->real_num_tx_queues) { int new_index = get_xps_queue(dev, skb); if (new_index

    时间:2021-09-03 关键词: ev ic ce

  • 硬件工程师前途到底怎样?看看大佬怎么说

    一位项目经理带着一名硬件工程师和一名软件工程师一同坐车去参加研讨会,结果汽车在半路抛锚,于是三人就“如何修理汽车”展开了激烈的讨论。 硬件工程师说:“我可以用随身携带的瑞士军刀把车坏的部分拆下来,找出原因,排除故障。” 项目经理托着腮帮子邪魅一笑:“根据经营管理学,应该召开会议,根据问题现状写出需求报告,制订计划,编写日程安排,逐步逼近,alpha测试,beta1测试和beta2测试解决问题。” 这时,软件工程师不慌不忙地说出了一句让硬件工程师和项目经理都喷饭的话:“咱们还是应该把车推回山顶再开下来,看看问题是否重复发生...” en...段子归段子,但基于不同的职业习惯,我们大概可以从中看出硬件工程师、项目经理以及软件工程师这三者在工作上分别扮演着什么样的角色,也就是所谓的职能分工。 不过扎心的是,跟软件工程师比起来,硬件工程师的前景似乎不怎么被人看好。网上总是不乏“硬件不如软件吃香”、“硬件干活多、待遇低、门槛高”、“十年硬件转IT,真香!”...等诸如此类的言论。由于硬件工程师做的事情多且杂,更是惨被戏称为“高级杂工”。 事实真是如此?搞硬件就真的这么苦逼?没有什么发展前景?看看资深硬件工程师怎么说! 先来了解一下:什么是硬件?百度百科上是这么介绍硬件的:"硬件(英文名Hardware),是计算机硬件的简称(中国大陆及香港用语,台湾作硬体),是指计算机系统中由电子,机械和光电元件等组成的各种物理装置的总称。这些物理装置按系统结构的要求构成一个有机整体为计算机软件运行提供物质基础。" 也就是说硬件是物理层面的,至少是你能看得到摸得着的东西,它是一种物质载体,物质基础。广义来说人类都是生活在物质基础之上,你可以把所有你能看到的东西都统称为硬件。当然狭义来说,一般我们所说的软件和硬件指的是电子领域的。 软件代码也是人编写的,我们所熟知的语言比如C、C 等都是通过编译器翻译成汇编语言,然后汇编语言通过汇编器翻译成二进制机器语言,机器语言操控门电路完成相应的动作。个人觉得,没有硬件,软件就没有存在的意义,硬件是一切的基础,这里可以看出硬件设计是多重要。 但软件和硬件又有明显的区分,至少工作内容区别很大。按照行业内描述硬件属于底层(一般称为底层硬件),软件称为上层(软件又分为:底层驱动、上层业务以及应用层等)。如果非要举个例子来说明软件和硬件,那最好的例子就是人,硬件指人的躯体,而软件指人的思维。 当然,对于非电子领域的人来说,很难想明白计算机是怎么工作的,硬件是怎样工作的,软件是怎样工作的,即使你知道都是0和1,但你没做过相关工作,你发现不了其中的神奇之处。 其实你只要知道,软件驱动硬件工作,驱动的激励是什么?是电讯号!硬件接收到的这个电讯号分为0和1,硬件的响应速度非常快,多快呢?举个例子,硬件中常用的串口波特率115200bit per second,一秒钟115200个0或者1,英语字母是8个bit(可在ASCII表看到,这在大学都学过),那就是一秒钟可打印14400个字母。 你眨下眼睛一万多个字母就出来了。当然实际上并没有这么多,这只是个形象的例子。 但在电路设计上100kHz属于比较慢的速率了。再比如显示器一幅图的刷新频率在一秒钟24个以上,我们人眼就看不出来。24帧的数据是非常大的,比如1080p30格式输出,总的数据量是一秒钟1920*1080*12*30= 746496000个0或者1,也就是7亿个0或者1。一般来说硬件设计指的是电路设计,这样说是没问题的,因为你所有的工作都是围绕电路设计,最终的目标也是产出一个优秀的电路,能够满足各种要求,经历各种考验。但实际上我们要求的是产品,而不是单板。 硬件工程师干什么? 硬件工程师(Hardware Engineer)主要负责整个产品的硬件设计。一个优秀的硬件工程师,不仅需要从外界交流获取对自己设计的需求,然后汇总,分析成具体的硬件实现。还要跟众多的芯片和方案供应商联系,从中挑选出合适的方案。当原理图完成后,则需要组织人员进行配合评审和检查,还要和CAD工程师一起工作来完成的设计。与此同时,要准备好BOM清单,开始采购和准备物料,联系加工厂家完成贴装工序。除了基本理论知识过硬,熟练掌握硬件原理图设计技术、硬件PCB图设计、硬件调试之外,还要必备快速学习能力、通信协议和标准的理解、电路设计的能力、沟通和全局控制的能力,物料选型能力、采购能力等等,甚至上到工科理论经济形势,下到历史政治文化科技,都要懂一点。通过下面一张硬件产品研发团队的构成图,大概就能明白硬件工程师在整个研发团队中扮演着多么重要的角色了:  需要说明的是,在整个项目研发团队中,有两个人和所有人打交道,一个就是项目经理,另一个就是硬件工程师。硬件工程师需要和各种研发人员打交道 、协调工作,这也就要求硬件工程师具有丰富的知识面和强大的协调能力,所以硬件工程师在整个研发团队中做主导作用。 作为一个硬件工程师,需要负责整个产品的研发过程。所以必须对每个时间段进行精确把握。项目都会有项目周期,虽然项目经理在把控时间,但具体的操作还是硬件工程师来搞。对于正常进度的项目来说: 原理图和详细设计方案:5周,包括参考设计以及原理图评审。 PCB布板布线:4周,包括配合结构、PCB进行电路调整或者器件重新选型。 发板及等待回板:2周,这两周是最闲的,发板同时必须完成BOM上传,这个不能忘。多看自己的图! 回板检查:1周,将自己的板子跑起来,能烧录uboot,网口能ping通。检查有无焊接问题。联系结构进行机器组装,查看结构有没有问题。 驱动调试:5周,配合完成所有底层功能的调试。 媒体版本:2周,这个是驱动调试之后第一个整机跑起来的版本,准备拿给测试进行测试。 信号测试:3周,配合信号测试人员完成信号测试。同时给做业务研发人员准备板子给他们研发。 功能测试:2周,配合功能测试人员完成环境测试,防护静电浪涌测试,以及其他功能测试,EMC测试等。 解BUG等待:2周,解决上述出现的所有BUG! 改板与发板:2周。........ 当然,具体时间会随着产品的复杂程度而变化,上面只做参考,不能一概而论。关于硬件设计的描述,网上还有一种比较形象的说法:“硬件设计就是根据产品经理的需求PRS(Product Requirement Specification),在COGS(Cost of Goods Sale)的要求下,利用目前业界成熟的芯片方案或者技术,在规定时间内完成符合以下要求的硬件产品(注意:是产品不是开发板)。”具体要求如下: ● PRS功能(Function)● 性能(perrformance)● 电源设计(power Supply)● 功耗(power Consumption)● 散热(Thermal/Cooling)● 噪音(Noise)● 信号完整性(Signal Integrity),● 电磁辐射(EMC/EMI)● 安规(Safet)● 器件采购(Component Sourcing)● 可靠性(Reliability)● 可测试性(DFT: design for test)● 可生产性(DFM:design for manufacture) 可以看到,一个成功的硬件设计,主要功能的实现只是所有环节中的一小部分。刚开始工作的时候,觉得板子电路设计完就完成了50%工作,PCB回板主要功能都能实现了,那就完成了80%的工作。实际上不是的,PCB回板主要功能都实现了,连30%工作都没有。所以不管是时间上,还是阶段上,产品的硬件设计时一个漫长过程。 而且你在一个公司做产品硬件设计,一般情况下都是参考成熟的方案,主芯片CPU主要功能的实现最终还是依靠芯片厂商提供的套片方案,一般来说为了降低风险,主要是参考套片方案的参考设计完成,芯片厂商也会提供包括器件封装,参考设计,仿真模型,PCB参考等等全部资料,在芯片功能越来越复杂的今天,一个片子动不动就几百上千个PIN,对于一个新项目来说,是没有时间一页页去吃透每个PIN,每个输入输出的具体功能,电气参数的,尤其是对于高速设计,比如DDR3接口,XAUI接口等等。一般来说,芯片厂商提供的参考设计就是他们经过开发,验证,测试的最佳方案了,很多情况就是你必须按照参考设计来做,否则硬件可能就有问题,一般来说就是信号完整性问题或者EMC问题。 那有的人就说了,硬件电路设计谈不上设计,都是copy成熟电路。芯片厂商提供越来越周到的服务,再加上公司沉淀的技术积累,硬件设计工程师可以完全不动脑子进行电路设计。这样一来,硬件工程师的价值似乎越来越低了,毕竟一个产品的核心功能或者技术一般都在IC或者FPGA里面了,硬件工程师一般没有能力进行核心逻辑设计IC design。 那如果按照这个逻辑软件设计也谈不上设计,都是copy成熟代码。试问有几个软件开发人员不移植别人的代码?再深入点,有几个软件工程师能随意更改uboot、kernel,不百度C语言语法,不移植业务程序,不去问芯片厂商的技术支持? 即使都是成熟的东西,实际上工作过程中我并没有发现哪个项目做得很快,同样一套电路和代码,成熟产品没问题,新产品为什么就有问题?最后还是是硬件设计去解决。 对于这上述问题,笔者也曾经困惑过,总是感觉硬件设计没有什么好搞的了,不就是抄抄参考设计,就跟组装一台电脑一样组装一个单板嘛。当然随着项目经验的增多,尤其从事现在硬件系统级设计的角色,感觉原来自己考虑更多是从一名原理图设计工程师的角度考虑问题,看问题总是很片面。就像开始说的,一个成功的硬件设计,功能Function只是一小部分,至于其他的因素和能力,一个硬件工程师的能力取决于能考虑因素越多,越深入,就越是一个优秀的硬件工程师。 所以硬件工程师是吃经验的,对公司来说培养一个硬件工程师成本很高,硬件不会像软件一样代码错了修改一下几分钟就可以搞定,硬件设计错了,那有可能全部都要重来,整个项目周期可能就要延迟3周甚至一个月以上。 有个观点需要说明一下,啥都不懂也可以做出事情,但对个人来说会有发展天花板。硬件方面就像参考电路一样,你不知道电路怎么工作的也能把它用起来,软件方面就像uboot和kernel一样你看不懂也能用起来,但一旦你懂,那就不一样了。 就像一谈到硬件设计,大家都认为是电路设计,好简单,没什么难度,但实际上不是的,越到底层越难,责任越大,部门交流越多。懂得越多,学得越容易,就能够走得越远。 什么是硬件电路设计? 顾名思义,硬件电路设计就是设计电路的,能够熟练使用cadence绘制电路与查看PCB。硬件设计中的电路设计是硬件工程师最重要的职责。电路设计考验的是硬件工程师的设计基本功,即对一些硬件器件的理解以及灵活应用,比如:CPU、电阻/电容/电感、二极管/三极管、保护器件/接口器件、逻辑芯片/逻辑功能、电源等。 硬件电路设计主要针对电路设计,里面涉及的东西比较多,需要足够的经验与理论知识。8年硬件工程师的难言之隐韩寒执导的电影《飞驰人生》有这么一句经典对白:“中年人的崩溃,是从开口借钱开始的”。 人到中年,各方面都开始走下坡路,当你手捧着泡满枸杞的保温杯,看着镜子里日渐隆起的大肚腩和后移的发际线,再想想“孩子、车子、房子”...唉声叹气往头顶一瞅,发现竟然还悬了把“达摩克利斯之剑”,仿佛它随时都能掉下来将你劈成两半。年轻人的痛,气宇轩昂,中年人的痛,无声无息!陈航(化名),年龄30 ,拥有8年硬件开发经验,目前就职于深圳某医疗器械公司,呆了五年还在底层挣扎。 工作上,他自认为从不马虎,技术也过硬,但一直得不到晋升的机会。眼看着一个个初出茅庐的“小萌新”开始拿着跟自己差不多的薪水,有些甚至已晋升为管理层。 他觉得很迷茫,想跳槽,投了许多简历,但没有任何收到音讯!现在看来,“另择良木”这条路对他来说,似乎很难走通。多年的技术生涯,让陈航身上带有部分工程师的“通病”,尤其体现在性格上面,天真(此处带有贬意)、敏感、胆怯、多虑、木讷,不善言辞,也不善交际,而在思维方面,又明显过于教条化。另一方面,对于长年奋斗在底层的陈航来说,严重缺乏管理思维模式。所以,即便技术过硬,但缺乏项目管理能力,加上性格过于敏感,一直难有晋升机会。而另一位毕业8年,转了三家公司的硬件工程师也表示,虽然自己拥有8年的工作经验,但是由于工作太杂,杂而不精,所以在面试的时候总会被人挑刺,导致工资很难往上提,更别说晋升管理层了。作为一名硬件狗,你不应该坐以待毙,要勇于打破职业瓶颈,“高薪”、“管理”两手抓起来!都说硬件工程师的薪资取决于能力,一般情况下,硬件工程师都是要历练很多年才能达到一个比较高水平的,所以不要好高骛远,脚踏实地,厚积薄发才是王道。根据近6年内的相关调查数据显示,来自全国的企业电子工程师岗位要求中,对项目管理能力的要求超过50%。由此可见,项目管理已成为初中级工程师必备能力。我们再来看看硬件工程师的职业进阶线路图:从上图我们可以看出,走“技术路线”的硬件工程师,无论是薪资待遇还是未来的发展潜力,都远不如走“管理路线”的大佬们。干硬件,即使混到专家级,薪资也就20K-30K的水平。而若晋升为管理层,那么终极目标就是创业,在赚钱方面拥有无限可能。要想拥抱“高薪”、进入“管理层”,你需要掌握的核心技能大体如下:1.主导公司产品电路设计开发,样品制作;2.分析客户体验,领导企业产品升级;3.决定企业硬件产品核心差距;4.产品功能、性能决策;5.掌握产品成本核心;6.带领团队完成硬件功能性和性能要求的逻辑设计等....都说干硬件这行,入门容易,精深太难!搞硬件,一方面需要“深”,一方面需要“博”。现代电子电路知识是个大坑,其深如海。一辈子钻研,如果能在一个小点上精通,就算大能了。坑爹的是,当个硬件工程师不能光懂硬件,代码要会写,结构要了解,按照行业不同,你可能还需要懂得:控制理论,光,机,热,气,生物,化学等等各个方面的知识。这也是为什么很多干硬件的都说自己“差不多什么都会一点,但不精!“差不多十年前,硬件和软件还处于势均力敌的状态,随着IC芯片集成度越来越高,硬件工程师的身价也开始随之下跌。 现如今,做产品都是由供应商提供方案,很多原厂的公版设计需要改动的地方越来越少,并且出了任何问题也都由原厂直接跟进解决。IC集成度越高,硬件设计就越窄,对硬件工程师的要求自然也会越来越低。总的来说,硬件现在最大的瓶颈就是消费级市场一体解决方案和不断整合的芯片集成度,这种直接由原厂提供完整“钥匙”的方案,让设计风险大幅降低的同时,也削弱了硬件工程师的重要性。如前所述,硬件的辉煌是在2000年以前,那时硬件还没有饱和,正处在上升期,随着硬件的性能提升,软件利用硬件资源玩出了花,硬件的时代也随之暗沉,现在上游半导体基本已经出现垄断化,没有无序竞争,标准化从薪资到制度都在逐步限死。搞硬件真的就没有什么发展前景?搞软件是能挣几年钱,但硬件可以吃一辈子。 硬件工程师可以养老,基本上不存在中年危机。与软件行业不同,硬件工程师的薪资跟经验直接挂钩,很少出现应届生与在职工程师薪资倒挂的现象。按照艰苦奋斗再创业的节奏,终身就业是大趋势,硬件工程师是一份可以实现终身就业的工作。而软件行业变化速度快,软件工程师可替代性强,coder能干到架构师高级算法工程师的人凤毛麟角,能够中年成功转管理岗的也不多。而且新员工比老员工薪资高也已经是普遍现象,大龄coder面临的竞争压力比同龄硬件工程师大不少。 此外,如果硬件实在搞不下去了,还可以转项目经理啥的。大多数硬件工程师一般到后期都会转管理,或自己创业。跟软件相比,接触面会比较宽,更容易从全盘去考虑问题。 总之,一个顶级硬件工程师可遇不可求,而一个顶级的软件工程师一抓一大把。拿苹果公司来说,他们顶级硬件工程师的工资要比同级别的软件工程师薪资高。 当然,术业有专攻,不能简单用谁好谁坏来定论,无论是硬件还是软件,修炼内功才是王道。 行业的大佬如何看待硬件工程师前程问题?硬件工程师是这样一种奇特的工作:在中国大多数从事这个行业的人都没有入门。那些宣称由于上游芯片厂家的DEMO越来越成熟,导致硬件工程师成为了“裱糊匠”,到处抄参考设计的,他们自己确实就是这样,也确实没有见识过什么是真正资深的硬件工程师。互联网的高价吸引了许多优秀人才,使得硬件行业的总体人才水平偏低,更加重了第一条的现状。其实我也挺看好机械行业的,越是被互联网抽走了人才的洼地,越是存在巨大的需求。你不能问那些被迫干机械或硬件的人,他们资质平庸,转行做软件也怕学不会算法,他们一定告诉你硬件不行,坑深得很,XXX做软件水平差还薪资50K/月起......硬件专家的资质要求很高,没有上上之资、又有一定的毅力苦功,有高手在起步时带一下,几乎不可能有什么成就。如果说学软件对数学逻辑功底要求高的话,学硬件还得加上物理、以及特定行业相关的工程应用知识。用卡尔曼滤波实现干扰状态下的传感器数据采集,以便进行过程控制的系统中,究竟是采用屏蔽驱动技术的信号电缆更好呢,还是采用光电或磁电隔离更可靠?这些问题似乎都不再局限于电路信号范畴,它与成本、材料、应用可靠性、代码的兼容性都相关了。好的硬件工程师,似乎是这样一种专家:他运筹帷幄,熟知每一个技术细节,能一下子反应过来任何问题的可能来源,在成本、功能、性能与客户体验之间游刃有余。回到正题:如果你有超过一般人的天赋,做什么都挺好,不只是硬件。如果你资质一般,去做些一般人也能挣到钱的工作,比如软件。需求量大嘛,总是可以多容纳些滥竽充数的人,更何况一般人也能写得大差不差。其实对于“研发工程师”而言,能当得起这个称呼的人,是为我们设计新产品、创造新价值的人,难道不应该是人群中最聪明的top5%? 你认真诚恳地评价一下自己,就知道自己适合不适合做工程师了。我觉得硬件很有趣,在某些战略层面上,硬件设计总是需要科学家级别的人才能胜任。如果你有情怀,不妨可以试试。最后,这个问题的本意其实有问题,大多数人回答也按照心照不宣的本意在回答,挺有趣。这个问题的真正含义是“我就想和别人一样地上上班,也一样努力地工作学习,能否获得超额的回报?“来钱快肯定是有原因的,要么特别聪明、要么特别勤劳、要么狗屎运特别好。有人说大部分需求可以随便抄抄DEMO就能搞定了。我感觉“搞”是这么”搞“了,”定“则未必能“定”了。君不见那么多动不动就被干扰数据乱蹦、一上高低温就瘫痪,或者好一点精度差、响应慢、偶尔死机要重启下,这些带病产品都是哪里来的?须知DEMO的主要目的是展示“技术可行性“,它最大的问题在于没有和特定的行业应用相结合。有些为行业定制的DEMO只考虑了技术本身,没有考虑诸如振动、干扰、环境温湿度等因素。而这恰恰就是硬件工程师的最大价值:在技术可行的基础上,根据现场应用特征,优化其功能、强化其性能、在成本与性能之间找到最佳平衡,让一个技术可行的方案成为一个商业成功的产品,这才是硬件工程师的荣誉之所在。我们有些硬件工程师,可能从未想过他所谓的”研发设计“体现在哪里,到底研究了什么、开发了什么、设计了什么?还是仅仅抄袭了什么?电子工程师这个职业,国内企业的核心竞争力确实在国际竞争中没有什么优势,甚至差距还挺大,所以才会有那些“到处抄抄”也就差不多了的看法 - 你的竞争力就是“差不多”的档次,你个人也是“差不多”的水平,当然企业也好,个人也好,前途也就是“差不多”了。看一个问题评价是高是低,其实是和个人的标准有关的。你觉得这样就可以了,换个国家换个环境人家说不定觉得莫名其妙 - 就这种水平还敢自称工程师?有人一直在强调“那种资深的高水平工程师很少 - 需求也少”,可能还是有误解。我们目前的现状并非是中低级工程师多,高级资深工程师少,而是基本达到研发能力的工程师少,许多都谈不上“研发”二字。说得刻薄一点,我们的“资深”可能是人家的“基础”。我不是很能理解,一个大学学了微积分、普通物理、电路原理、信号与系统、模电数电,毕业工作几年后仍然理直气壮地说我模电不行、我数电不懂、这个小信号分析我做不了......这和资深搭得上关系吗?就算做到了就可以以“资深工程师”自居了?这不是基础工程师要求么。记得看过一次报道,一次硬件工程师的招聘,要求面试者讲讲自己做硬件的心得。结果他掏出一个上家公司的电路板,说你看吧,用了六层板呢。我接触过一些这样的工程师,情商极低,缺乏足够的诚信或道德意识,表达能力差,学习能力弱。他们喜欢挂在口头的话就是“要是有高手带我,多干几个项目,我经验就上来了”。他们情愿去现场一趟一趟的调试(所谓的调试依我看几乎是胡乱试,好了不知道为啥好,坏了也不知为啥坏,很少是按理论指导一步步来),也不愿先在脑袋里仔细分析一遍 - 也可能他们确实没能力分析。他们的经验就像是武功口诀一样,什么抗干扰要“多点接地或单点接地”啦,或者IC前面要放几个去耦电容啦,也有什么通信口加个光电隔离啦,似乎口诀越多,经验越丰富。你要问他这些口诀背后的电路原理到底是什么?为什么一定要0.1uF?在这个应用场景适合不适合,他就哑口无言了。其实做任何一行首先要端正态度,你是要做标准的事情,还是要做“不标准差不多”的事情。我一直认为中国存在巨大的机会,其原因很简单:只要你中规中矩做到工程师的基本要求,你在国内就是领先的,有着巨大优势的,因为国内的同行或企业存在太多不着调的现象了。问题是,我们把认真读书考试平均分也不过90来分的人称为“学霸",把能够将书本理论与研发实践结合起来的工程师称为“高手”(连理论与实践相结合都做不到的工程师不是坑人么?),这不仅是眼光的问题,更是人才供给侧改革的问题:大量低端人力资源过剩,高端人才供给不足。这是和我们产业现状匹配的人才现状,也是我们未来改进的必由之路:国家产业假如能够升级,绝对离不开社会人才的升级。END来源:电力电子技术与新能源版权归原作者所有,如有侵权,请联系删除。▍

    时间:2021-09-03 关键词: abi AD ce

  • Veson收购数据解决方案Oceanbolt

    商业海事软件领先企业为大宗商品和航运业务提供的创新市场数据解决方案 波士顿2021年9月1日 /美通社/ -- 全球商业海事软件市场领导者Veson Nautical自豪地宣布,对大宗商品交易流程分析和海运智能动态数据解决方案Oceanbolt实施战略收购。 Oceanbolt的数据解决方案可提供基于网络和API的高完整性、实时数据访问,包括商品贸易流量、货运吨位、实时和准确船舶位置、港口拥堵状况、港口活动和周转时间 -- 如用作战略管理滞期费的实用见解。 自2019年成立以来,挪威合资企业Oceanbolt的创新数据平台赢得了干散货船东运营商、商品交易商、供应链协调商和吨位租船人等众多客户的尊重。Oceanbolt将一流的AIS处理引擎与港口和泊位多边图的专有地理空间数据库相结合,允许在数秒内处理昂贵的计算。如今,Oceanbolt已处理300多亿数据点,每天观察超过6000万次,每年跟踪50多亿吨超过140种的商品。  Veson Nautical首席执行官John Veson表示:“Oceanbolt团队为行业提供的专业知识、营销见解和技术能力确实非常出色。 我们很高兴欢迎Oceanbolt加入Veson大家庭。我们两个组织在使命方面深切契合,致力于使海运和商品交易界能够以最大的敏捷性作出最佳决定。” Oceanbolt联合创始人Niclas Dæhli Priess表示:“我们非常高兴能与Veson Nautical合作,并相信用户将从一项显著增强的产品中受益,”Priess补充道:“将Oceanbolt专注于分析的解决方案与Veson广泛的产品套件和行业知识相结合,这显然大有裨益。通过来自Veson的共享资源,我们盼望看到Oceanbolt算法的准确性和功能进一步增强。在做出交易或商业货运决策方面,VIP用户将受益于在正确的时间获得额外的数据和更好的可见性。” Oceanbolt首席执行官兼联合创始人Mads Schou-Andreasen表示:“在日益数字化的世界中,成功部署数据驱动决策流程的能力正在成为一个关键的差异化竞争因素。  Schou-Andreasen还表示:“在行业利益相关者利益攸关的情况下,我们要提供可信、准确的数据解决方案以让我们的客户获得可供操作的见解,这一点至关重要。Oceanbolt和Veson对航运和商品行业的共同愿景将加速我们的创新,为我们的客户开辟新的方式来利用数据做出更好的业务决策。我们可以共同提供市场上最具吸引力的数据和分析解决方案。” Oceanbolt联合创始人Niclas Dæhli Priess和Mads Schou-Andreasen将加入Veson Nautical团队,分别担任产品管理总监和软件工程总监,负责Oceanbolt的产品。  Oceanbolt解决方案添加到Veson的产品套件中可强化Veson的使命,即通过深化和扩展专业知识和资源的广度,推动海事商业的标准平台发展,为双方的客户社区带来价值。  为Veson Nautical客户提供更深刻的见解随着对决策数据需求的不断增强,Oceanbolt将为Veson客户提供一个强大的动态数据智能解决方案和受益机会,可以更直接地获取关键市场的洞见和贸易流量、拥堵和全球船舶事件的分析。通过提供大量影响海洋合同所有利益相关者决策的外部变量的实时丰富数据,Oceanbolt将强化Veson客户可用数据的完整性、深度和广度,以支持我们改变客户工作和决策方式的目标。Oceanbolt的加入还将为Veson提供新的机会,以更有力地服务于商品交易商和供应链调度用户。Oceanbolt将作为一个独立的产品提供给Veson的客户,未来有可能将Oceanbolt数据直接集成到Veson IMOS平台。  Oceanbolt客户的强大商业能力形成决策依据的见解(如Oceanbolt提供的见解)最终必须融入企业工作流程,才能释放其真正的价值。Veson IMOS平台是一个强大的商业平台,其价值得到世界领先的船东运营商、商品交易商和吨位承租人的广泛认可,可为Oceanbolt客户提供必要的动态工具和能力,在数据能够发挥最大作用的时刻将其变为现实。此外,Veson拥有深厚的专业知识和专业功能,可为干散货、油轮和能源领域客户增加巨大的价值。  了解更多点击此处。  媒体垂询请直接联系Brooks Maitland,marketing@veson.com。 相关链接 :http://www.veson.com

    时间:2021-09-02 关键词: ce

  • Colt Data Centre Services将建设新的45MW大阪京阪奈数据中心

    (全球TMT2021年8月31日讯)提供全球超大规模数据中心解决方案的供应商 Colt Data Centre Services (Colt DCS) 开始了其在日本下一个超大规模数据中心的破土动工;该数据中心将位于关西地区京阪奈科学城,是一个占地42,000m2 的 45MW 数据中心。该站点将准备在 2023 年初为 Colt DCS 客户提供服务。 该运营商中立性且多样化的网络数据中心将经过专门设计,以用于满足超大规模和企业客户其不断增长的需求和寻求大型数据中心的可扩展容量需求。自 2011 年日本地震后,许多公司意识到了地理上分散站点的好处,因此对大阪附近的数据中心有很大的需求,因为这是灾难恢复计划的一个组成部分。为满足这一需求,才将新站点战略性地选择在京都和大阪交界处基岩上方仅 3 米的稳定土地上。 大阪京阪奈数据中心的建造将采用防震地基,使该建筑能够承受日本气象厅地震等级高达 7 级的大地震。 该数据中心将采用最先进的冷却技术来确保高效率,同时支持 Colt DCS 及其客户的可持续发展目标。 在 Colt DCS 宣布富达 与三井物产 成立合资公司之后,该站点将迅速破土动工,在日本建造先进的超大规模数据中心,并具有在亚太地区进一步发展的潜力。

    时间:2021-08-31 关键词: vi ic ce

发布文章

技术子站