Admin interface not running

Hi there,
I've installed influxdb from homebrew (yesterday) and tried to run it by:
influxdb -config=/usr/local/etc/influxdb.conf

but the admin interface is not running. I get connect refused for both the admin interface and API (ports 8083 and 8086). The config is default.
Also I checked lsof and really it is listening just on the raft and protobuf ports.
The log is:
[01/22/14 19:33:29] [INFO] Redirectoring logging to influxdb.log
[01/22/14 19:33:29] [INFO] Starting Influx Server...
[01/22/14 19:33:29] [INFO]
+---------------------------------------------+
|  _____        __ _            _____  ____   |
| |_   _|      / _| |          |  __ \|  _ \  |
|   | |  _ __ | |_| |_   ___  _| |  | | |_) | |
|   | | | '_ \|  _| | | | \ \/ / |  | |  _ <  |
|  _| |_| | | | | | | |_| |>  <| |__| | |_) | |
| |_____|_| |_|_| |_|\__,_/_/\_\_____/|____/  |
+---------------------------------------------+

[01/22/14 19:33:29] [INFO] Opening database at /usr/local/var/influxdb/data
[01/22/14 19:33:29] [INFO] ProtobufServer listening on :8099
[01/22/14 19:33:29] [INFO] Initializing Raft HTTP server
[01/22/14 19:33:29] [INFO] Raft Server Listening at http://Michals-MacBook-Pro.local:8090
[01/22/14 19:33:29] [INFO] Initializing Raft Server: /usr/local/var/influxdb/raft 8090
[01/22/14 19:33:29] [DEBG] Recovering the cluster configuration
[01/22/14 19:33:29] [INFO] ClusterServer: 1 connecting to: Michals-MacBook-Pro.local:8099
[01/22/14 19:33:29] [INFO] Recovered from log
[01/22/14 19:33:29] [INFO] Waiting for local server to be added
[01/22/14 19:33:29] [INFO] connected to Michals-MacBook-Pro.local:8099
[01/22/14 19:33:29] [INFO] ProtobufServer: client connected: <IP_ADDRESS>:51582
[01/22/14 19:33:29] [INFO] (raft:fec395b) Selected as leader. Starting leader loop.
[01/22/14 19:33:30] [DEBG] (raft:fec395b) Executing leader loop.

Will try to build in instead of installing from the bottle.
Do you need more info?

I've just encountered this issue (admin UI & API not starting) on v0.8.8 on OSX Yosemite.  I had a working configuration previously, just haven't used it in a while.  Clearing out (well renaming to .bak) the /usr/local/var/influxdb/data directory didn't help.  However, renaming the /usr/local/var/influxdb/raft directory did fix things - except now the UI doesn't know anything about my old databases (even after I restored the prior /data directory).  Worth reopening?

@worrel thanks for the additional issue report, but there is no active development on the 0.8.x branch or any new releases of the packages.
The raft directory contains all the metadata for the instance. If that is moved, the database cannot find previous data.


Build the tweet query system

[x] Understand how does the twitter api works.
[x] Build a dummy query for test purposes.
[ ] Build the custom query system.

I've used insomnia to test some queries and them check which responses did i get. Also the twitter api grants you some testing curl, so i could test the api token

The url preview used was:
https://api.twitter.com/2/tweets/search/recent?expansions=author_id&query=(jair bolsonaro OR lula OR ciro gomes OR joão doria OR simone tebet OR luciano bivar OR sergio moro OR felipe d'ávila OR andré janones OR leonardo péricles OR aldo rebelo OR eduardo leite OR eymael OR pablo marçal OR vera lucia OR sofia manzano) lang%3Apt
I was looking for each politician possible pre candidate and tweet that has the portuguese language, bringing also the author_id information


fix Plot2D position info with masks

This PR fixes the displayed information in Plot2D's PositionInfo widget when there is a mask.
This is a regression from PR #2913
closes  #3134

Nice, thanks a lot.
Works well.


misc: Bump github.com/google/go-cmp to v0.4.0

The cmp package is used in tests to compare values and generate diffs.
The newer version fixes a bug that manifests itself in the upcoming
Go 1.14.
Closes #129.

Ignoring Travis failure, tracked in #135.


decommission everything IE related

let's review and remove everything IE related. Also we have to define what we should support for Edge

Verified, fixed.


Tweaks to covid featured descriptions

Use the 16px font and halve the margin after feedback from designers.

Thanks @danacotoran 👍


Talk with Postgraphile

Hi! This project looks really interesting! I think it could be a very good fit with Postgraphile, I think you should get in touch with them to see if you can do something together! I'd love to see some unification of powers in this field!

Hey,
Thanks for your interest!
The Postgraphile team are doing wonders in the Postgres & GraphQL scene. I like their approach which is similar to ours in that it creates an API based on the existing database schema. Not sure about GraphQL part - this isn't something we're focusing at the moment. We're experimenting with the current querying API to bring in joins and nested data to hopefully expose similar functionality with less code. Saying that, we're curious to know what they think of this project.
Thanks a lot and let us know if you have more ideas!


Sprite3D and Quad in one Viewport increases CPU usage

When I create empty project and add at scene one of Sprite3D or Quad it works great and CPU usage remains normal (~2-3%):

But when I add both of them at scene, CPU usage increases to ~26%:

My platform is Windows.

Can you still reproduce this issue in Godot 1.1 or the current master branch?

Yes, problem still exist in Godot_v2.0_alpha_20150930_win64.exe. I create Quad, Sprite3D with texture and turn on Update Always in editor to reproduse the problem.

Tried this and there's a massive flood of errors in the console (couldn't copy because Windows console is awful).
When I close, the editor keeps flooding this errors:
ERROR: RasterizerGLES2::set_render_target:  Condition ' rt->fbo==0 ' is true.
At:  drivers\gles2\rasterizer_gles2.cpp:4375
ERROR: VisualServerRaster::_draw_viewport:  Condition ' desired_rect.width<=0 ||
 desired_rect.height<=0 ' is true.
At:  servers\visual\visual_server_raster.cpp:7003

Sample project: https://dl.dropboxusercontent.com/u/9300401/1262.zip

Not critical for the upcoming 2.1, so moving to the next milestone.

What's the status on this in the current master branch?


Usage of targetObject is deprecated

Was trying to fix this deprecation:
DEPRECATION: <client-web@component:dynamic-link::ember3232> Usage of targetObject is deprecated. Please use target instead. [deprecation id: ember-runtime.using-targetObject]
However, it seems that target is already being used to bind the html target attribute. So I'm not sure how to approach this one.
Personally, I think that using 'target' for the html property / binding makes more sense than using some alias. But given that Ember is now using target to mean something else.. I'm not sure what else can be done to make them coexist nicely.
Am I overlooking something? Did they overlook this case when they changed the API?
Any thoughts?
Thanks

@asross Did you ever get a chance to think about which direction to take this? I'm willing to work on a PR

Hey, thanks for the issue and your willingness to work on a PR. This is a tricky one, isn't it?
The best thing would be if we could somehow use target to get the component's target object but still allow users to pass target='_blank' when creating the component. That would keep the library totally backwards-compatible. It would be worth looking into whether that's possible.
If it isn't, then I think we should just bite the bullet and introduce another property like linkTarget which we include in attributeBindings as 'linkTarget:target' (but support both target and linkTarget in the params). So basically:
attributeBindings: ['linkTarget:target'],

linkTarget: Ember.computed('params.linkTarget', 'params.target', function() {
  return this.get('params.linkTarget') || this.get('params.target')
}),

performAction: function() {
  var target = this.get('target') || this.get('targetObject') || this.get('_targetObject');
   // ...
}

We can then remove support for the bare target property and bump the major version. Sound like a reasonable plan?

Actually, if we wanted to be really sneaky, we could check if this.get('target') is a string or not, like this:
linkTarget: Ember.computed('params.linkTarget', 'params.target', 'target', function() {
  if (typeof this.get('target') === 'string') {
     return this.get('target');
  } else {
     return this.get('params.linkTarget') || this.get('params.target');
   }
}),

performAction: function() {
  var target = this.get('target');
  if (typeof target === 'string') {
     target = this.get('targetObject') || this.get('_targetObject');
  }
   // ...
}

Then we avoid introducing a backwards incompatibility :)


Reorder config to be alphabetical & match documentation

easier to follow along if default config and documentation are in the same order

Thanks! Merged in be6c30fa2f7df4166473a5cf84c3f0decce5ead0 after fixing some trailing whitespace and commit message nits.


Optimize rtd css styles

bold font weight.
rst styles.

:tada: This issue has been resolved in version 0.0.6 :tada:
The release is available on:

v0.0.6
GitHub release

Your semantic-release bot :package::rocket:


SNAPSHOT and SERIALIZABLE isolation don't work until something is added or removed

This is a rather major bug in our transaction isolation.
Essentially if you start two transactions (on separate connections) and commit data on one of them, then you can read that data on from the other transaction.
If you add or remove that from the connection before the other one commits then everything works as expected.
I've made a proof-of-concept unit test. https://github.com/eclipse/rdf4j-storage/pull/268

This isn't necessarily a bug: rdf4j uses optimistic concurrency control, so it doesn't need to preempt against changes in the dataset even under snapshot isolation. Moreover the time the snapshot is taken is determined by the first operation, so if the commit occurred before that it's not wrong to include it. Still on holiday so haven't checked your test, if I misunderstood let me know.

If I understand your comment correctly. .begin() does not actually start an isolated transaction, but instead defers a transaction until the first get/add/remove operation. In my proposed fix we start an isolated transaction immediately inside .begin(). So any commit() called (logically) after a begin() will not be visible.
I would like to find out how PostgreSQL handles this. I couldn't find any info directly related to this kind of behaviour. So if experimental evidence shows that they've done what we've been doing all along, then it should be fine to keep going and not change anything.
You should enjoy your holiday and not worry about this.

After some testing with Postgresql it seems that their SERIALIZABLE acts the same way as ours. So I will close this issue and my PR, and instead remember to call .hasStatement(null,null,null, true) right after my .begin() to force a transaction to start.


Postman GET ServiceProviderConfig calls the "/serviceConfiguration" endpoint

From my understanding, as per the SCIM specification, the ServiceProviderConfig discover endpoint path should be
/ServiceProviderConfig, not /serviceConfiguration.
Is this a bug in the postman test?

Seconded.

Came here to create this issue :-)

Bump. We're also expecting /ServiceProviderConfig as designed. Should we cater for both endpoints as a workaround until a fix is done?
Is the request and response the same for  /ServiceProviderConfig vs /serviceConfiguration?


Implement PrimaryScrollController inside  CupertinoTabScaffold

