VirtualBox supports emulated e1000 NIC for VM while VMware fusion does not. VMware Fusion’s VM setting does not support configuring of NIC HW type. The NIC HW is PCnet32 which is not supported by DPDK.
However, we can change NIC HW type by editing VM configuration file directly.
Refer : How to emulate 10 Gbps NIC in a VMware Fusion VM
Edit vmx file to VMX file is in where vmware image located
DPDK Userspace in Dublin 2015에서 발표
Stageful traffic generator
특징 Generate traffic based on templates of real, captured flows No TCP/IP stack Up to 200Gbps with standard server hardware Low cost 1RU (C220M UCS-1RU) Cisco internal DPDK, ZMQ, Python libs Virtualization(vmxnet3/e1000) ~20Gbps per core Generate flow templates Support 1K templates Yaml based traffic profile GUI GUI which monitors real-time properties of TRex - min/max/average latency, jitter
Python 연동 Code https://github.com/cisco-system-traffic-generator/trex-core
From http://www.theeffectiveengineer.com/blog/what-makes-a-good-engineering-culture
1. Optimize for iteration speed Continous deployment to support rapid validation High test coverage to reduce build and site breakages Fast unit tests to encourage people to run them Fast and incremental compiles and reloads to reduce development time Bill Walsh, 49ers to 3 Super bowls,
Commit, Explode, Recover
A team crippled with indecisiveness will just cause individual efforts to flounders
2. Push relentlessly toward automation Consider operational burden per engineer
부서간 협력이 잘 안되는 듯 하니 대책으로 ‘부서간 협력지수’를 수치화해서 평가하겠다. 그럼 협력이 잘 될까 궁금하네
HP, Intel, Cisco/Juniper, WindRiver 외에 Orchestrator 관련 회사도 다수 존재.
개인적으로는 역시 Nokia가 가장 관심이 가는데
Telco Cloud portfolio - virtualizing radio functions - LTE eNB L2/L3 processing, MME and GW functionality, Wi-Fi controllers and virtual RNCs and vBSCs Multi-layer architecture - pioneers the use of Ethernet fronthaul and any combination of distributed and centralized deployments Processing capacity is allocated from almost anywhere in the network, such as an adjacent cell or a centralized data center, to where it is needed most for coordination and capacity.
어딘가 보고 정리한 글인데 출처를 기억하지 못하겠다….
SW 품질 개선 노력의 대상 SW 품질을 높이는데 Tool, System, People 그리고 Management중에 어떤 면을 개선하는 경우 효과가 높을까?
Tool : 2 배 System : 10배 People : 30배 Management : 60배 이상 그렇지만 대개의 관리자는 개선효과를 반대로 알고 있다.
사람은 변화해야 할 때 변화한다(더 이상 저항하지 못할 때) 그러나 위기는 갑자기 오지 않는다. 다만 위기에 대한 인지를 갑자기 할 뿐이다.
변화는 성능 저하를 유발한다.
경쟁을 부추켜서 조직의 성과를 얻으려는 관리자는 아무런 노력도 하지 않고 결과만 날로 먹으려는 것과 같다. 아무 고민없이 할 수 있는 제일 쉬운 방법이니까.
조직원들에게 동기부여를 줄지, 조직의 협동심을 아떻게하면 높일 수 있을 지 고민할 필요가 없이 결과만 취하면 되니까. 그런 관리자는 조직에 해를 끼치는 존재다.
할 수 있는 게 없는 건지,해도 안되는 건지. 여러가지 방법을 써도 안된다면 조직원과 함께 고민하면 안될까. 함께 속해 있는 ‘조직’의 성과를 위한 거니까
@유정식의 ‘착각하는 CEO’를 읽는 중 프랑스/베트남/쥐 박멸/쥐 사육 부분을 읽고
Link : http://www.bloter.net/archives/233978
스포카는 측정 가능한 업무 시스템을 위해 깃허브, 슬랙, 지라 같은 협업 도구를 이용했다. 직원들은 협업 도구들로 기록을 철저히 하면서 업무상황을 공유하고 있다. 기록 내용은 아주 자세한 내용을 담는다. 예를 들어 ‘○○에게 e메일을 보냈다’, ‘A에게 답변을 받았다’, ‘개발을 위한 자료 조사 중’ 같은 식이다. 이 내용은 직원별로 볼 수 있다. e메일 내용이 어떤 것이었는지, 자료 조사는 어떤 것을 했는지도 상세히 기록되고 있다.
김재석 CTO는 “처음에는 기록을 습관화하는 데 시간이 조금 더 걸렸다”라며 “기록을 편하게 할 수 있도록 기존 협업도구를 스포카 환경에 맞게 재개발하기도 했다”라고 설명했다.
from NASA/JPL(Jet Propulsion Laboratory)
The result is that most existing guidelines contain well over a hundred rules, sometimes with questionable justification. Some rules especially those that try to stipulate the use of white-space in programs, may have been introduced by personal preference; others are meants to prevent very specific and unlikely types of error from eariler coding efforts within the same organization.
효율적인 가이드라인이 되려면, rule의 개수는 적어야 하고, 쉽게 이해되고, 기억될 수 있을 만큼 명확해야 한다.
출처 : 관리의 기본 (Fundamental of management) #2 - 관리자/리더에게 필요한 역량
가장 중요한 것은 Communication 역량으로, 팀내 또는 팀간의 조율을 위해서는 반드시 필요한 능력이라고 생각한다. 두말할 필요가 없는 부분인데, 효과적인 커뮤니케이션 스킬을 가지기 위해서는 상호 존중이 바탕이 되어야 한다. 존중의 바탕이 없이는 명령이되고, 명령은 팀을 Push하는 모델을 만들지, 팀이 스스로 높은 성과를 낼 수 있도록 Pull (당기는 형태)의 리더쉽을 만들어내기는 어렵다.
관리자로써 전체적인 계획을 만들고 이를 실행하려면, 팀원들을 코칭할 필요가 있다.