Skip to content

Conversation

john-michaelburke
Copy link
Collaborator

@john-michaelburke john-michaelburke commented Apr 28, 2021

This change currently points to a branch undergoing review:
https://github.com/swift-nav/thachoppa/pull/18 swift-nav/libsbp#967

Attempts introducing an artificial delay while reading SBP files to mimic a realtime viewing.
Adds pip caching to GA.

TODO (Want to get some feedback on the approach first)

  • fix current unit tests to accommodate this feature
  • adjust benchmarks using this new feature
  • add some unit testing to the realtime_delay function in maintab

@john-michaelburke john-michaelburke force-pushed the john-michaelburke/realtime branch from 8544357 to 27a42eb Compare April 29, 2021 02:19
@john-michaelburke john-michaelburke force-pushed the john-michaelburke/realtime branch from 27a42eb to ca83fca Compare April 29, 2021 02:48
@john-michaelburke john-michaelburke force-pushed the john-michaelburke/realtime branch 2 times, most recently from 05767e9 to 40b95ab Compare April 29, 2021 03:28
@john-michaelburke john-michaelburke force-pushed the john-michaelburke/realtime branch from 40b95ab to 35b4e62 Compare April 29, 2021 03:30
@john-michaelburke john-michaelburke force-pushed the john-michaelburke/realtime branch 7 times, most recently from 42b1806 to 07dfbdb Compare April 29, 2021 06:35
@john-michaelburke john-michaelburke force-pushed the john-michaelburke/realtime branch 8 times, most recently from a8182ea to cabdeea Compare April 29, 2021 21:20
@john-michaelburke
Copy link
Collaborator Author

The benchmarks in CI needed to be adjusted for this new delay. I choose not to use the delay for our backend cpu benchmark because the aim is to get worst case CPU usage so delay would counter this.

The Backend Mem benchmark greatly increased for Windows (Not too sure why) ~90MB mean +/- 40MB.

I added caching for all pip install stages in CI and it seems to moderately reduce build time with the exception of Windows, @jayvdb I think once you get the pycapnp wheel working, the reduction will be huge for windows in tandem with this change. Seems the other two wheels not being cached are fbs and pymany; however, I am not sure if they take much time at all.

I had to add LLVM/Clang to the CI to support the swiftnav-rs dependency through libsbp with this new GpsTime feature. This also adds a significant amount of time to the build sadly (Maybe it would be worth investigating caching Rust).

- name: Cache pip
uses: actions/cache@v2
with:
path: ~/Library/Caches/pip
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rather than having three cache locations, set PIP_CACHE_DIR to a sensible directory. '~/.cache/pip` is a good choice. Understand you may be tired of CI; I can take this up in my next PR.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Haha definitely a bit tired of CI but that's quite alright just getting better. Good suggestion this cleans up a lot of the repetition.

- name: Build ${{ runner.os }} Binaries.
env:
OS_NAME: ${{ runner.os }}
LIBCLANG_PATH: "C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/Llvm/x64/bin"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use a top(workflow) level env for this, so it isnt repeated multiple times.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is different for each operating system. Is there a way to set it only for certain OSs?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, either use if on the env, if that is possible at the global level, or set LIBCLANG_PATH_WIN: .., and then use that global in the per OS jobs where it is needed.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. I ended up going with the LIBCLANG_PATH_WIN. It would be nice to investigate an if on the env later on though so we can combine the two steps again.


_ => {
// no-op
continue;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is intended to avoid delays for messages we dont know about?

or avoid log flushes?

Either way, the reason should be added as a comment here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am doing it to prevent unrelated messages from forcing a delay. Not really sure what the best approach is as I know it prevents from log flushing. I could alternatively set a boolean here and check it on each iteration? What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

set a boolean, and pass it to realtime_delay, so that it can log when a delay was encountered and ignored.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a boolean but don't pass it to the realtime_delay. I decided not to go with the logging. I believe we would be getting something on the order of 5-10+ messages (not consumed) every 100ms so I think as small of a footprint as possible is ideal.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO we should still log them, but only if there is a delay in the message, or it is a message type with delay that we know is not appropriate when trying to simulate realtime delays ; they can be logged at the level below what is normally shown to the user. Currently anything below log::LevelFilter::Info is omitted, so Debug level would do the trick for now.
Our logger can also become smarter to collapse duplicated or similar messages.

I can work on this in my next log panel PR - I actually want a lot of logging activity, so it is easier to see how the log panel will perform if the console is left open for days.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright I added a debug for skipped messages and when a sleep occurs. How could I test out a different log level locally?

@john-michaelburke john-michaelburke force-pushed the john-michaelburke/realtime branch from dc2b64a to f7bf1f4 Compare April 30, 2021 02:05
@john-michaelburke john-michaelburke force-pushed the john-michaelburke/realtime branch from f7bf1f4 to 18039a9 Compare April 30, 2021 02:14
@john-michaelburke
Copy link
Collaborator Author

@silverjam @notoriaga PTAL

csv = "1"
paste = "1"
pyo3 = { version = "0.13", features = ["extension-module"] }
sbp = { git = "https://github.com/swift-nav/libsbp.git", rev = "0563350bb387e4a966a2b558adb7b05b2baf005f" }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be much effort to switch back to the choppa here? Not sure when this will be done. I have some changes that I'm gonna push soon which will break things (but I can just make a new branch)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When it's all set I can go and switch this + the choppa itself to use the new libsbp stuff

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think for the sake of the demo Monday it would be great if we could live with this. I wonder if it is possible to target a revision of a branch in cargo toml? Maybe that could allow you to continue developing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh don't worry about it, I'll just leave that one be and push a new one, probably will be easier to look at that way as well

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@notoriaga Too late. I figured it out. I guess you just provide the revision and drop the branch name and everything is groovy!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess you just provide the revision and drop the branch name and everything is groovy!

Nice, good to know

@john-michaelburke john-michaelburke changed the title [CPP-80]Add realtime delay when reading an SBPfile. [CPP-80]Add realtime delay when reading an SBPfile and pip cache to GA. Apr 30, 2021
Copy link
Contributor

@silverjam silverjam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one nit, but otherwise lgtm

let shared_state_clone_ = shared_state.clone();
let messages = sbp::iter_messages(stream);
process_messages(messages, shared_state_clone_, client_send.clone());
process_messages(messages, shared_state_clone_, client_send.clone(), true);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bare bools are not descriptive at the call site, I would prefer an enum, or simply:

Suggested change
process_messages(messages, shared_state_clone_, client_send.clone(), true);
process_messages(messages, shared_state_clone_, client_send.clone(), /* realtime_delay = */ true);

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. I created an Enum for the bare boolean in process_messages corresponding to RealtimeDelay::On/Off, the other bare delay was in the connect_to_file for whether or not to close after finishing where I only added an inline comment as you suggest.

@john-michaelburke john-michaelburke merged commit 19472b9 into main Apr 30, 2021
@john-michaelburke john-michaelburke deleted the john-michaelburke/realtime branch April 30, 2021 23:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants