distributedcomputing   646

« earlier    

Postmortem: VSTS 4 September 2018 – Service Blog – Azure DevOps
However, the reality of cross-region synchronous replication is messy. For example, the region paired with South Central US is US North Central. Even at the speed of light, it takes time for the data to reach the other data center and for the original data center to receive the response. The round-trip latency is added to every write. This adds approximately 70ms for each round trip between South Central US and US North Central. For some of our key services, that’s too long. Machines slow down and networks have problems for any number of reasons. Since every write only succeeds when two different sets of services in two different regions can successfully commit the data and respond, there is twice the opportunity for slowdowns and failures. As a result, either availability suffers (halted while waiting for the secondary write to commit) or the system must fall back to asynchronous replication.
cloud  distributedcomputing  database  captheorem  recovery  microsoft  ovum 
20 days ago by yorksranter
Cloudflare goes InterPlanetary - Introducing Cloudflare’s IPFS Gateway
Using Cloudflare’s gateway, you can also build a website that’s hosted entirely on IPFS, but still available to your users at a custom domain name. Plus, we’ll issue any website connected to our gateway a free SSL certificate, ensuring that each website connected to Cloudflare's gateway is secure from snooping and manipulation.
distributedcomputing  p2p  cdn  cloudflare  ipfs  ccn 
25 days ago by yorksranter
DBMS Musings: NewSQL database systems are failing to guarantee consistency, and I blame Spanner
(1) Systems that fail to guarantee consistency result in complex, expensive, and often buggy application code.
(2) The reduction of availability that is caused by the guarantee of consistency is minute, and hardly noticeable for many deployments.
(3) The CAP theorem is fundamentally asymmetrical. CP systems can guarantee consistency. AP systems do not guarantee availability (no system can guarantee 100% availability). Thus only one side of the CAP theorem opens the door for any useful guarantees.
I believe that the above three points is what has caused the amazing renaissance of distributed, transactional database systems
captheorem  distributedcomputing  database  nosql  newsql  hacker  google  spanner  cool 
25 days ago by yorksranter
What do you believe now that you didn't five years ago? Centralized wins. Decentralized loses. - High Scalability -
With cloud based edge computing we've entered a kind of weird mushy mixed centralized/decentralized architecture phase. Amazon let's you put EC2 instances at the edge. Microsoft has Azure IoT Edge. Google has Cloud IoT Edge and GKE On-Prem and Edge TPU. The general idea is you pay cloud providers to put their machines on your premises and let them manage what they can. You aren't paying other people to manage you're own equipment, the equipment isn't even yours. Outsourcing with a twist. Since the prefix de- means "away from" and centr- means "middle", maybe postcentralization, as in after the middle, would be a good term for it?
distributedcomputing 
7 weeks ago by yorksranter
Costs of task allocation with local feedback: Effects of colony size and extra workers in social insects and other multi-agent systems
If more workers are present than needed to complete the work available, some workers will always be idle; despite this, having surplus workers makes redistributing them across the tasks that need work much faster. Thus, unexpectedly, such surplus, idle workers may potentially significantly improve system performance
allocation  ants  distributedcomputing  cybernetics 
june 2018 by yorksranter
Distributed TensorFlow - O'Reilly Media
On the one hand: distributed tensorflow On the other, Android Neural Networks API: Hmm?
tensorflow  distributed  distributedComputing  NN  architecture  platform 
december 2017 by psychemedia
Notes on Distributed Systems for Young Bloods – Something Similar
New systems engineers will find the Fallacies of Distributed Computing and the CAP theorem as part of their self-education. But these are abstract pieces without the direct, actionable advice the inexperienced engineer needs to start moving. It’s surprising how little context new engineers are given when they start out.

Below is a list of some lessons I’ve learned as a distributed systems engineer that are worth being told to a new engineer. Some are subtle, and some are surprising, but none are controversial. This list is for the new distributed systems engineer to guide their thinking about the field they are taking on. It’s not comprehensive, but it’s a good beginning.
programming  distributed  distributedcomputing  fallacies 
september 2017 by stiefkind

« earlier    

related tags

