in compute_study.md, it is indicated that
'Duplicate each study for 2, 4, 8, and 16 workers per node (reducing chunk size proportionally)'
But I do not recall this reduction of chunk size for each increase of workers per node in utils.py,
am i missing something??
Let me look more closely...
@tinaok Also, if you are planning on attending the Pangeo community meeting remotely, you might be able to present some of your benchmarking work in a Lightning Talk. It would be a very short (and remote) presentation, but it might be possible. @jhamman would know for sure.
@tinaok Ok. I've looked more closely at the benchmarking code. (@andersy005 may have something more to say about this, but I'll take a stab myself.) The design of the current code assumes 1 chunk per worker (see
benchmarks/datasets.py), and it therefore assumes that the total dataset size will be equal to the (chunk size) * (number of nodes) * (number of workers per node).
This may not be optimal, but I think this can be amended in later versions.
The thought behind the
compute_study.md writeup was to sketch out what would be needed to generate some preliminary scaling studies for various "common" operations done with xarray and dask. The results of each study should be a plot of "Number of Nodes" vs "Operation Runtime". However, the "Operation Runtime" depends on much more than "Number of Nodes", including "Number of Workers per Node", "Number of Threads per Worker", "Total Number of Chunks", "Chunk Size", etc.
I wanted to consider 2 kinds of studies, strong and weak, since these are considered "canonical" in the HPC world. In the strong scaling studies, the "Total Data Size" should be fixed while the "Number of Nodes" is varied. In the weak scaling studies, the "Data Size per Node" should be fixed while the "Number of Nodes" is varied.
When I was coming up with the
compute_study.md document, I tried to find a way to fix all of the other parameters in a way such that each study was "fair." I chose 1 "Chunk per Worker" and 1 "Thread per Worker", and I chose to vary the "Chunk Size" and "Number of Workers per Node". And later we tried to come up with a way of varying the "Chunking Scheme" (i.e., chunk over all dimensions, chunk over only spatial dimensions, chunk over only time), too. But we need to generate data that looks at how these numbers vary with "Chunks per Worker" and "Threads per Worker", too.
@/all - the agenda and attendee list for next week’s community meeting in Seattle is now final. See details here: http://pangeo.io/meetings/2019_summer-meeting.html#
Remote participation details are also available on this page. @kmpaul - we’ll probably need to wait and see if remote lightning talks will work. We may need a proxy presenter.
thought folks on this channel might be interested in this job opening at JPL https://jpl.jobs/jobs/2019-10892-Big-Data-Software-Lead
Is anyone else experiencing the
Error displaying widget with e.g. the dask_kubernetes.KubeCluster widget (or any other widget)? It looks like this is related to ipywidgets==7.5. I have a Pangeo environment with jupyterlab=0.35, tornado=5.1.1 and dask_labextension==0.3.3, because I noticed that it was a working configuration at some point, but I'm not sure this is still the recommended configuration.
We are also logging this on big-query: https://console.cloud.google.com/bigquery?d=dev_pangeo_io_usage_metering&p=pangeo-181919&page=dataset&project=pangeo-181919 but I haven’t looked at these logs yet.
actually, I just did it. Two issues for you to peak at: https://github.com/pangeo-data/pangeo-cmip6-examples/issues
2d is the hex representation of an ascii - still doesn’t explain why k8s puts the hex code in the pod name.
it's fun to have data!
everything has to be parsed out of kubernetes API calls
Here are the different API method calls
method_name
io.k8s.core.v1.pods.attach.create 8
io.k8s.core.v1.pods.binding.create 291582
io.k8s.core.v1.pods.create 66682
io.k8s.core.v1.pods.delete 656336
io.k8s.core.v1.pods.eviction.create 312632
io.k8s.core.v1.pods.exec.create 204
io.k8s.core.v1.pods.get 109
io.k8s.core.v1.pods.portforward.create 3974
io.k8s.core.v1.pods.status.patch 17
io.k8s.core.v1.services.proxy.get 6
what is a binding and what is an eviction?
how do
binding.create and eviction.create differ from just create?
I do see that there are roughly equal parts create & delete calls so it must be something to do with the type of pod created. All delete calls tend to use the same api.
and when a pod isn't welcome anymore it gets evicated
for example because there are more important pods that need resources
@choldgraf, @mrocklin, @lheagy, @lila, @rabernat - tentative plan to get drinks at Sol Liquor Lounge c.8pm sound okay with people? Lots of good dinner options around there but I won’t be able to join until after the dinner hour.
As indicated on slack some discussion questions for general and education:
Open Questions on Education (will also post on Gitter)
Please read and consider responding out Wednesday. We plan to devote 20 of our 30 minutes on pangeo education to open discussion. Further planning on pangeo Education will follow Thursday.
- "What is pangeo?" or a longer version "What is unclear or perhaps confusing about pangeo?" is worth articulating: In order to proceed to "Who and what and how is pangeo teaching?"
- Should (How should?) the pangeo Education WG play a role in testing pangeo tech?
- Does "publications = evidence of pangeo impact" work as a retrograde motivator on the challenge of "What should the pangeo team be emphasizing today?" (both Education and more broadly)
- Comment on the value of the imperative "Get dataset X wired into pangeo" ...motivating scientists who use X to migrate to pangeo. What is { X }? Process to select and import X? Should Pangeo Ed teach you how to import some X?