iOS native widgets have to feature that CupertinoTabScaffold doesn't support yet.

Scroll to the top when the status bar is tapped. (This is only possible yet with material Scaffold)
Scroll to the top when the active tab inside the CupertinoTabBar is tapped again.

I would like to propose to add a PrimaryScrollController that handle both cases. The implementation would be very similar to the one in Scaffold here.
I would be able to do a PR if you are interested in implement this.

Hi @jamesblasco
Sounds like. a good idea, PRs are always welcome
Thank you

@jamesblasco, do you have any progress on this task?


replace simplemde-markdown-editor

Because simplemde-markdown-editor has not been maintained for a long time, and there is a risk of xss, it is ready to no longer be used.
Then I'll find a new markdown editor.

I will investigate it.

https://github.com/PanJiaChen/vue-element-admin/pull/1374/files


Add step_func to exp_hydro docs

Added step function found in the tests, see https://github.com/chooron/HydroModels.jl/blob/35ff1bbd24172db898c701da079d8bbbbd9d2bc7/test/run_lumped_model.jl#L1

close #2


Please consider adding an open source license

Would you consider adding a license file to this project? This would be consistent with good community practices and would allow others to build upon your work with a clear set of rules for what is acceptable.
For maximum compatibility with other free software projects, please consider using MIT license, such as expressed here:
https://github.com/intel352/vagrant-shell-scripts/blob/master/LICENSE.md
(replace the copyright statement with your copyright, of course)
If this is all indeed example code, you might consider the even less restrictive MIT-0 license, which is how Amazon licenses most of their new example code. This is like the MIT license but does not require attribution:
https://github.com/aws/mit-0/blob/master/MIT-0

You should actually put in the YEAR and COPYRIGHT HOLDER bits here too...

Thx, updated


PDF Preview broken in Insomnia 2020.4.0

Describe the bug
The response preview is empty and a error is thrown in the console.
To Reproduce
Send a GET request with a response of content type application/pdf.
Screenshots

Desktop:

OS: tested on Linux and macOS
App Version: Insomnia Core 2020.4.0

Thank you for reporting this!
INS-127

A fix to this has been released with 2020.4.1 😄


Add accessibility page

Looks like I didn't break it over in the website update.

[ ] New page
[ ] Add to footer

I was looking at an old link.
Page: https://proudlyservingbook.com/accessibility/


Limit on number of Research Outputs?

