-
Notifications
You must be signed in to change notification settings - Fork 2
[CPP-80]Add realtime delay when reading an SBPfile and pip cache to GA. #43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…hachoppa integration.
8544357
to
27a42eb
Compare
27a42eb
to
ca83fca
Compare
05767e9
to
40b95ab
Compare
40b95ab
to
35b4e62
Compare
42b1806
to
07dfbdb
Compare
a8182ea
to
cabdeea
Compare
cabdeea
to
ac66a2c
Compare
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). |
.github/workflows/main.yml
Outdated
- name: Cache pip | ||
uses: actions/cache@v2 | ||
with: | ||
path: ~/Library/Caches/pip |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
.github/workflows/main.yml
Outdated
- 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" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
dc2b64a
to
f7bf1f4
Compare
f7bf1f4
to
18039a9
Compare
@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" } |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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
There was a problem hiding this 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
console_backend/src/types.rs
Outdated
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); |
There was a problem hiding this comment.
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:
process_messages(messages, shared_state_clone_, client_send.clone(), true); | |
process_messages(messages, shared_state_clone_, client_send.clone(), /* realtime_delay = */ true); |
There was a problem hiding this comment.
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.
This change currently points to a branch undergoing review:
https://github.com/swift-nav/thachoppa/pull/18swift-nav/libsbp#967Attempts 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 featureadjust benchmarks using this new featureadd some unit testing to the realtime_delay function in maintab