| [atom] 1 process: 3163.35764706 total Watts consumed | |
| [atom] 1 process: 1043 s | |
| Watts per second: 3.03294117647 | |
| [atom] 2 processes: 4720.97058824 total Watts consumed | |
| [atom] 2 processes: 1063 s | |
| Watts per second: 4.44117647059 | |
| [atom] 3 processes: 6622.40465116 total Watts consumed | |
| [atom] 3 processes: 1345 s | |
| Watts per second: 4.92372093023 | |
| [atom] 4 processes: 8888.5296 total Watts consumed |
| getTime() implemented with clock_gettime(), using CLOCK_REALTIME (http://linux.die.net/man/3/clock_gettime) | |
| not 100% accurate for beginning of cmsRun process, but since there are so many samplings, I think that's not problematic | |
| start_time = getTime() | |
| while(cmsRun_is_alive()) | |
| if(diff_bigger(start_time, now = getTime(), 1ms)) | |
| start_time = now | |
| measure_rapl() | |
| streams | |
| streams can be seen as channels through were data flow in, out, or in both directions. the streams have different states, depending on what's happening at the given moment: streams can have data available, ready to receive more data, amongst others. these states are announced to the application through Events. thus, streams are EventEmitters which means they emit predefined events depending on its state. for example, when a source stream (from where data flows out) emits a 'readable' event, new data is ready to be read from that stream. the same happens with writtable streams and all the others. this design is really handy to control and monitor our streams and keeping the code clean and following a well defined design pattern. | |
| streams are used in fs | |
| in production code example | |
| <div id="player" class=" watch-medium "> | |
| <div id="theater-background"></div> | |
| <div id="player-mole-container"></div> //here goes the player | |
| <div class="clear"></div> | |
| </div> | |
| #theater-background{ | |
| position:absolute; | |
| left:0; |
| 1. How to run a team of people who never see each other | |
| http://qz.com/230998/how-to-run-a-team-of-people-who-never-see-each-other/?utm_content=bufferb282b&utm_medium=twitter.com&utm_source=social&utm_campaign=buffer | |
| 2. 12 startups in 12 months. levels.io article | |
| http://www.techinasia.com/12-startups-in-12-months-how-this-digital-nomad-doing-it/ | |
| 3. Our decentralized future (by Pietr Hinjens) | |
| https://www.youtube.com/watch?v=36bKE_JsHZs | |
| 4.Log management on SmartOS feat DTrace and Nodejs (by Joyent) |
| >> when trying to compile ParFullCMS on tlabphi02: | |
| (...) | |
| [3/4] Compiling Geant4 logfile: compilation.log | |
| G4 done | |
| mkdir: cannot create directory `build-CMS': Disk quota exceeded | |
| ./build.sh: line 182: cd: build-CMS: No such file or directory | |
| [4/4] Compiling application logfile: compilation.log | |
| ./build.sh: line 194: ../compilation.log: Disk quota exceeded |
###consensus-manager
####consensus wrapper for a distributed topology
The consensus manager listens and stores responses from remote peers until the consensus is reached. The consensus is reached depending on the strategy implemented.
The consensus manager controls:
| The blockchain application stack | |
| - http://joel.mn/post/103546215249/the-blockchain-application-stack |
| From: Joylent <love@joylent.eu> | |
| Date: 15 January 2015 at 16:49 | |
| Subject: Joylent shipment update | |
| To: Gonçalo <g6pestana@gmail.com> | |
| Dear Gonçalo, | |
| As you have previously read on one of our social medias (or perhaps you’ve already mailed us about this), | |
| last week we suffered yet another mechanical breakdown causing our production line to come to a standstill. |
| var zmq = require('zmq'); | |
| var david = "tcp://192.168.1.225:8888"; | |
| var pestana = "tcp://192.168.1.240:8887" | |
| var port ="tcp://127.0.0.1:12345" | |
| //client | |
| var cli_sock = zmq.socket('dealer'); |