When submitting a new Research Output item (eg https://doi.org/10.1093/ve/veaa069) to the Hakai Institute Juvenile Salmon Program DMP (https://doi.org/10.48321/D1CW23) and pressing save I get a this error message in the browser:
Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request

Reason: Error reading from remote server

Apache/2.4.57 () Server at dmptool.org Port 443

I'm just wondering if I've hit a limit to the number of Research Outputs I can include (32 included so far) or if this is a bug.
Thanks!
Brett

thanks for reporting this @Br-Johnson
This happens periodically when the server is slow to respond. We are investigating the root cause.
For the short term though, if you try to submit the form again it should work.

I am unfortunately still getting this error.

Ok, thanks for updating us.
The code is making external calls to try and fetch the citation for every related identifier associated with the DMP. Some of the the response times can be a bit slow, and our load balancer is timing out which is why you see the proxy error.
We will need to make this process asynchronous so that it doesn't interfere with the page response.
 Apologies for the inconvenience

Hi @Br-Johnson we just released a patch that should address your issue. Please let us know if you continue to have any problems.

Hey @briri Thanks for this! I was able to add that new research output no problem now. However, it just shows up as "Article:  https://doi.org/10.1093/ve/veaa069  - No citation available."
Not sure if there was a bug introduced to the doi metadata service or if the doi metadata may be incompatible or corrupt on the crossref side.
However, I added a different DOI for testing purposes and it came back as a properly formatted citation.

Thanks for verifying that the page is no longer throwing a proxy error. For some reason that particular DOI does not return its citation information in a way that we can use it (an underlying library we use to extract the DOI bibtex reports an encoding error).

Thanks!


Parsing problem when file doesn't end in EOL

Running spirv-as on the attached file yields:
error: 21: 1: Invalid Opcode name 'OpCapability Shader
OpMemoryModel Logical GLSL450

%i32 = OpTypeInt 32 1
%f32 = OpTypeFloat 32
%v4i32 = OpTypeVector %i32 4
%timg = OpTypeImage %i32 2D 0 0 0 0 Unknown
%pimg = OpTypePointer Input %timg
%tfun = OpTypeFunction %i32

%vimg = OpVariable %pimg Input
%coord = OpConstant %i32 0
%bias = OpConstant %f32 0.

%main = OpFunction %i32 None %tfun
%lbl = OpLabel
%img = OpLoad %timg %vimg
%r1 = OpImageFetch %v4i32 %img %coord Offset|Bias %bias %bias
;%r2 = OpImageSampleExplicitLod %v4i32 %sample %coord Bias 0.2
OpReturnValue %coord
OpFunctionEndѷ'

IOW, it thinks the whole program is an opcode name. :scream_cat:
shader.txt

I'm surprised it doesn't stop at the first space after OpCapbility.  ?!  Hmm.

Forgot to add: if I add a newline at the end of the file, it assembles just fine.

Done via #131.

I verified it against the shader.txt file originally submitted, but with the trailing newline removed.  (Somehow it crept in?)

@dneto0 Yeah, the attached file has EOL before EOF.
@dekimir kindly shows me how to use the power of echo -n.


Set up email signup form

The email signup form currently doesn't do anything. We need to implement it's backend...which is dependent on #10 for picking a CRM system. 😬 We'll also want to add reCAPTCHA to the site to prevent sign-up spamming.

Update: per #10, we are going to move forward with SendinBlue for email marketing. See their signup form documentation.


Roots of Quadratic equation in Java [math]

🚀 Feature
Solving Quadratic equations in Java-A program that prints all real solutions to quadratic equation ax^2+bx+c=0, if discriminant is negative displays a message "roots are imaginary".
(A clear and concise description of what the feature is.)
Have you read the Contributing Guidelines on Pull Requests?
Yes.
Motivation
I would like to contribute to this project under GSSOC'21.
(Please outline the motivation for the proposal.)
Pitch
Quadratic equations are actually used in everyday life, as when calculating areas, determining a product's profit or formulating the speed of an object
(Please explain why this feature should be implemented and how it would be used.)
/assign

Can you please assign me this issue?

I would like to work on it as a part of GSSOC'21.
Can you please assign the work to me?

/assign


HA Core crashing when using this addon

I needed to stop using this awesome addon because 2 to 3 times a day, mostly in the morning and in the evening, this addon causes an HA Core crash.
I manually need to restart the core in the console.
I use the latest and greatest (non beta) version of Home Assistant
The questions are:
Does somebody else have this issues?
Is there active development going on?`
Thank you very much for any input!!

I don't see this issue at all. Do you have any logs to share?

I don't see this issue at all. Do you have any logs to share?

I concur. I'm on the latest HAOS and I've never experienced a crash with this integration.

It looks like it's got jammed into some sort of auth loop. Have you tried removing and re-adding it and double-checking your credentials? (although I presume that they are working ok the rest of the time).
Are you seeing this periodically in the logs?
2024-05-29 17:10:41.045 INFO (SyncWorker_14) [weconnect_cupra] Token expired
2024-05-29 17:10:41.045 INFO (SyncWorker_14) [weconnect_cupra] Refreshing tokens

Everything works during the day. The crash comes always in the morning, one or two times and the same happens in the evening.
To me, it looks like, when the car is not charging or moving it disconnects, which might lead to this "jamming"
I do not have checked the loga while it is working.
When it works, it's a perfect addon!

enabled the addon again to check the logs in working state
so far I got this sevceral times -> Timeout updating weconnect_cupra

Another Update
I have set up a new home assistant in Proxmox, totally virgin and installed this addon - same problems.

As it seems to be the only one to have this issue, I will close this
Thanks for the input!

I'm really struggling to reproduce this, I'm afraid. The only thing I can suggest is if you are willing to share credentials with me so I can debug directly with your car and see if I can find if there's a difference here.
Happy to leave open until we properly resolve.

thank you for the offer, but I am afraid that sharing such infos is not a good idea.. my solution now is, that I run a second proxmox home assistant installation just for this addon and connect it to my active home assistant via remote. in addition I reboot the whole cupra vm every hour ;-)


Asciidoc documentation into 2.x

The feature/documentation branch is in a position where it would provide value to appear on the elastic docs site for the 2.x client, on a progession over perfection basis. A summary of the changes:

references AsciiDoc.dll library located in src/lib/dnx451. I will put this up on github and publish to nuget to reference from there when it is good for alpha (it works for our current purposes but is limited and can only output asciidocs for the moment). This library is used to modify the asciidocs generated from literate tests to perform such actions as adding attribute entries, section titles for usage pages, etc.

The structure of the asciidocs has been verified with the docs generation process using

./build_docs.pl --doc ~/docs/asciidoc/index.asciidoc

where ~ is the project root

Corrected the spelling of some directory names in the Tests project e.g. ClientConcepts/HighLevel/Inference, and moved the files to the new directory

Tidy up and elaborated descriptions for different client options, adding cross reference links where useful

Usage examples for all Query DSL and Aggregations calls

:balloon: :tada: :fireworks: :cake:
Decent docs! Only 4 years in the making :smile:
This new documentation that'll be part of elastic.co is gonna rock! Functionally everything looks good to me to merge however I have some prerequisites before merging this into the master and 2.x integration branches.

If AsciiDoc is not in a shape you want to publish it to nuget (prerelease works too here), we need to move the source under Litterateur itself so we can iterate over it. I much rather we publish this under a new github org that we're all part of and throw it on nuget as a prerelease package though, no need to goldplate before opensourcing.

Since this is a huge feature PR, I think this needs to be resend from a new branch where you cherry-pick all the actual commits, getting rid of the merge commits, squash them to a degree that makes sense, create a single asciidoc generation commit and send a new PR. This will greatly simplify pulling it into master as well

Awesome work @russcam !

Since this is a huge feature PR, I think this needs to be resend from a new branch where you cherry-pick all the actual commits, getting rid of the merge commits, squash them to a degree that makes sense, create a single asciidoc generation commit and send a new PR. This will greatly simplify pulling it into master as well

Would just rebasing against 2.x then squashing to a single commit be the same thing?

that would not get rid of the merge commits with 2.x AFAIK

If AsciiDoc is not in a shape you want to publish it to nuget (prerelease works too here), we need to move the source under Litterateur itself so we can iterate over it. I much rather we publish this under a new github org that we're all part of and throw it on nuget as a prerelease package though, no need to goldplate before opensourcing.

Happy to release to github under an org we can all work on it on - just letting you know it's a little messy in places. Feel free to slash and burn :smile:
I'll cherry pick the commits out and squash them into one commit for the PR :+1:

Closing to open a cherry-picked PR :+1:


Flash of old prompt on enter

Issue summary
When you have a dynamic prompt (using variable) and command change that prompt, there is a flash of old prompt before the new is visible.
Expected behavior
The new prompt should render without flash
Actual behavior
There is flash of old prompt after enter
Steps to reproduce

Open demo https://codepen.io/jcubic/pen/KKYBWog?editors=0010
type cd ~/directory
type cd /

Additional notes
This is related to https://github.com/jcubic/jquery.terminal/issues/923
As a workaround, you can make the function that change the prompt async.

Fixed with #923

This is not fixed.


UP-4179:  uPortal 5 project overhault with a Gradle-based build

https://issues.jasig.org/browse/UP-4179
This is only the beginning of this work.
Please see the wiki page for this effort:  https://wiki.jasig.org/display/UPC/uPortal+5+Project+Overhaul
The complete plan is outlined there.
Tasks

[ ] Review changes to import/export to verify that pre-uP5 entity files are still importable
[ ] Leave the script attributes of existing files in src/main/data unchanged
[ ] Verify that all of the following have been thoroughly cleaned of anything org.jasig.portal...

uportal-war/src/main/java
uportal-war/src/main/resources
uportal-war/src/test/java
uportal-war/src/test/groovy
uportal-war/src/test/resources

Travis CI seems to be invoking $gradle assemble where it should be invoking $gradle install... anyone know why that is?

Coverage decreased (-0.03%) to 22.964% when pulling 4ab5fc705147fb0ad7b28fe369e191826994afe0 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.005%) to 22.985% when pulling c91a8f8d6e349c19287d7c404a94fef8569e602f on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.001%) to 22.989% when pulling a87baae1e8769ee291cc7abc4e59e4adf3f30fa2 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.001%) to 22.989% when pulling fc3f8d258b916abef996b9c461cb9493052c203e on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage increased (+0.01%) to 23.002% when pulling 6af06b637c8abd6e5a6b3122325e396d8f93501b on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage increased (+0.01%) to 23.002% when pulling 6812068a609422ebd9ad62f1c0380b3da746e635 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage increased (+0.003%) to 22.992% when pulling 6812068a609422ebd9ad62f1c0380b3da746e635 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage increased (+0.003%) to 22.992% when pulling cd93e255f3cc1cb722da5e7d4801f83fae970fc3 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage increased (+0.006%) to 22.996% when pulling 845606038c74a866d62552bd8334f236db7e28cd on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage increased (+0.0007%) to 22.991% when pulling 0e65cca33d6ea922f376b22d9dca2b415f1b82bd on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage increased (+0.003%) to 22.992% when pulling dd4624caf26fd0da8b5b529f60e259caebf4d9be on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage increased (+0.006%) to 22.996% when pulling 661efa5d42931c3229aa6a2ca783f7ca9876384f on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage increased (+0.01%) to 23.0% when pulling 661efa5d42931c3229aa6a2ca783f7ca9876384f on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.005%) to 22.985% when pulling 723661ffb9c0c7c64bc1817e4ce2de300bb06e94 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.005%) to 22.985% when pulling a0a29f5cae6761a37ddc7e307da11d08644a17ab on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage increased (+0.0007%) to 22.991% when pulling 2e3b7a8064084df2096b7e53bc123a2aca057fe2 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage increased (+0.003%) to 22.992% when pulling 2e3b7a8064084df2096b7e53bc123a2aca057fe2 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage increased (+0.003%) to 22.992% when pulling bbd6f1391fed95290a8dde24881da4b0af53bef0 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage increased (+0.0007%) to 22.991% when pulling edf11b95164fad5987b12d1c1220148f4faa664c on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.006%) to 22.984% when pulling 1389b9b5b72f253b41959dc45b6bc866cfb696b2 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage increased (+0.005%) to 22.995% when pulling 1389b9b5b72f253b41959dc45b6bc866cfb696b2 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.02%) to 22.969% when pulling a127ec9e281a3df4df013e541c0e03588dcd1c5f on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.03%) to 22.958% when pulling b1122cf89398011b424993cac6d8f30c611e060d on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.02%) to 22.967% when pulling 4bb77159ee2477427aee1c8627db24acd5fe1ae5 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.004%) to 22.986% when pulling 0a62393f977d3caab73dd316829db77ab8897fe4 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.02%) to 22.969% when pulling a6f1e9a2ae9274c4556105b7061ef5b9cd4b6208 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.03%) to 22.964% when pulling a6f1e9a2ae9274c4556105b7061ef5b9cd4b6208 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.03%) to 22.964% when pulling fbd2ffe67a67c70aec686b355503088d53d72b6e on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

I think you'll need to undo the .gradle change to .gitignore, and remove the .gradle files then once the .gradle files are gone, put the .gradle change to .gitignore back.  Otherwise everytime someone builds they will see those files as "out of date" and in need of being committed.

@holdorph is that happening to you?  (It's not happening to me.)  I don't know a lot about how the Gradle Wrapper works, but I researched the topic of what entries are typically added to .gitignore for a Gradle-based project.  I didn't think to research whether to handle .gitignore or the wrapper in a specific order.

Coverage decreased (-0.03%) to 22.956% when pulling 89019c22c069fcab3b5474abd7bc317675329b2d on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.04%) to 22.954% when pulling c17a743dbc497edd4fec2759d5861d182ffc4b78 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.008%) to 22.982% when pulling 2da66ec2fa2e3149499475de9cca09a1cc69aee7 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.002%) to 22.988% when pulling 68e59dd76828615e4ff80dfd6a7f477b3cb76e8b on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.002%) to 22.988% when pulling 542a01f56e1e028c595e46b1ef72b2dcf32b18c7 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

My comment is that right now the commits to not match the gitgnore.  you are ignoring files you have IN the repository, that's inconsistent.  One of the two things is wrong.  Either the files shouldn't be in the PR, or the line shouldn't be in the .gitinore. But putting files into the PR THEN updating the .gitignore to ignore those files, looks like an accident and mistake.  And it can have negative side effects in addition to just being plain confusing.

Coverage decreased (-0.01%) to 22.98% when pulling b5e19472b8998d0068bc304067a63d152ada275e on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.02%) to 22.969% when pulling ef24fca147e9f726c23523b41ea46c4f40202349 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.01%) to 22.98% when pulling 4c1eb4c7332ad3dcb47101947ea035ceba41aba4 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.03%) to 22.962% when pulling c5365b6ccaba64280daf54177e301aced568d631 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.02%) to 22.975% when pulling 20c20d07a8ea076b027e9c8bbc5f5eea74765fe8 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.02%) to 22.969% when pulling 01ebf39315cc3b8ea440cb9db2d53169de434f42 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.02%) to 22.967% when pulling 2c97debfa756b31bbd074074e0e52e7d77a2132d on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.006%) to 22.984% when pulling 63ab3d5c727b60448093003dcf144c8e93800951 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.01%) to 22.978% when pulling 22cd947db67e1c9d403f114fface0508c06961dc on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.01%) to 22.977% when pulling 22cd947db67e1c9d403f114fface0508c06961dc on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.01%) to 22.978% when pulling 22cd947db67e1c9d403f114fface0508c06961dc on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.004%) to 22.986% when pulling 67c8fbac53c648634e02f16108c188a8dd55e753 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.02%) to 22.973% when pulling 62085b98b7009d79ec68a7361ee89e4062e460f0 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.02%) to 22.971% when pulling 62085b98b7009d79ec68a7361ee89e4062e460f0 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.008%) to 22.982% when pulling 9b23b263d8b5980d54250f446448a96843263b83 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.02%) to 22.973% when pulling be64fbee4db8de4709e8d48b9afa24ddd2d05535 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.002%) to 22.988% when pulling d9ea1ec3d665edc972ed06f6648730c769397cfb on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

@holdorph -- I ran some tests.  Here's what I now believe...
I thought that the command $gradle wrapper would create only files that are a necessary part of the build system, but I was wrong about that.  It also generated 6 files in .gradle.  Those files don't need to be included -- they're work/temp files used by Gradle during the execution of $gradle wrapper itself (and later used by other commands).  Nothing in .gradle/ needs to be in the repo, and .gradle/ can & should be listed in the .gitignore.
I have made these changes.

Coverage increased (+0.007%) to 22.997% when pulling e945df5d0301ed0f89b24019fb39f3ff6fbce1cb on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.02%) to 22.973% when pulling 9be12f04f9cf2e0ad1cfaad1ecbf41912bd5d468 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.02%) to 22.97% when pulling 006bc48b33ca8fcc2d8f05ad89b614c2a8ef23df on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.009%) to 22.981% when pulling 85de7eb6afc2db00e91359de9cc952880231bde9 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.

Coverage decreased (-0.01%) to 22.979% when pulling 75787b826f531cc923eae3418dd01fe28b74a5d2 on drewwills:UP-4179 into c5d425de9738e73432bf4c2d066b67782495b001 on Jasig:master.


fix: syntax action.yml

:tada: This PR is included in version 1.1.2 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


Return individual pauli expected values

Many applications we don't necessarily want the sum of expected values
but a list of expected values.  the estimate_pauli_sum functionality can
be expanded in a very simple way to return the desired values by
augmenting the named tuple

@ntezak I've adjusted the name to pauli_expectations and documented more appropriately.  I also maintained consistency such that the expected value of each pauli term is returned by not only returning the moment value but the coefficient multiplied by the moment value.  I believe this is closer to the behavior that a user would expect.
For example:
if  p1 = 0.5 * sX(0) is the Pauli term then the routine now returns 0.5 * < X >


ReferenceError: structuredClone is not defined

ReferenceError: structuredClone is not defined

https://github.com/acacode/swagger-typescript-api/issues/883

Same.
Node version 18.18.0


RangeError (index): Index out of range: index should be less than 2: 2

提示此bug

Please use English to describe the bug/feature request, and include some sample code to reproduce the bug.
Feel free to reopen the issue with those changes.


Add support for devcontainer (updated)

Update devcontainer requirements to allow for a robust development environment. This should be accessible from github workspaces now too. This was tested on VSCode.

@diptanu not the cleanest and shorted commit history (I could squash them if you think it makes sense) but I think this is fine for now. We can prob merge this first then the extractors (or implement extractors straight into https://github.com/tensorlakeai/indexify-extractors


feat: mssql storage type extra #185149472

This PR is related to #1060.
It suggests a different approach to the iops and storage_type interdependency.
Instead of masking some invalid combinations from the user, let every invalid
combination fail with descriptive messages.
This PR requires a team discussion and the approval of the whole team to be merged.
Checklist:

[ ] Have you added Release Notes in the docs repositories?
[x] Have you followed the Conventional Commits specification?

Added @servicesenablement as a reviewer to prevent this PR from appearing in Slack Code Review bot messages.

Closed due to no recent activity


Javascript Syntax highlighting bug

Issue Type: Bug
If you are editing the HTML file, it’s fine.
But if you try to edit the Handlebars (.hbs) file, you will feel very bad when the problem occurs.
Reproduce Bug

Create a HTML file
Insert the following code to head tag
<script>function foo() { if ('bar' == 'bar') { return true; } } </script>
Then you will see the bug
Please observe the color of the code </script> (Closing tag)

Personal analysis
This bug will come out when } } appearing.
Syntax highlighting system can't close the block correctly.
This issue occurs after VSCode version 1.32
Expected results

Exceptional result

Support video

Please observe the color of Handlebars curly braces.
Please note the end of line 4, The } } is appearing!
Related Issues
From daaain/Handlebars#103
System Infomation
VS Code version: Code - Insiders 1.34.0-insider (daf71423252a707b8e396e8afa8102b717f8213b, 2019-05-06T22:07:35.830Z)
OS version: Darwin x64 18.0.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (4 x 3200)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: enabledrasterization: unavailable_offsurface_synchronization: enabled_onvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
3, 3, 3

Memory (System)
24.00GB (0.02GB free)

Process Argv
-psn_0_2736796

Screen Reader
no

VM
0%

Extensions (16)

Extension
Author (truncated)
Version

Handlebars
and
0.4.1

gltf-vscode
ces
2.2.5

vscode-svgviewer
css
2.0.0

vscode-eslint
dba
1.8.2

githistory
don
0.4.6

gitlens
eam
9.7.3

vscode-mysql
for
0.4.0

minify
Hoo
0.4.3

mysql-syntax
jak
1.3.1

code-beautifier
mic
2.2.1

vscode-filesize
mkx
2.1.2

vscode-language-pack-zh-hant
MS-
1.34.1

mssql
ms-
1.6.0

vsliveshare
ms-
1.0.181

material-icon-theme
PKi
3.7.0

ejs-language-support
Qas
0.0.1

Thank you for the detailed bug! I have updated the grammars and pulled in the fix for this. It will be available in an insiders build soon.


Split does not behave as it should

Hi,
I have a big DIV at my html that I'm converting this using canvas (jspdf is doing this) taking a screenshot and putting the image ate the pdf.
My code is like this:
var pdf = new jsPDF('p', 'pt', 'a4');
      pdf.addHTML(
        $('#myElement'),
        {
          format:'png',
          pagesplit: true
        },
        function(canvas) {
          console.log(canvas)
          $(window).scrollTop(scrollTop)
          pdf.save(pdfName);
        }
      );

The problem is that when I use "pagesplit = true" JSPDF split the image in some pages, it's nice! But the image becomes stretched totally disfigured.
There is some way to avoid image get stretched when using pagesplit?

I'm not sure if you're having the same issue we were experiencing, however, we found that by simply updating our scaleFactor we were able to make the final multi-page PDF display properly. Note the pdf.internal.scaleFactor = 2.25.
var pdf = new jsPDF('p', 'pt', 'letter');

pdf.internal.scaleFactor = 2.25;

pdf.addHTML(element[0], 0, 0, {
  pagesplit: true
}, function() {
  pdf.save('FieldStack-PracticeMetrics-' + new Date() + '.pdf');
});

See MrRio/jsPDF/issues/707#issuecomment-205469112

Hi there,
There's now a html2pdf example which much better supports generating documents from HTML.
Get the latest master and try:
npm install
npm start

Then visit localhost:8000/examples/html2pdf/showcase.html
Hope this works well for you :)
Many thanks,
James


Add Model3 XML comments

Proposed change

Aslo moved some code to the development apps project as this might not be needed anymore when codegen is complete
Type of change

[ ] Dependency upgrade
[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (which adds functionality to an existing integration)
[ ] Breaking change (fix/feature causing existing functionality to break)
[ ] Code quality improvements to existing code or addition of tests

Additional information

This PR fixes or closes issue: fixes #
This PR is related to issue:
Link to documentation pull request:

Checklist

[ ] The code change is tested and works locally.
[ ] Local tests pass. Your PR cannot be merged unless tests pass
[ ] There is no commented out code in this PR.
[ ] I have followed the [development checklist][dev-checklist]
[ ] The code compiles without warnings (code quality chek)
[ ] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated for www.home-assistant.io

Codecov Report

Merging #470 (d166014) into remodel (36aaa9c) will increase coverage by 9.51%.
The diff coverage is 86.66%.

@@             Coverage Diff             @@
##           remodel     #470      +/-   ##
===========================================
+ Coverage    68.20%   77.71%   +9.51%
===========================================
  Files           15       11       -4
  Lines          195      184      -11
  Branches        21       23       +2
===========================================
+ Hits           133      143      +10
+ Misses          51       30      -21
  Partials        11       11

Flag
Coverage Δ

unittests
77.71% <86.66%> (+9.51%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...odel3/NetDeamon.Model3/DependencyInjectionSetup.cs
54.54% <ø> (ø)

src/Model3/NetDeamon.Model3/Entities/Entity.cs
66.66% <ø> (ø)

...del3/NetDeamon.Model3/Entities/EntityExtensions.cs
0.00% <0.00%> (ø)

...rc/Model3/NetDeamon.Model3/Entities/EntityState.cs
76.92% <ø> (ø)

...del3/NetDeamon.Model3/Internal/ExtensionMethods.cs
58.33% <ø> (ø)

...rc/Model3/NetDeamon.Model3/Entities/StateChange.cs
96.29% <100.00%> (+0.84%)
:arrow_up:

...amon.Model3/Internal/AppScopedHaContextProvider.cs
73.33% <100.00%> (+5.33%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 36aaa9c...d166014. Read the comment docs.


[Feature] RDMA support for distribued Tensorflow

Tensorflow paper (http://arxiv.org/pdf/1605.08695v1.pdf) states that Tensorflow supports multiple communication protocols such as gRPC over TCP, and RDMA over Converged Ethernet. Current repo, on the other hand, only has gRPC implementations.
Do you have any plan to introduce RDMA support? It should be beneficial especially for GPU-to-GPU communications across servers.

I'm reading distributed tensorflow code recently, hope I can give a help.

The only concern of external contribution of adding RDMA support is whether Google will release its own implementation in the future, which will render external effort less meaningful.
Can we have a member in the TF team confirm that it will not be open sourced, at least not recently?

There's some DMA-related code in open-source TensorFlow, @poxvoculi probably knows how far it is from being usable to do RDMA in open-source

RDMA for open source TF is an issue that's starting to get some attention from the TF team, though I can't yet predict timing for a solution.  gRPC is not likely to be extended in the necessary way, and the internal system referred to in the cited paper is not suitable for open sourcing.  Presumably if you are interested in this problem, you're already using a cluster with GPUs and RDMA capable networking.  If so,  would you mind saying what kind of rpc/networking you're using on that cluster?

One possible way to leverage RDMA is to use MPI version of TensorFlow which is available with Machine Learning Toolkit on Extreme Scale (MaTEx): https://github.com/abhinavvishnu/matex

I've only had a quick look but it seems rather ad-hoc (implemented in MPI-Python and run single-node TF in it). Plus it is certainly not the same as what appears in the TF paper. I believe what we are talking about would be a truly remote API that support sync/async communication and send/recv graph partitioning, or pretty much everything in the current gRPC runtime.

OK. Actually mpi-python will provide better performance than gRPC because
MPI can use high speed interconnect. Can you be more specific as to how it
is different than the TF paper? Does gRPC support collective operations?
send/recv with parameter server will not work for more than a few compute
nodes.
On Tue, Oct 18, 2016 at 8:13 AM, Bairen Yi<EMAIL_ADDRESS>wrote:

I've only had a quick look but it seems rather ad-hoc (implemented in
MPI-Python and run single-node TF in it). Plus it is certainly not the same
as what appears in the TF paper. I believe what we are talking about would
be a truly remote API that support sync/async communication and send/recv
graph partitioning, or pretty much everything in the current gRPC runtime.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/issues/2916#issuecomment-254538689,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGMD7zysqQZuOkq8epf83zCmmiRsiQw8ks5q1OItgaJpZM4I35Qd
.

--
Abhinav Vishnu
Research Scientist
Pacific Northwest National Lab
Richland, WA 99352

Basically explicit messaging needs to be handled by MPI users, while the interface provided by TF is higher (i.e. node placement for model parallelism) and the design of send/recv node makes it compatible with single-device graph execution.
Please refer to section 3.2 of the TF white paper for details.

Is the RdmaSession the correct way to go for the RDMA support? We're also investigating the RDMA solution.

MPI is the way to go for RDMA support on compute clusters - this is the most common setup. There is also RDMA versions of Hadoop/Spark/Hbase. So the data side is distributed. As for the distributed learning, TF is behind CNTK - which runs on MPI and thus has RDMA for free. gRPC is dead end.

Google is planning to transition to gRPC for all internal networking, so it's not a dead-end in terms of development. Also, I've been told by Baidu ML people that they have to maintain their own fork of MPI because the official one has bugs.

There have been message passing and distributed object architectures for ever. Every ten years or so we re-invent. Corba to stateless DCOM to n-th iteration of message queuing. What alphabet runs is their business choice - but does not reflect the HPC community. If there is a convergence that happens between distributed learning and distributed data - it will have to take into account investments people made. Infiniband ran 10 Gbps  low-latency networking 16 years ago and has over 80% market share in compute clustering world. The only logical explanation is to defend its own cloud.

@yaroslavvb Indeed, as @avader906 implied, MPI is a standard API (http://mpi-forum.org/) with many implementations.  According to this paper, Baidu uses MVAPICH2, which has GPUdirect support.  I'll hazard a guess that the bugs they see are related to GPUdirect and may in fact be performance defects, rather than functional correctness issues.
In any case, please do not create FUD about MPI.  No MPI implementation is perfect, and some are better than others.

Thinkgs are moving fast - last time i looked and mvapich2 did not support infiniband and now we talk about GPUdirect. @jeffhammond and @yaroslavvb are the two people who's contribution to get TF on RDMA would be invaluable. Seems MPI provides what we need today while gRPC might get there with time. What would be architectural and API choices to make sure TF could be compiled and run on both ?

@jeffhammond and @yaroslavvb are the two people who's contribution to get TF on RDMA would be invaluable.
TF does not scale beyond one host only in the multiple node / multiple GPU distributed learning environment. Just look at the calculation bandwidth that is now possible:
https://devblogs.nvidia.com/parallelforall/benchmarking-gpudirect-rdma-on-modern-server-platforms/
MPI provides what we need today while gRPC might get there with time. What would be architectural and API choices to make sure TF could be compiled against both ?

I would like to join in -- if possible. We have been identifying minimal
changes in TF runtime to support MPI based parallelism in the optimizer
class. We expect the implementation to be ready in a few weeks.
Please let me know, if you would like to discuss this further.
Sincerely,
:- Abhinav
On Sun, Jan 29, 2017 at 2:47 AM, avader906<EMAIL_ADDRESS>wrote:

@jeffhammond https://github.com/jeffhammond and @yaroslavvb
https://github.com/yaroslavvb are the two people who's contribution to
get TF on RDMA would be invaluable.
TF does not scale beyond one host only in the multiple node / multiple GPU
distributed learning environment. Just look at the calculation bandwidth
that is now possible:
https://devblogs.nvidia.com/parallelforall/benchmarking-
gpudirect-rdma-on-modern-server-platforms/
MPI provides what we need today while gRPC might get there with time. What
would be architectural and API choices to make sure TF could be compiled
against both ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/issues/2916#issuecomment-275906182,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGMD7xpjB6-dsmuZWxZzMIDXJfRxeob3ks5rXG4ngaJpZM4I35Qd
.

--
Abhinav Vishnu
Research Scientist
Pacific Northwest National Lab
Richland, WA 99352

@avader906 Some numbers/concrete performance goals would be useful here. IE, what is an important application, how fast is it now in TF GRPC, how fast is it in competing implementation?
Note that there are two use-cases -- using distributed TensorFlow on public cloud, and using TensorFlow on dedicated compute clusters. Existing TF is optimized for the public cloud case because that's what compute at Google is like -- CPU and network resources are shared among many competing users, so there's variability in communication/computation performance across workers, and individual workers can die without warning. At OpenAI we use distributed tensorflow to train RL agents like this on public cloud providers and the robustness to worker slowdowns/restart is an important feature.
The "dedicated compute cluster" scenario is somewhat alien to Google, so this would need community to help define goals/requirements.
It seems @abhinavvishnu has done some work on integrating MPI. For a brief glance at the matex repo, it seems the approach is well-supported by current TF abstractions -- using session.run to do the computation, then using MPI for data transfers. I've done some preliminary investigation of the extra overhead introduced by session.run and it seems it can be reduced by 50% by using TF_SessionRun (easy), and possibly another 50% by removing the memory copy (harder)

@yaroslavvb are you google employee ? I can understand the commercial nature of an effort to limit the platform development in the direction of increasing CPU loading available to individual users. After all idle CPU could be resold to another. But that conversation does not belong here. Different users have different needs - amazon and msft both offer HPC cloud.
TCP/IP - by design, is not a high performance shared resources interconnect. And CPU - by design is not a vector algebra optimized processing unit. Neither are suited for the computation type tasks Tensorflow is built to solve. This is similar to engineering a high horse power car and giving it crappy tires - and being in the business of selling tires.
Let's examine order of magnitude numbers on equivalently priced reference hardware - Haswell E  / Intel MKL and Kepler generation GPU / CUDA.
A medium sized DNN is 1000 PFlops total training these days. Let's assume that the architecture of the underlying NN is enough to consumer multiple FDR streams of data to 4 hosts with 4 GPUs. I interchange the use of infiniband and RDMA from here on.

LINPACK as benchmark, dual Haswell E CPU is ~320 GFlops and single Kepler based GPU is ~2TFlops. In practical terms - training DNN - the speedup is x10. More speedup for CNN. It is possible to use GPUDirect and get 20-30% more performance on top. The latest generation of GPUs double that again.

From the storage point of view - it is possible to deliver 10 Gbytes per second data stream to one or many hosts over the network. FDR infiniband will give you ~6 Gbytes per second. This is enough to saturate a single host and one GPU. It is certainly possible to stream 6Gbytes per second to 4 hosts.

Limits on multiple GPUs - single host are due to PCI bus, latencies and GPU memory capacity. Let's say effective 10 GBytes per second PCI-E 3.0 - and (in practical terms) 4 Kepler GPUs. In practice, this setup can not be saturated by 6GBytes per second of data (both because of GPU latencies and lanes bandwidth).

In terms of multiple hosts, we need to decide on on the interconnect. 1 Gbit ethernet is 120Mbytes of data, 10 GbE is ~1Gbyte. From the bandwidth perspective - ethernet is a bottle neck. In practice, the limiting factor is not the bandwidth but the latencies between the network, CPU and GPU. On paper infiniband here is x25 better than 10GbE. In practical terms, measuring with IOPS on a fixed block size - FDR is roughly x4 better. The latency issue would limit the total number of hosts it would be possible to scale out calculations to.

Single Host, dual CPU: ~3125 hours

32 dual CPU hosts: If the best case scenario on paper is 98 hours, with 10GbE 390 hours. This is of course absolutely unrealistic even is calculation scales beyond 16 hosts. In practice numbers would be much worse both in absolute and in difference - order of magnitude 200 hours with infiniband and 1200 hours with 10GpE.

4 Hosts, 4 GPUs : 31 hours best case scenario with infiniband. Limiting infiniband to IPoIB - no RDMA it would be roughly x4 worse. With 10GbE ~x6 or 188 hours. Actual scenario depends on the software as much as on hardware - scalability is not linear. Realistic numbers would be 48 hours for RDMA enabled interconnect vs 192 hours 10GbE.

There is still potential to scale beyond 4 hosts infiniband combination - but not with ethernet. This is particularly interesting for many hosts - 1 GPU configuration.

In summary, the numbers would be >390++ hours for a cluster of 32 dual CPU hosts vs 4 hosts 4 GPUs 48 hours (with RDMA) vs 192 hours 10GbE.
Using RDMA, RDMA aware MPI and computation engine that accepts MPI (CNTK) - it is possible to train the above network in 4x4 configuration in under 24 hours (Pascal GPU and RDMA).
Infiniband now has EDR (and HDR coming) increasing horizontal scalability further.

@avader906 contributions are welcome in this area. One starting point might be evaluating @abhinavvishnu 's approach for combining TensorFlow and MPI and identifying/removing bottlenecks

@yaroslavvb  I've linked the 2 week old study in my prior post. The kit to replicate and tests results are at http://dlbench.comp.hkbu.edu.hk/. In multi host environment TF is unusable - seems I am wasting my breath here.

@avader906 Thanks for the link. Note that the study compares CNTK toolkit which uses MPI to distribute to multiple GPUs, to single-machine TensorFlow which uses direct GPU->GPU transfers. The 3.31x speedup they get on CIFAR resnet50 using 4 GPUs suggests that MPI is being quite efficient. Not sure what's going on with single-machine TF getting only 1.65x scaling on 4x GPUs, that would need some investigation

@avader906 I'm not going to wade too far into the MPI vs TCP/IP or Ethernet vs InfiniBand debates, other than to say that the real advantage of MPI is the ability to target any of these technologies and more while outsourcing the low-level performance optimization to someone else (who is usually an expert).  For example, IBM used MPI when running deep learning on their Blue Gene/Q system [1] and my Intel colleagues used MPI when running the same code across AWS and a Cray XC supercomputer [2].

Parallel Deep Neural Network Training for Big Data on Blue Gene/Q
Distributed Deep Learning Using Synchronous Stochastic Gradient Descent

@jeffhammond There is no debate. Questions where asked why this (RDMA) feature is important and what could be improved in TF / gRPC.
Detailed technical argument requires networking and distributed systems design knowledge - not a requirement per say to code TF and meet clearly articulated users' needs.
There are now sufficient references in this thread - industry use cases, single host benchmarking and estimates of gains in distributed environment to focus on delivering the feature.
Some more introductory insights into technical aspects could be inferred from here:
cuda-aware 2 node MPI benchmarking:
https://devblogs.nvidia.com/parallelforall/benchmarking-cuda-aware-mpi/
GPUDirect on RDMA
https://devblogs.nvidia.com/parallelforall/benchmarking-gpudirect-rdma-on-modern-server-platforms/
Patiently waiting for updates from @abhinavvishnu and wish him and hist team all the best

Thanks for the detailed discussion.
We are currently making code changes in the TF runtime. The reason we have
a memcpy at this point is because we had issues with pyfunc not working
correctly for all versions. More as soon as we have updates.
Sincerely,
:- Abhinav
On Mon, Jan 30, 2017 at 2:33 AM, avader906<EMAIL_ADDRESS>wrote:

@jeffhammond https://github.com/jeffhammond There is no debate.
Questions where asked why this (RDMA) feature is important and what could
be improved in TF / gRPC.
Detailed technical argument requires networking and distributed systems
design knowledge - not a requirement per say to code TF and meet clearly
articulated users' needs.
There are now sufficient references in this thread - industry use cases,
single host benchmarking and estimates of gains in distributed environment
to focus on delivering the feature.
Some more introductory insights into technical aspects could be inferred
from here:
cuda-aware 2 node MPI benchmarking:
https://devblogs.nvidia.com/parallelforall/benchmarking-cuda-aware-mpi/
GPUDirect on RDMA
https://devblogs.nvidia.com/parallelforall/benchmarking-
gpudirect-rdma-on-modern-server-platforms/
Patiently waiting for updates from @abhinavvishnu
https://github.com/abhinavvishnu and wish him and hist team all the best
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/issues/2916#issuecomment-276028310,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGMD7yt4va4i5cGSME_KlSNxQazUL-pbks5rXbx1gaJpZM4I35Qd
.

--
Abhinav Vishnu
Research Scientist
Pacific Northwest National Lab
Richland, WA 99352

@abhinavvishnu are you modifying C++ core runtime (ie files like executor.cc) or just the Python parts? Changes to core runtime would take significant effort to integrate since they touch everything. Modifying python parts and compiled code loaded through tf.load_library mechanism are much easier to integrate.

We are starting with Python. Our objective is to minimize changes to C++,
but we may have to. We will keep you posted of some of the decisions!
Thanks,
:- Abhinav
On Mon, Jan 30, 2017 at 4:49 PM, Yaroslav Bulatov<EMAIL_ADDRESS>wrote:

@abhinavvishnu https://github.com/abhinavvishnu are you modifying C++
core runtime (ie files like executor.cc) or just the Python parts?
Changes to core runtime would take significant effort to integrate since
they touch everything. Modifying python parts and compiled code loaded
through tf.load_library mechanism are much easier to integrate.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/issues/2916#issuecomment-276239884,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGMD708n0OAKJJQck4RiMOeOUn4WwtUjks5rXoUpgaJpZM4I35Qd
.

--
Abhinav Vishnu
Research Scientist
Pacific Northwest National Lab
Richland, WA 99352

@abhinavvishnu what is the ballpark overhead / performance penalty of python route vs refactoring transport architecture dependency in core ? 20% ? 40%?
@yaroslavvb what are unit tests for gRPC dependencies in the repository ? ease of integration and various ugliness of same nature should never be a development objective. what is your estimate for refactoring ?

Does anybody has a neural net that benefits significantly from fast networking (e.g. infiniband, etc)?
I played with the vgg model from https://github.com/tensorflow/models/tree/master/slim. I compared two cases: (1) single-node-single-gpu, (2) 1-worker-1-ps, where the worker is on a GPU node and the parameter server is on a CPU node. In both cases, I used batch size 32 and I saw almost identical training speed (i.e. sec/step). If communication was bottleneck, I should see a lot slower with the worker/ps configuration.
I could not run more than one workers with slim/vgg. I got out-of-memory error on the chief worker (I was using Nvidia K80 with 12GB memory).
If anyone knows a good model that runs on multiple nodes and shows potential speedup with faster networking, I would like to know.
Thanks.

@junshi15 there will be no speedup training on two threads - one CPU another GPU. compute time will run at CPU which is the bottle neck - GPU will finish and remain idle.
You need to test on the machine with 2 GPUs. TF speedup will be minimal (https://github.com/Microsoft/CNTK/raw/master/Documentation/Documents/PerformanceChart.png)
Benchmark pages are http://dlbench.comp.hkbu.edu.hk/ (very recent) and https://github.com/Alexey-Kamenev/Benchmarks (rather old).
RDMA will allow to distribute CPU computations and scale the practical node size beyond 4-5 nodes. In terms of distributed (over the network) learning with GPUs - RDMA is necessary to scale beyond a single node to saturate current generation cards.

@avader906 Thanks for your informative reply.
I have no doubt that high-speed interconnection helps in a multi-node setting. We see it with Caffe, more precisely CaffeOnSpark since Caffe does not go beyond single node. I however have yet to see it with Tensorflow.
The chart you provided "PerformanceChart.png" does not scale to more than 1-node for tensorflow. The Alexey-Kamenev tensorflow benchmark  shows only 1-node-4-gpu case. I do not see multi-node-multi(or single)-gpu settings in dlbench web page either (or maybe I missed it).
I was not expecting speed-up in the 1-worker-1ps case, instead I was hoping to see slow-down compared to training the same VGG on a single GPU. But to my supprise, I see more or less the same speed.

@junshi15 Sorry, but I do not understand the purpose of your test and how does it relate to RDMA. If you want to test scalability - run TF on two GPUs on the same node and compare it with other kits. This is the absolute performance you can get regardless the interconnect used.
Regarding Hadoop/Spark - are you running builds supporting RDMA in infiniband environment? What order of speedup have you seen from moving away from ethernet?

@avader906 Let's say I want to train a model with 32 GPU's. The maximum number of GPUs I can cram in a single box is 8. So I end up with 4 nodes. Then I connect the nodes with 1Gbps ethernet (those are all I have at this moment).  I launch the distributed version of Tensorflow, start training. It may take weeks to finish. I am not happy. Let's say I can not change the neural nets to reduce the computation. My next step may be upgrading ethernet cards to those shiny infiniband cards. I then somehow need to get tensorflow to work with inifiniband, maybe with help from this thread.
Now before I invest in infiniband, I would like to know if the upgrade has any impact in my training. My VGG example, albeit artificial,  shows there is no need to upgrade the network for that particular case, since even with ethernet, my 1-worker-1-ps is as good as single-gpu, the best one can get.
Yes, CaffeOnSpark, https://github.com/yahoo/CaffeOnSpark, supports RDMA if you build with infiniband flag on and running in GPU mode. We see 2x improvement in speed although this  depends on a lot of settings.

This seems to be model specific, for instance https://github.com/rafaljozefowicz/lm becomes 8x slower if you use 8 1-GPU machines with 1Gbps connectivity compared to 8 GPUs in a single process.

@junshi15 x2 improvement is only from IPoIB ? Have you compiled / used RDMA aware versions of Hadoop and Spark? In terms of your test - it says nothing about multinode / multi-GPU environment and whether your setup is sufficient. You may have to invest into refining the test further.
@yaroslavvb That is to be expected given the overhead in communication / gradient exchanges and the obvious connectivity bottleneck. How loaded are GPUs ? I would support your conclusion if GPUs are saturated at 100% - but they are idle as NICs struggle.
To simplify to the extreme. Anyone here has a PC they play games on? Imagine if you put NVIDIA GTX card you use to another PC - and then forward all requests via the game engine to that other PC and fetch results back. What do you think will happen if you use TCP-IP ? What will happen if you use RDMA/infiniband ? What would happen if you link with PCI bridge and respective cables ?

Chainer folks claim that they are 5.5 times faster than TF in the distributed environment (128 GPUs, Resnet-50):
http://chainer.org/general/2017/02/08/Performance-of-Distributed-Deep-Learning-Using-ChainerMN.html
I think it is mostly because of RDMA/InfiniBand (MXNet and CNTK are doing much better than TF most likely because of it).

Chainer is showing results for ResNet-50, which is much easier to scale the
AlexNet/GoogleNet. They are using MPI based implementation as well. So it
is pretty good, but I am not sure, if they are doing any other
optimizations such as asynchronous communication, layer-wise etc.
:- Abhinav
On Thu, Feb 9, 2017 at 6:10 AM, Yaroslav Goncharov<EMAIL_ADDRESS>
wrote:

Chainer folks claim that they are 5.5 times faster than TF in the
distributed environment (128 GPUs, Resnet-50):
http://chainer.org/general/2017/02/08/Performance-of-
Distributed-Deep-Learning-Using-ChainerMN.html
I think it is mostly because of RDMA/InfiniBand (MXNet and CNTK are doing
much better than TF most likely because of it).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/issues/2916#issuecomment-278612491,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGMD7ydCkSmF_Y25cG7eo53dms3EHP94ks5ravQxgaJpZM4I35Qd
.

--
Abhinav Vishnu
Research Scientist
Pacific Northwest National Lab
Richland, WA 99352

We recently released a package called TensorflowOnSpark (https://github.com/yahoo/tensorflowonspark), which includes a RDMA implementation for tensorflow (https://github.com/yahoo/tensorflow/tree/yahoo/tensorflow/core/distributed_runtime/rdma).
The RDMA implementation is not based on MPI, but rather based on ibverbs C++ API. We keep the GRPC protocol for cluster setup, graph exchange, etc, but replace all the tensor send/receive with RDMA write. You can find more info in the reame file (https://github.com/yahoo/tensorflow/blob/yahoo/tensorflow/core/distributed_runtime/rdma/rdma_readme.md).
While training large networks like VGG_19, we saw 2x faster on infiniband than GRPC on ethernet.  The improvement on inception_v3 was found limited, maybe less than 10% improvement for a 2-node cluster, a bit more for a 4-node cluster.

Please checkout this RDMA enhancement of TensorFlow mentioned by @junshi15. You could use it independent of TensorFlowOnSpark.
It is designed to work in a cloud setting, where a set of nodes are dynamically allocated.
That's why we avoid MPI option.

@anfeng What specific issues do you see with using MPI in a cloud setting?
MPI has supported dynamic process management since version MPI 2.0, which was released in 2003.  Granted, high-quality support for functions like MPI_Comm_spawn_multiple has not always been widely available, but that is only because the majority of MPI users do not care about that feature set (because they are using MPI in a static resource environment).
Dynamically subtracting nodes from MPI jobs is a slightly more complicated issue than adding nodes, but this is intimately related to fault-tolerance activities that are of great interest to many in the MPI community right now.
MPI-in-the-cloud proof points include:

A friend of mine has enabled MPICH to work with Apache YARN as described here.
Mesos appears to support MPICH via this project.
AWS supports MPI as described here.
MPI plus Hadoop is described by Intel here.

One of the advantages of using MPI is that you can reuse a wide range of numerical linear algebra software from the HPC community, e.g. CTF achieves close to 50% of peak on 1000+ node supercomputers (details) for tensor operations.  I'm not aware of any distributed-memory deep learning frameworks that can do this yet.
Disclaimer: I work for Intel and was involved in two of the aforementioned efforts (which two should be obvious within two clicks).

Let them stare on to shadows. Everything in that thread - including
theoretical speedup from various interconnect / distributed computing stack
combinations can be calculated with a piece of paper. Latencies are known
at every point and so is bandwidth. Scalability factors could be
approximated from various benchmarks around there. If you give people
numbers and they resist, the issue is something else. There are multiples
of alternatives to TF - it was not the first and not the last and is
fundamentally flowed from the bottom of architecture up.
On Tue, Feb 14, 2017 at 1:44 AM, Jeff Hammond<EMAIL_ADDRESS>wrote:

@anfeng https://github.com/anfeng What specific issues do you see with
using MPI in a cloud setting?
MPI has supported dynamic process management since version MPI 2.0
http://mpi-forum.org/docs/mpi-2.0/mpi2-report.pdf, which was released
in 2003. Granted, high-quality support for functions like
MPI_Comm_spawn_multiple
https://linux.die.net/man/3/mpi_comm_spawn_multiple has not always been
widely available, but that is only because the majority of MPI users do not
care about that feature set (because they are using MPI in a static
resource environment).
Dynamically subtracting nodes from MPI jobs is a slightly more complicated
issue than adding nodes, but this is intimately related to fault-tolerance
activities that are of great interest to many in the MPI community right
now.
MPI-in-the-cloud proof points include:

A friend of mine has enabled MPICH to work with Apache YARN as
described here
http://lists.mpich.org/pipermail/devel/2016-July/000717.html.
Mesos appears to support MPICH via this project
https://github.com/mesosphere/mesos-hydra.
AWS supports MPI as described here
https://cyclecomputing.com/running-mpi-applications-in-amazon-ec2/.
MPI plus Hadoop is described by Intel here
https://software.intel.com/en-us/articles/intel-mpi-library-supporting-the-hadoop-ecosystem
.

One of the advantages of using MPI is that you can reuse a wide range of
numerical linear algebra software from the HPC community, e.g. CTF
https://github.com/solomonik/ctf achieves close to 50% of peak on 1000+
node supercomputers (details
https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-143.html)
for tensor operations. I'm not aware of any distributed-memory deep
learning frameworks that can do this yet.
Disclaimer: I work for Intel and was involved in two of the aforementioned
efforts (which two should be obvious within two clicks).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/issues/2916#issuecomment-279570898,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVoAWGhhd_fa8Szyo3DZLsmURlFplg5wks5rcPjngaJpZM4I35Qd
.

@junshi15 Could this difference caused by this issue: https://github.com/tensorflow/tensorflow/issues/6116?

@llhe I think there are two causes. First, infiniband RDMA is faster than Ethernet. Second, the problem you highlighted in issue #6116. Our work was based on TF 0.12.1, the new GRPC patch was not applied.

@junshi15 I am very interesting to test out your RDMA implementation. However I see difference only on C++ part; did you provide any interface for Python API users to use your RDMA implementation?

@byronyi A quick instruction is here. Please post specific questions over there so we don't pollute this thread. Thanks.

It says hybrid protocol is not supported, and I wonder if that is something we could work on. Traces in current TF here and there suggests that hybrid protocol is supported by the original TF in Google, yet these facilities are not used in your implementation.

@byronyi "Hybrid" means some of the nodes in the cluster are connected with Ethernet and others are with Infiniband. We have not found such a use case. If you think that's something interesting to you, feel free to extend the code.

Rather I believe such deployment is not uncommon, given Ethernet has been the mainstream interconnect for commodity data centers for over a decade, and it takes time and effort for IB to completely replace it, if at all.
Nevertheless, this patch is really interesting to me and I appreciate your help towards the final adoption of RDMA into TF.
A rather personal request: would you mind drop me a line at my email so we could have a chat? I cannot find your contact anywhere else online.

S-Caffe state of the art implementation details - including CUDA IPC / NCCL, GPUDirect RDMA  in the context of hybrid MPI + CUDA RDMA aware application using 160 GPU multi-host system.
http://dl.acm.org/citation.cfm?id=3018769

someone made a PR to add MPI interface -- https://github.com/tensorflow/tensorflow/pull/7710

Baidu Research All-Reduce MPI patch https://github.com/baidu-research/tensorflow-allreduce
http://www.tomshardware.com/news/baidu-svail-ring-allreduce-library,33691.html

I has a distributed tensorflow case which has 2 workers, but the speed up is only near 1. I don't know if it is related with this issue you discussed. Can you have a look?
http://stackoverflow.com/questions/42500739/between-graph-replication-of-ptb-rnn-model-is-slower-than-single-gpu-version

I guess it depends on the model and how much the computation part is VS the
network part of the model.
Can u elaborate about the application/model/network being used ?
On Tue, Feb 28, 2017 at 7:39 AM, kaizhigaosu<EMAIL_ADDRESS>wrote:

I has a distributed tensorflow case which has 2 workers, but the speed up
is only near 1. I don't know if it is related with this issue you
discussed. Can you have a look?
http://stackoverflow.com/questions/42500739/between-
graph-replication-of-ptb-rnn-model-is-slower-than-single-gpu-version
http://url
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/issues/2916#issuecomment-282947494,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVPgz8aN30NBFHj6Wqc0DHUzovjtmUKfks5rg7MngaJpZM4I35Qd
.

--
Ido

Hi All:
We have checked in an initial support for distributed TF, such that the
changes for distributed memory are abstracted from the user. The code is
available at:
https://github.com/abhinavvishnu/matex/tree/master/src/deeplearning
Please find the documentation at https://github.com/abhinavvishnu/matex/wiki
We have tested it on GPU clusters and CPU clusters.
To do:

multi-GPU support
Keras integration
A document which describes our changes.

Thanks, please let us know if you have any questions.
Sincerely,
;- Abhinav
On Tue, Feb 28, 2017 at 4:37 AM, Ido Shamay<EMAIL_ADDRESS>wrote:

I guess it depends on the model and how much the computation part is VS the
network part of the model.
Can u elaborate about the application/model/network being used ?
On Tue, Feb 28, 2017 at 7:39 AM, kaizhigaosu<EMAIL_ADDRESS>wrote:

I has a distributed tensorflow case which has 2 workers, but the speed up
is only near 1. I don't know if it is related with this issue you
discussed. Can you have a look?
http://stackoverflow.com/questions/42500739/between-
graph-replication-of-ptb-rnn-model-is-slower-than-single-gpu-version
http://url
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/tensorflow/tensorflow/issues/
2916#issuecomment-282947494>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AVPgz8aN30NBFHj6Wqc0DHUzovjtmUKfks5rg7MngaJpZM4I35Qd>
.

--
Ido
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/issues/2916#issuecomment-283027829,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGMD779fbceq-W4fGBc3Jv7zB1xHGVJ9ks5rhBTsgaJpZM4I35Qd
.

--
Abhinav Vishnu
Research Scientist
Pacific Northwest National Lab
Richland, WA 99352

We created a PR #8943 to enable RDMA based distributed training on TensorFlow about 2 weeks ago. This PR was merged into master yesterday with help from TensorFlow team.
Please give it a try. We welcome your feedbacks.

@anfeng where are the benchmarks?

We (@bkovalev and me) did some testing on the new verbs code VS the default gRPC over TCP.
Some of the results in - https://docs.google.com/spreadsheets/d/1UIqmp5sKwPnxWpZkJ1rCcGrJz-Iqr4_1NZdZdRqJ7N8/pubhtml.
You can see there up to ~25% improvement with verbs in Inception-V3 (with only 14GPUs K40 in 7 nodes) and good results in VGG-16 case, where TCP can hardly get it running.
The TCP issue is caused by a 100% CPU utilization on the workers cores sending the tensors (~5Gbit/s parameters/gradient vectors), we tried some optimizations (TCP tunings, IRQ affinity methods) but nothing helped to this moment (we are still working to tune performance in this case.
We are working to extend the scale and optimize the verbs code even further.
Thanks @junshi15 @anfeng for the excellent code contribution.

@shamoya On what network (IB or RoCE, link speed) are you performing the testing?

@shamoya Is that possible that maybe your Test about TCP is actually run over ipoib ?

@thinxer @jcf94
TCP results are from 100GE network.
The RDMA test ran on IB (EDR) network.
We are starting soon a new cycle with P100 (PCIe) GPUs and RDMA running on RoCE (same 100GE network as TCP).

@shamoya one-for-one on the hardware side, RoCE will give back that 25% vs pure IB. what about GPUdirect over RDMA - is that something in the pipeline?

Hi @avader906,
RoCE V2 penalty VS IB EDR is around 8%, this is from the same machines I ran the tests:
ib_write_bw -s 8388608 -d mlx5_1 --report_gbits <IP_ADDRESS>
                RDMA_Write BW Test

Dual-port       : OFF          Device         : mlx5_1
Number of qps   : 1            Transport type : IB
Connection type : RC           Using SRQ      : OFF
TX depth        : 128
CQ Moderation   : 100
Mtu             : 4096[B]
Link type       : IB
Max inline data : 0[B]
rdma_cm QPs     : OFF
Data ex. method : Ethernet
local address: LID 0x0b QPN 0x01e9 PSN 0xfe065 RKey 0x0ce502 VAddr 0x007f01ab331000
remote address: LID 0x0c QPN 0x01d3 PSN 0x4347ae RKey 0x0351af VAddr 0x007fe4e5351000
#bytes     #iterations    BW peak[Gb/sec]    BW average[Gb/sec]   MsgRate[Mpps]
8388608  5000             99.11                       99.00                           0.001475
ib_write_bw -s 8388608 -d mlx5_0 -x 0 --report_gbits <IP_ADDRESS>
                RDMA_Write BW Test

Dual-port       : OFF          Device         : mlx5_0
Number of qps   : 1            Transport type : IB
Connection type : RC           Using SRQ      : OFF
TX depth        : 128
CQ Moderation   : 100
Mtu             : 1024[B]
Link type       : Ethernet
GID index       : 0
Max inline data : 0[B]
rdma_cm QPs     : OFF
Data ex. method : Ethernet
local address: LID 0000 QPN 0x016b PSN 0x1833eb RKey 0x002d9c VAddr 0x007f12498bd000
GID: 254:128:00:00:00:00:00:00:126:254:144:255:254:32:230:120
remote address: LID 0000 QPN 0x016b PSN 0xa4b427 RKey 0x00962b VAddr 0x007f79e76f3000
GID: 254:128:00:00:00:00:00:00:126:254:144:255:254:32:232:60
#bytes     #iterations    BW peak[Gb/sec]    BW average[Gb/sec]   MsgRate[Mpps]
8388608  5000             91.57                       91.57                           0.001365
25% is only on the Inception case (and tested on small scale - potentially more with larger scale), with VGG (which is much harder to scale) it's uncomparable improvement for now (gRPC TCP is literally unusable here).
All TX/RX NIC Ethernet features are enabled (RX/TX Checksums, TSO/GRO/LRO etc..).
We tried disabled TSO (CPU intensive) and played with Affinities to split the TCP stack code from the gRPC application and that also didn't helped.
The problem here I think is the memory management done by the gRPC (allocation and freeing of Tensor buffers) - I'm still looking at it and will share once I know more.
GPU Direct RDMA is in the pipeline, along with memory optimizations (ODP) and other improvement (connections management, etc..). I'm preparing a plan (depends on the resources we'll have here) and I will gladly share it soon I have it.
As the above optimizations are related to verbs work provided by @junshi15 (which is a P2P RDMA),
I think we must also talk about future work which will introduce collectives notation of reduction between the workers (thus remove the need of parameter server) without integrating MPI (but rather a "native" approach of collectives in tensorflow).

@shamoya tremendous work! P2P RDMA is more usefull for the majority of users who do not run Tesla. Regarding RoCE vs IB - reoccurring theme in this thread is missing the role of latency. You have calculated the bandwidth comparison based on one connection and MTU. Depending on MTU (which is tuned to NUMA/Affinity) and the number of threads/connections - that bandwidth will change. Because of latencies (overhead in establishing and replying to a connection), RoCE will always have a lower practical throughput than otherwise indicated by bandwidth measurement alone.

@avader906 - In general I agree with the impact of RoCE added latency and number of connections, but I don't think it matters at all in our specific use case.
We care about large messages (Tensors) so latency ~ throughput,
and number of connections is not in large scale (dozens of nodes at max) so I don't expect any penalties in HW caches, and all of them are established beforehand.
Do you agree or I misunderstood your point ?

@shamoya it was a general reflection on scalability and the compound effect latencies might have within platform architecture decisions. i agree with you that specific performance is use case dependent.

Ok, I see now the bad performance with gRPC TCP on VGG-16 (large Tensors) is explained in #6116 (Thanks for the great analysis @ilhe).
Waiting for #7466 to be merged and and we will re-run the gRPC TCP results again.
This will give us much better indication of the RDMA improvement in large tensors.

@shamoya  is there a testbed in tensorflow specifically for gRPC? or even a crude hello world.
I have all the protobufs converted over to swift 3.1 but now just trying to wrap head around dropping down to gRCP https://github.com/nubbel/swift-tensorflow

We published a RDMA based version here: https://github.com/CGCL-codes/Tensorflow-RDMA
FYI.

We published a RDMA based version here: https://github.com/CGCL-codes/Tensorflow-RDMA FYI.

Can you paste the source code?


Gatsby + beta.18:  "String interpolation is not allowed in graphql tag"

Updated my gatsby project from beta.12 to beta.18 and a I got a message like this:
String interpolation is not allowed in graphql tag:
  29 |     }
  30 |   }
> 31 |   ${frag_0}
     |  ^^^^^^^^^
  32 | `)($$Image.Fragments.GatsbyImageSharpFluid.query);
  33 |
  34 | function parse(value) {

I'm using graphql fragments and it was working with beta.12.

Yes you need to set "fragment-in-query=exclude". I didn't take the time to document this yet! Sorry!

no problem @jfrolich! thanks :)