2016  3dics  8b10b  academia  adc  adder  aes  ai  aio  algorithm  algorithms  allocation  alu  amazon  amdahlslaw  analysis  antennaeffect  ants  apache  apacheflume  apachekafka  apachestorm  arbiter  arbitrarywaveformgenerator  architecture  arstechnica  article  asic  asynchronouslogic  ate  atpg  audiocodec  auth  autonomousvehicles  availability  aws  bandwidth  beol  berkeley  bga  bgasubstrate  bigdata  bist  bitcoin  bittorrent  blockchain  blog  blogs  boinc  booleanalgebra  borg  btb  bugs  bumping  burn-in  c4istar  cache  cachecoherence  cam  cap  captheorem  captherum  ccn  cdn  chip  cisc  citizenscience  clockgating  cloud  cloudcomputing  cloudera  cloudflare  cloudserver  cloudstorage  cmos  code  coding  computerscience  computing  concistency  confluent  consensus  consistency  container  continuousdeployment  cool  coprocessor  cpi  cpu  crc  crdt  crosstalk  csa  cts  curated  cybernetics  dac  dask  dat  data  database  datacenter  db  dcos  dds  def  deployment  design  development  dfm  dft  dht  dib  dicing  die  dimm  distribute  distributed  distributedsystems  diy  dll  dma  dmm  docker  dominologic  dram  drc  driverlesscars  dsm  dsp  dut  dv  ecc  eco  eda  edacompanies  edgenetworks  editorial  elasticsearch  electromigration  electronics  elixir  emi  engineering  enterprisearchitecture  epos  erlang  esd  etcd  ethernet  explanation  f35  fabless  fallacies  faulttolerance  feol  fft  fib  fifo  files  filesystem  finfet  flash  flip-chip  flip-flop  foundry  fpga  fpu  fram  framework  fullcustomdesign  funtoclone  fusion  future  gartnerdc  gdsii  getpocket  git  go  golang  google  government  gpio  gpu  graycode  grid  gui  hacker  hackernews  hacking  hadoop  hardware  hbm  hdl  heatpipe  heatsink  highavailability  history  holdtime  hybridlogicalclocks  i2c  icassembly  idempotence  ifttt  infrastructure  integration  internet  internetofthings  interposer  iot  ip  ipfs  ipvendors  isi  javascript  jeffdean  jitter  jtag  kafka  kgd  lambda  lan  lasp  latchup  latency  layout  leadframe  learning  lef  lfsr  library  linux  list  loadbalancing  lofi  logging  logicaleffort  logicanalyzer  lsb  lvds  lvs  maglev  maskworks  matrix  mcm  mealymachine  mesos  mesosphere  messaging  microchips  microservices  microsoft  mii  mimd  mls  mmu  mongodb  monitoring  mooremachine  mooreslaw  mosfet  mosis  mpw  msb  mtbf  multi-thresholdcmos  multiplier  mux  mysqlha  nco  networking  newsql  nix  nn  noc  node  nosql  ntp  observability  offgrid  opencourse  opensource  operatingsystems  opticalproximitycorrection  oscilloscope  ovum  p2p  paas  packagemanager  paper  papers  parallelcomputing  passtransistorlogic  paxos  pcie  pcm  pdf  pdk  personpeterdeutsch  photo-lithography  photomasks  physicaldesign  pic  platform  pll  pop  post  powergating  pr  probecard  programming  pvtcorner  pwm  python  q  rabbitmq  radar  radiationhardening  raft  raid  reconfigurablecomputing  recovery  redundancy  relevance  replication  research  rest  reticle  riak  risc  robotics  rom  royalnavy  rtl  rubinius  sailing  samza  sbc  scheduling  schmitttrigger  screencast  sdr  searchengine  security  sem  semiconductorfabrication  semiconductors  serdes  serverless  setuptime  seu  shiftregister  signalling  signoff  silicon  silicononinsulator  simd  sip  smt  soa  soc  socialnetworks  software-development  software  softwareengineering  spanner  spectrumanalyzer  spi  spice  sql  sram  sta  standardcelldesign  stepper  stl  storm  stream  streamprocessing  subthresholdleakage  synchronouslogic  synthesis  system  systemc  systems  tape-out  tcl  technology  tensorflow  testing  time  tlb  tlink  tolearn  tool  topology  tradeoffs  transistor  tsv  tutorial  twitter  uart  ubuntu  usb  ux  verilog  video  videocodec  videos  virtualisation  virtualmemory  visualisation  vliw  vlsi  volunteer  vonneumannarchitecture  wafer  waferthinning  wan  webdevtools  webrtc  webservices  websocket  wifi  wirebond  workflowmanager  wsi  xmpp  zookeeper  Ømq 

Copy this bookmark:



description:


tags: