4 ms·

I don't know the exact numbers, but it is regularly evaluated, and they found that it won't save money moving to the cloud (yet). Apparently, grid jobs have di

I don't know the exact numbers, but it is regularly evaluated, and they found that it won't save money moving to the cloud (yet). Apparently, grid jobs have different IO/CPU/Memory characteristics from typical cloud applications. My jobs tend to use a lot of CPU and bandwidth, but are mostly IO bound. A friend did a very, very CPU intensive analysis for his PhD, and they estimated that it would cost $30 million to run it on AWS. I'm not sure where they got that number from, so take it with a grain of salt, but even if they are an order of magnitude off, it is still prohibitive. Another issue we are facing is RAM consumption. Many scientists are not trained programmers, so there are a lot of memory leaks. It didn't use to matter, an analysis program ran only a few hours and was single-threaded anyway. Now we are moving to using multi-threading, and we have been using multi-processing anyway... And as I understand it, in modern hardware the RAM/CPU ratio is getting lower and lower. If your job or thread needs 8 GB RAM, you can't run many of them on a 32 core CPU... So yeah, I think the main issue is wierd resource usage patterns. Not that it would be impossible. Grid computing is basically just a weird parallelly evolved version of cloud computing, after all.

Coding_Cat 10y ago
For the Alice experiment most jobs are IO limited. Although throughput should be improved by run 3 via backend changes (I hope so at least, currently doing my MSc. thesis on exactly that...). Simulations are compute heavy, but analysis tasks vary, with the speed of a modern processor future analysis is still likely to be IO/bandwidth limited. The ratio of RAM to core on the test server I have access to is 128/20 so 6.4 GiB per core. But for (future) analysis the plan is to use, or at least try to use, shared memory and grouping users tasks together based on the required data (They speak of an analysis train with wagons). So a large part of the ram requirements, namely the backing data, should be shared among the cores. I think ideally there will be a top-level scheduler for each node which tries to minimize the required bandwidth (but that is outside the scope of my work so who knows how it's implemented). With a few "best practices" it should be possible for most analysis to consume a 'reasonable' amount of memory at any given time in that case.

Coding_Cat 10y ago

For the Alice experiment most jobs are IO limited. Although throughput should be improved by run 3 via backend changes (I hope so at least, currently doing my MSc. thesis on exactly that...). Simulations are compute heavy, but analysis tasks vary, with the speed of a modern processor future analysis is still likely to be IO/bandwidth limited. The ratio of RAM to core on the test server I have access to is 128/20 so 6.4 GiB per core. But for (future) analysis the plan is to use, or at least try to use, shared memory and grouping users tasks together based on the required data (They speak of an analysis train with wagons). So a large part of the ram requirements, namely the backing data, should be shared among the cores. I think ideally there will be a top-level scheduler for each node which tries to minimize the required bandwidth (but that is outside the scope of my work so who knows how it's implemented). With a few "best practices" it should be possible for most analysis to consume a 'reasonable' amount of memory at any given time in that case.