Template tags were hacked in before to just support Gatsby. Now we have proper support for them, this setting is necessary to make sure the fragments are not embedded in the query which is the default for graphql-ppx.


Max Workers for Parallel Runner

Description
I am working with a very slow database connection to get data migrated to S3.  The parallel runner allows me to get up to the number of cpu core connections running in parallel.
Context
I would like to be able to kick it up a notch while waiting on slow sql queries.
Possible Implementation
Parallel Runner Module
As shown int the ProcessPoolExecutor docs max_workers can be passed into the ProcessPoolExecutor
Change Line 34 in the parallel runner module to bring in Optional.
- from typing import Any, Dict
+ from typing import Any, Dict, Optional

Change Line 59-68 in the parallel runner module
-    def __init__(self):
+   def __init__(self, max_workers: Optional[int]=None):
        """Instantiates the runner by creating a Manager.
+
+     Args:
          max_workers
        """
        self._manager = ParallelRunnerManager()
        self._manager.start()
+     self.max_workers = max_workers

Change line 170 in the parallel runner module to the following
-         with ProcessPoolExecutor() as pool:
+        with ProcessPoolExecutor(max_workers=self.max_workers) as pool:

kedro_cli in template
add MAX_WORKERS_HELP to kedro_cli line 91
+
+MAX_WORKERS_HELP = """Maximum number of process to run in parallel. If max_workers is None or not given, it will default to the number of processors on the machine. If max_workers is lower or equal to 0, then a ValueError will be raised.
In the default template add a flag to the cli in [kedro_cli lines 102-147](https://github.com/quantumblacklabs/kedro/blob/861baa5ee8dd1c8ffce3ef83ae598fa38ecb55e6/kedro/template/%7B%7B%20cookiecutter.repo_name%20%7D%7D/kedro_cli.py#L102-L147)

``` diff
@click.group(context_settings=CONTEXT_SETTINGS, name=__file__)
def cli():
    """Command line tools for manipulating a Kedro project."""

@cli.command()
@click.option("--from-nodes", type=str, default="", help=FROM_NODES_HELP)
@click.option("--to-nodes", type=str, default="", help=TO_NODES_HELP)
@click.option(
    "--node",
    "-n",
    "node_names",
    type=str,
    default=None,
    multiple=True,
    help=NODE_ARG_HELP,
)
@click.option(
    "--runner", "-r", type=str, default=None, multiple=False, help=RUNNER_ARG_HELP
)
@click.option("--parallel", "-p", is_flag=True, multiple=False, help=PARALLEL_ARG_HELP)
+ @click.option("--max-workers", type=int, default=None, multiple=False, help=MAX_WORKERS_HELP)
@click.option("--env", "-e", type=str, default=None, multiple=False, help=ENV_ARG_HELP)
@click.option("--tag", "-t", type=str, default=None, multiple=True, help=TAG_ARG_HELP)
- def run(tag, env, parallel, runner, node_names, to_nodes, from_nodes):
+ def run(tag, env, parallel, runner, max_workers, node_names, to_nodes, from_nodes):
    """Run the pipeline."""
    from {{cookiecutter.python_package}}.run import main
    from_nodes = [n for n in from_nodes.split(",") if n]
    to_nodes = [n for n in to_nodes.split(",") if n]

    if parallel and runner:
        raise KedroCliError(
            "Both --parallel and --runner options cannot be used together. "
            "Please use either --parallel or --runner."
        )
+
+  if runner and max_workers != None:
+     raise KedroCliError(
+        "Both --runner and --max-workers options cannot be used together."
+        "Please use either --parallel with --max-workers or --runner."

    if parallel:
        runner = "ParallelRunner"
    runner_class = load_obj(runner, "kedro.runner") if runner else SequentialRunner
+
+   runner_kwargs = {}
+   if parallel and max_workers !=None:
+      runner_kwargs['max_workers'] = max_workers

    main(
        tags=tag,
        env=env,
-         runner=runner_class(),
+         runner=runner_class(**runner_kwargs), # i am not familiar with load_obj, so I am not completely sure this is correct
        node_names=node_names,
        from_nodes=from_nodes,
        to_nodes=to_nodes,
    )

Docs
04_create_pipelines.md line 727
- * `ParallelRunner` - runs your nodes in parallel; independent nodes are able to run at the same time, allowing you to take advantage of multiple CPU cores.
+ * `ParallelRunner` - runs your nodes in parallel; independent nodes are able to run at the same time, allowing you to take advantage of multiple CPU cores as set by `max_workers`.

05_nodes_and_pipelines.md line 526
+ > *Note: * the parallel runner can be called with --max-workers to set the maximum number of worker processes.

004_create_pipelines.md line 737
+ > *Note: * the parallel runner can be called with --max-workers to set the maximum number of worker processes.

Hi @WaylonWalker, that's great, thank you for your effort!
I agree it's very useful. The next step would be to have a separate runner type (gevent/eventlet based) for IO-heavy operations, but for now it should do the job.
Can you please send a PR with these changes?

Thanks @Flid I'll work on it.

@WaylonWalker
We had a quick conversation about this issue with the team. We are trying to limit the complexity of the tool public interface, and would prefer to not have another CLI parameter for the run command (I'm talking about --max-workers). It has lots of switches already, and this one new is not going to be widely used really.
At the same time, we consider the entire kedro_cli.py file to be a part of the "public interface", something the Kedro user can access and modify easily in their projects. That's why, if you just add it as a parameter to the ParallelRunner (max_workers, as you did already), then users can "hardcode" the parameter in the file themselves. It's not as nice for your case, but keeps it simple for the majority of users.
Sorry a bit of your work is wasted, but the rest is still very appreciated. It would be great if you send a pull request.

@Flid Thanks for the heads up.  I'll make sure to revert that part.  Our team will be using a custom cookiecutter based on kedro new with a few customizations for us.  I can make the change there.
I was able to easily make the change, testing it has proven tricky as my current pipeline is in 14.3 and several things seemed broken when I tried to use my branch of kedro on it.  Nothing major just need a bit of time to make the upgrade and test it out.

@WaylonWalker We have added this in https://github.com/quantumblacklabs/kedro/commit/4dc48e7b17104356934b5a7cb91c760a739fe44e (and we are releasing the new version soon). I am closing this issue but let us know if you have any questions :)

Thanks @921kiyo I am just now getting several of my pipelines up to the latest version so that I could test.


Auto Merge Pull Request

Please have a look onto the file contributors.yml and try to resolve the issue, due to which it fails to execute.
@Siddhant-K-code

I think, bot doesn't have power to merge PR automatically

Perhaps! Btw, thanks for your efforts.. :))


Move to ipfs-shipyard?

Now we have an org to incubate projects that not part of the core implementation of the protocol or discussion of the spec. That org is ipfs-shipyard created from https://github.com/ipfs/pm/issues/448
Short description:

IPFS Shipyard is a venue for the community to pursue and collaborate on research experiments, products, code libraries and more around the IPFS project. It is where innovation in userland happens and where we discover and form new primitives to push to the core of IPFS.

Anyone opposing?

Why? This is part of webui and as such shipped with every release of go-ipfs

@dignifiedquire we should still be able to ship this as part with webui, even if it's with ipfs-shipyard

Sure, but it is part of the core offering is what I am trying to say. So I don't see the reason to move it to the shipyard

It can stay here :)


Convert Fluent's uint8 type to Postgres "char"

Fluent's .uint8 schema data type is now converted to Postgres' 8-bit "char" type.

These changes are now available in 2.0.0-beta.2.3


Structuring APIs

A massive PR includes the API structuring, test cases, CI setup
What it does not contain

An exhaustive test suite
RTD setup
A well structured documentation
Lot of example code
mypy check

The APIs might need more changes (one I could think off is the have dictionary style access). The primary motive I had while designing the APIs is making user relying on git checkout as much as possible. But I could see why a git + stockroom workflow should be an option but should not be the only workflow possible especially since stockroom allows model storage without user spending time figuring out how to store models. The next release will be a more organized with more API planning analyzing user stories trying out with this release

@hhsecond why did you decide not to go with the src/stockroom layout?


Review and consider adding Hope Life Center

https://www.google.com/maps/place/Hope+Life+Center/@44.9564206,-89.6668267,17z/data=!3m1!4b1!4m6!3m5!1s0x880021a98e83798f:0x8f56a5c2ab8ff7dc!8m2!3d44.9564168!4d-89.6642518!16s%2Fg%2F1tfm20b4
https://github.com/MassMove/SCBot/blob/master/2023/Hope_Life_Center.md

Added in https://github.com/MassMove/AbortionMisinformation/pull/9


add forcing read to forcing module

Needed to test code more rigorously and set up for BMI links

https://github.com/NOAA-OWP/noah-mp-modular/pull/7 includes forcing read capability. The module can be improved, but I'm closing this issue.


Make shallow circuit demo Catalyst-Compatible

Context:
Convert Shallow Circuit Demo into a Catalyst-compatiable one.
Description of the Change: Mainly replace jax.jit with qjit. However, it introduces errors related to functools.partial (#814 and #815). Right now I circumvent the errors by avoiding using functools.partial. Will open the other PRs to fix the issues.
Related GitHub Issues:
[sc-65901]

Just a note that codecov/project coverage failure usually means (a) the feature branch's new feature is not covered by a new test and/or (b) the feature branch is out of sync with main branch.