1 |
On 08/10/2016 10:20 AM, Michael Mol wrote: |
2 |
> On Wednesday, August 10, 2016 10:13:29 AM james wrote: |
3 |
>> On 08/10/2016 07:45 AM, Michael Mol wrote: |
4 |
>>> On Tuesday, August 09, 2016 05:22:22 PM james wrote: |
5 |
> |
6 |
>>>> |
7 |
>>>> I did a quick test with games-arcade/xgalaga. It's an old, quirky game |
8 |
>>>> with sporadic lag variations. On a workstation with 32G ram and (8) 4GHz |
9 |
>>>> 64bit cores, very lightly loaded, there is no reason for in game lag. |
10 |
>>>> Your previous settings made it much better and quicker the vast majority |
11 |
>>>> of the time; but not optimal (always responsive). Experiences tell me if |
12 |
>>>> I can tweak a system so that that game stays responsive whilst the |
13 |
>>>> application(s) mix is concurrently running then the quick |
14 |
>>>> test+parameter settings is reasonably well behaved. So thats becomes a |
15 |
>>>> baseline for further automated tests and fine tuning for a system under |
16 |
>>>> study. |
17 |
>>> |
18 |
>>> What kind of storage are you running on? What filesystem? If you're still |
19 |
>>> hitting swap, are you using a swap file or a swap partition? |
20 |
>> |
21 |
>> The system I mostly referenced, rarely hits swap in days of uptime. It's |
22 |
>> the keyboard latency, while playing the game, that I try to tune away, |
23 |
>> while other codes are running. I try very hard to keep codes from |
24 |
>> swapping out, cause ultimately I'm most interested in clusters that keep |
25 |
>> everything running (in memory). AkA ultimate utilization of Apache-Spark |
26 |
>> and other "in-memory" techniques. |
27 |
> |
28 |
> Gotcha. dirty_bytes and dirty_background_bytes won't apply to anything that |
29 |
> doesn't call mmap() with a file backing or perform some other file I/O. If |
30 |
> you're not doing those things, they should have little to no impact. |
31 |
|
32 |
Background needed:: I'm one of those (idealists?) that deeply believes |
33 |
the holy grail of computing will soon emerge (nice pun huh). That is |
34 |
that clusters, local clusters will run all workloads that multicore |
35 |
systems currently do. So a bunch of old crap can become a beautiful |
36 |
computational system, whilst I sit back and sip exotic beverages and |
37 |
enjoy my day; video training to go to the gym and dominate the young |
38 |
studs on the court.... New hardware (aka new computers and cosmetic |
39 |
surgery) will do the rest. |
40 |
|
41 |
So an incredible variety of memory, storage and file systems will |
42 |
ultimately need to be tested. I try to stay simple and focused (believe |
43 |
it or not). Initially the thought is to run a primitive desktop, like |
44 |
lxde or lxqt and use those under utilized resources as |
45 |
node-computational contributors, whist still remaining responsive at the |
46 |
keyboard (xgalaga is a quick and dirty test for this). So, you now have |
47 |
a wonderful cover story is the boss catches you noodling around with |
48 |
swords and sorcery to, you can tell'm you looking for subtle latency |
49 |
issues...... The game speeds up and slows down, with zero swapping, due |
50 |
to my I suspect mostly as VM issues and MM issues. |
51 |
An 8 core never goes above 0.2 on the load and only rarely saturates one |
52 |
core, for a transient instance. Even if xgalaga is a single thread game, |
53 |
it does not explain this transient keyboard lag. I'm open to other forms |
54 |
of quick at-the-keyboard graphical tests as a quick and dirty |
55 |
measurement of overall system attentiveness to pending addtional |
56 |
input/workload demands. After that is happy, with a given set of running |
57 |
codes (test-vectors) I can get a very quick feedback of performance this |
58 |
way. |
59 |
|
60 |
For deeper studies, I like trace-cmd/Ftrace/KernelShark, but those are |
61 |
like zabbix on utilization and analytical studies. I use xgalaga as a |
62 |
quick and dirty; but am surely open to new codes for that sort of quick |
63 |
and easy feedback. |
64 |
|
65 |
|
66 |
|
67 |
> Ideal values for dirty_bytes and dirty_background_bytes will depend heavily on |
68 |
> the nature of your underlying storage. Dozens of other things might be tweaked |
69 |
> depending on what filesystem you're using. Which is why I was asking about |
70 |
> those things. |
71 |
|
72 |
A myriad of combinations exist. So picking some common combinations, |
73 |
will allow for others to test my work, when it is package up for sharing |
74 |
and testing. For me eventually automating a collection of 'test vectors' |
75 |
is what's important, not the first few test-vectors themselvs. Then the |
76 |
pathway forward for other collections of running processes can become |
77 |
yet another collection of 'test vectors'. No limit on these collectives. |
78 |
Eventually a customer will step forward and define the collective of |
79 |
'test vectors', so I do hope to work with/for one of the more |
80 |
progressive vendors, eventually, in these efforts. Certainly sharing the |
81 |
work, openly, is far more important to me. For now, I start with things |
82 |
I like, know and have some familiarity with; no magic on these choices. |
83 |
|
84 |
|
85 |
>> Combined codes running simultaneously never hits the HD (no swappiness) |
86 |
>> but still there is keyboard lag. |
87 |
> |
88 |
> Where are you measuring this lag? How much lag are we talking about? |
89 |
|
90 |
Remember, I'm an EE and complex fluids computational kind of guy, so I |
91 |
have no problem drudging down the sparse or full matrix types of |
92 |
mentally inebriating adventuresome calculations, like computational |
93 |
chemistry. But, since this approach is not yet ready for those sorts of |
94 |
things, I keep things simple; for now. What I want, is an automated |
95 |
installation semantic, where folks can download images and run them on |
96 |
their small clusters) on a weekly basis and keep solving the same |
97 |
test-vector collectives over and over. Tweaks and ideas are in the newly |
98 |
released images, a group of gentoo-users test things out. But |
99 |
an automated, quick and simple gentoo system, flies against what most |
100 |
folks believe in this community (dammit, I have to respect, so I work on |
101 |
my one scripts I have lifted from others) {wink wink; nudge nudge}. |
102 |
As you already know.... |
103 |
|
104 |
|
105 |
>> Not that it is actually affecting the |
106 |
>> running codes to any appreciable degree, but it is a test I run so that |
107 |
>> the cluster nodes will benefit from still being (low latency) quickly |
108 |
>> attentive to interactions with the cluster master processes, regardless |
109 |
>> of workloads on the nodes. Sure its not totally accurate, but so far |
110 |
>> this semantical approach, is pretty darn close. It's not part of this |
111 |
>> conversation (on VM etc) but ultimately getting this right solves one of |
112 |
>> the biggest problems for building any cluster; that is workload |
113 |
>> invocation, shedding and management to optimize resource utilization, |
114 |
>> regardless of the orchestration(s) used to manage the nodes. Swapping to |
115 |
>> disc is verbotim, in my (ultimate) goals and target scenarios. |
116 |
>> |
117 |
>> No worries, you have given me enough info and ideas to move forward with |
118 |
>> testing and tuning. I'm going to evolve these into more precisely |
119 |
>> controlled and monitored experiments, noting exact hardware differences; |
120 |
>> that should complete the tuning of the Memory Management tasks, within |
121 |
>> acceptable confine . Then automate it for later checking on cluster |
122 |
>> test runs with various hardware setups. Eventually these test will be |
123 |
>> extended to a variety of memory and storage hardware, once the |
124 |
>> techniques are automated. No worries, I now have enough ideas and |
125 |
>> details (thanks to you) to move forward. |
126 |
> |
127 |
> You've got me curious, now you're going to go run off and play with your |
128 |
> thought problems and not share! Tease! |
129 |
|
130 |
Dude, I share too much. If you had not gone of vacation (from |
131 |
gentoo-user) you'd know this. Since I am way too mentally handicapped to |
132 |
do all of this on my own, (and too old and wise to even try) I routinely |
133 |
seek guidance and help. I read quite a lot, to remind me of the mistakes |
134 |
from previous distributed parallel computational attempts; and that |
135 |
reading also saddens me a bit to see so many malformed cluster ideas. Oh |
136 |
well, failure is the most important lesson technical folks learn. Most |
137 |
often ideas just bounces off the wall right back at me, but I have |
138 |
learned to duck (most of the time). YOU and anyone else are most welcome |
139 |
to join my efforts; we all shall benefit from robust, local clusters, as |
140 |
masters of gentoo (or poezer of gentoo, just like me). <end philosophy> |
141 |
|
142 |
So while we are at it, scripts or stage-4 images that can be rapidly |
143 |
booted up on a given small hardware cluster, are keen to my approach. |
144 |
Memory management, is probably the most challenging aspect of building |
145 |
and robustly (efficient resource utilization) managing these clusters |
146 |
or outsourced clusters (clouds in vendor speak). I Use the same cluster |
147 |
setup, to test a myriad of different problem-solution sets on the |
148 |
identical hardware, but only change the software, including file |
149 |
systems: both DFS (cephfs/orangefs/openAFS/Beefs) and the local fs (xfs, |
150 |
ext4,) and well as hybrids like btrfs and special file systsems like |
151 |
bcache. On top of Openstack, Hadoop, Mesos, old Beowulf (with a fast DFS |
152 |
replacing NFS) and others. |
153 |
|
154 |
Once domain specific problems are moved to a cluster and that solution |
155 |
set is near-optimal, after robustly testing many codes, in a CI fashion |
156 |
outlined above, it becomes a stage-4 canned solution for somebody to run |
157 |
on their hardware. If they need more hardware resouces, within a |
158 |
specific interval, THEN outsource those resource needs to the Cloud |
159 |
Vendors. Expecting a cloud vendor to be a champion of your Domain |
160 |
Specific need, is a roadmap to chapter 11 or 13, for that corporation. |
161 |
I suspect that once AWS and Google and MS and IBM learn what the NSA |
162 |
already knows, there will be a feeding frenzy on aquisitions of old |
163 |
technology companies. That's ultimately where the action is in clusters. |
164 |
|
165 |
All of this 'smoke and mirrors' marketing centric on social networks is |
166 |
just that; smoke and mirros. Why do I say this? Simple; there already is |
167 |
enough processing power to solve those problems and needs with current |
168 |
Snoracle style solutions and the by the bloated on wall-street. |
169 |
|
170 |
Now HPC, dude, that's the sweet edge of clustering. There are numerous |
171 |
gargantuan issues in that sphere and a few, like DESHAW are getting RICH |
172 |
off of clusters. He, a single Stanford professor, mastered computational |
173 |
chemistry, and locked his expertise into ASIC chips. |
174 |
Now he is conquering wallstreet. Domain Specific solutions are where the |
175 |
action is in clusters. It not that there's not money in the social |
176 |
networking spheres, those are locked up by the 'cost barrier to entry' |
177 |
semantics. OK, I digress. But the important thing is local clusters, |
178 |
taht can be rapidly build and torn down and reconfigured, with a few |
179 |
simple keystrokes, are the future of clusters. A given small to mid |
180 |
sized company better learn how to build their own clusters, or they be |
181 |
in the welfare line, like several other billion folks are. |
182 |
|
183 |
|
184 |
CoreOS and unikernels are really quite similar to my approach to |
185 |
clusters. A variety of Problem-solutions sets (aka test vectors) on |
186 |
identical hardware will light the pathway for Domain Specific cluster |
187 |
solutions. Mine will be a node cluster on amd64, for now. |
188 |
|
189 |
So, I'm not sitting on some Stanford level of skills or knowledge base |
190 |
(think amplabs). I have decades of experiences in mostly unfulfilled |
191 |
promises for ubiquitous distributed processing, and only narrowly (very |
192 |
tightly) focuses success stories. Still, I am a believer in that the |
193 |
current crop of linux clusters will become an Utopia computation engine |
194 |
system that works from the most modest of needs like mundane admin |
195 |
taskloads to the most demanding, time-sequence RT simulations of some of |
196 |
the grand challenges in computational dynamics and similar areas. |
197 |
|
198 |
But, after several years of research, I mostly see kids trying the same |
199 |
crap we tried decades ago, with a new 'fancy-pants' programming |
200 |
language:: (hence the prediction that the current cluster kids are being |
201 |
manipulated by the VC firms and deep pocketed folks toward certain |
202 |
failure), whilst they pay off their debts. Same story, different overlord. |
203 |
|
204 |
|
205 |
I am conflicted as to whether this is intentional or just a repeat of |
206 |
tards leading the blind and innocent off the cliff. That is most of the |
207 |
vendor centric cluster (marketers call these clouds), developing new |
208 |
codes are clueless. That said, surely those corps with large collections |
209 |
of existing software can migrate those critical codes to the cloud and |
210 |
only offer new versions of that software, with a (cloud centric) |
211 |
internet-needed license. Think Azure/MS, IBM etc etc. But that sort of |
212 |
position, will just allow competitors to eat away larger chunks of their |
213 |
market share. (But I really don't care about his part of the Cloud |
214 |
illusion. I'm a hard core hardware type who already knows that the |
215 |
future of clusters is mostly local, with local control. The cloud will |
216 |
become a secondary or tertiary market for cpu cycles and garbage |
217 |
collection (think social networking databases). Sure folks will put |
218 |
their websites on commercial clouds, but that is already just a natural |
219 |
evolution of Co-location of server and not some breakthrough is technology. |
220 |
|
221 |
|
222 |
|
223 |
|
224 |
Down this pathway, the developments in the latest version of Clang, gcc, |
225 |
etc etc, and EEs making the resources of the GPU (including DDR5+) into |
226 |
a transparent computational resource for the routine compilers. rDMA is |
227 |
going to change (everything). Ram will finally not be the bottleneck, as |
228 |
FPGA and GPU resources can be configured, dynamically, as either highly |
229 |
specialize processors or highly specialized memory (look at CAMs, or |
230 |
Content Addressible Memory for a teaser). Router vendors have been |
231 |
making billions of dollars by adding CAMs to otherwise mundane |
232 |
processing systsems. |
233 |
|
234 |
No more of those ancient (intel) parallel compilers and shit like |
235 |
that.... Plus and avalance of re-configurable memory types; mostly |
236 |
transparent to folks that use "emerge" for custom compiling. Then there |
237 |
is a hardened kernel. Few in the cluster world even know such things |
238 |
exist; more sadly why they are necessary and when they are necessary. |
239 |
Keep puffing on that buntu hoka pipe, brah_heim..... |
240 |
|
241 |
|
242 |
The flip side to this is that a lot of Vendors think that bloated linux |
243 |
operating systems, on top of non-tuned, non-stripped insecure linux |
244 |
kernels is going to be commercially viable. If you build your house on |
245 |
turds, when it starts to rain, there is a funky smell in the air, before |
246 |
it washes away. Bloated buntu, debian or RHEL are turds and are not |
247 |
going to work compared to stripped, minimal linux systems. That's where |
248 |
Docker, just "bitch-slapped" their competition by moving to subsume |
249 |
Apline linux..... |
250 |
|
251 |
Your postings and clarity on VM, has helped me focus, immensely. It is |
252 |
the current need in my work. Have I shared enough for you, today? |
253 |
|
254 |
Any other questions, or ideas are most welcome, publically or privately. |
255 |
I could be wrong about all of this, but, my fourth generational stab at |
256 |
ubiquitous (distributed || parallel) processing experiences tell me I'm |
257 |
not wrong but have the right idea. I do lack current skills in so many |
258 |
areas, that my work is impeded. |
259 |
|
260 |
Without the gentoo community, I could not posses such visions of |
261 |
future-present greatness; nor share it with others. |
262 |
|
263 |
|
264 |
|
265 |
|
266 |
>>>> Perhaps Zabbix +TSdB can get me further down the pathway. Time |
267 |
>>>> sequenced and analyzed data is over kill for this (xgalaga) test, but |
268 |
>>>> those coalesced test-vectors will be most useful for me as I seek a |
269 |
>>>> gentoo centric pathway for low latency clusters (on bare metal). |
270 |
>>> |
271 |
>>> If you're looking to avoid Zabbix interfering with your performance, |
272 |
>>> you'll |
273 |
>>> want the Zabbix server and web interface on a machine separate from the |
274 |
>>> machines you're trying to optimize. |
275 |
>> |
276 |
>> agreed. |
277 |
>> |
278 |
>> Thanks Mike, |
279 |
>> James |
280 |
> |
281 |
> np |
282 |
|
283 |
|
284 |
Clusters will end up on people's wrist watches, in the trunks of their |
285 |
autos and at their homes:: So they control their computational needs and |
286 |
security, sooner rather than later. I think the next president will |
287 |
mandate the opening of the OS to many vendors and open source for Cell |
288 |
phones, Apps and such. The current monopolies are excessively more |
289 |
powerful than the old 'robber barrons' and that fact is well recognized |
290 |
by lost of deeper thinkers. It's braned under globalization, but, it's |
291 |
demise is just under the horizon, imho. |
292 |
|
293 |
True, ubiquitous clusters will be a result of hard work on compilers |
294 |
that take sequential problems and break them down into pieces and |
295 |
reassemble them into a form that can leverage parallel techniques. gcc 5 |
296 |
and 6 and Clang are moving, rapidly in this direction. GPU vendors |
297 |
understand the importance of SIMD and MIMD processing for 'systolic' |
298 |
algorithms and such approaches to massive distributed processing. AMD |
299 |
(Radeon) understands that this power can most effectively be used, if it |
300 |
is cheap and open sourced. Nvidia, no so quick to follow (or lead) down |
301 |
this open source path, imho. Intel purchasing a FPGA company and |
302 |
licensing GPU technologies from many others, tells me the hardware |
303 |
vendors are preparing for a revolution. A direct sales channel to the |
304 |
commoners will be their greatest path to rediculous profitability. Why? |
305 |
Simple, the smaller the core (competitive team) that exists, the more |
306 |
excessive processing resources that will be purchased and purchased |
307 |
closer to the retail price. |
308 |
|
309 |
When hardware vendors partner with a few sofware companies, the margins |
310 |
on hardware get squeezed. Besides the hackers of the work, are finding |
311 |
any critical barriers to codes and publishing it so all have fair access |
312 |
to the latest codes (one way or another). The NSA and such entities are |
313 |
not going to stop this, because all of this software espionage, |
314 |
justifies governments taxing the snot out of citizens to fight those |
315 |
evil hackers. It's a far superior business model for DoD |
316 |
types like intel and google, than the cold ware ever though about being. |
317 |
The average tax-payer is too stupid to realize social network, with an |
318 |
Onior approach, is just feeding data-sets via google, linkedin, facebook |
319 |
etc, directly to the NSA and other Nation State actors. WE get jobs |
320 |
and pay taxes. They set the rules and manage the data. |
321 |
|
322 |
Problem is, eventually, the commoners will have sufficent clusters, |
323 |
solar panels water wells or sources and green house and tell da_main |
324 |
to stick his taxes on imports. Fine that works, then everybody gets |
325 |
a 3D printer and we, the commoners are self sufficient. |
326 |
|
327 |
The simple fact is that is a great business model for EVERYONE, |
328 |
including the elites, so what are we waiting on? A stupid old man like |
329 |
me? Naw, not at Gentoo, buntu, sure, RHEL definately, but not gentoo, |
330 |
brah. WE are the solution to everything! |
331 |
|
332 |
</> |
333 |
|
334 |
James |