Skip to content
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

Obs window size #5

Open
wants to merge 11 commits into
base: stateful-actors-implementation
Choose a base branch
from

Conversation

SatriaPriambada
Copy link
Collaborator

  1. Change the frequency from 125Hz to 250Hz
    We change the firing frequency according to dataset.
    This means prediction will happen after 30 sec * 250Hz = 7500 request

  2. Change the server to accomodate obs_w_30sec.
    obs_w_30sec is equal to batch size of waveform with observation window of 30 sec.
    For example if we want to do profile_ensemble of 5 minutes of waveform we will send tensor in size of (obs_w_30sec, 1, 7500).

@alindkhare alindkhare self-requested a review February 8, 2020 23:03
@@ -111,7 +111,12 @@ def __init__(self, address, actor_handles,
raise ValueError("Multiple Patients specified."
"Specify only one.")
patient_name = patient_name[0]
prediction_tensor = torch.zeros((1, 1, PREDITICATE_INTERVAL))

obs_w_30sec = query_kwargs.pop("obs_w_30sec", None)
Copy link
Owner

Choose a reason for hiding this comment

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

why obs_window has to be per query basis? Can it part of http server instantiation?

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 assume that when profile client make request it can change the obs_window.
If we put it as part of http server instantiation then the client will always have to send the same obs_window.
For example, when the patients are on stable condition client will only look at interval of obs_window 30s, however when the patients are critical condition, the client can send obs_window 30s, 2min, 5 min, etc

Copy link
Owner

Choose a reason for hiding this comment

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

Yes the client has to be consistent in sending the information. Any reasons for the assumption you are making?

if obs_w_30sec is None:
raise ValueError("Specify obs_w_30sec in query")
obs_w_30sec = int(obs_w_30sec[0])
prediction_tensor = torch.zeros((obs_w_30sec, 1, PREDITICATE_INTERVAL))
Copy link
Owner

@alindkhare alindkhare Feb 9, 2020

Choose a reason for hiding this comment

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

I think we need one more profiling :

@ray.remote
def echo_tensor(a : torch.Tensor): 
	return a
>>> %timeit ray.get(echo_tensor.remote(torch.zeros((obs_w_30sec, 1, PREDITICATE_INTERVAL))))

@SatriaPriambada
Copy link
Collaborator Author

SatriaPriambada commented Feb 9, 2020

This is the result from experimenting with ray profiling:
For context there are two function tested
Normal function means we input a tensor with ray remote and return the tensor back

@ray.remote
def echo_tensor(a : torch.Tensor):
   return a

Simple function means we input a tensor with ray remote and return a boolean whether serialization finished or not

@ray.remote
def echo_tensor_simple(a : torch.Tensor):
	return 1

The results are performed by doing the following:
for obs_w_30sec in range(1,11)

>>> PREDITICATE_INTERVAL = 7500
>>> %timeit ray.get(echo_tensor.remote(torch.zeros((obs_w_30sec, 1, PREDITICATE_INTERVAL))))
>>> %timeit ray.get(echo_tensor_simple.remote(torch.zeros((obs_w_30sec, 1, PREDITICATE_INTERVAL))))

ray_serialize_latency_vs_obs_w_30sec

@SatriaPriambada
Copy link
Collaborator Author

SatriaPriambada commented Feb 10, 2020

This is the latency profile for different observation_window_30sec
Based on my implementation, each observation window will be treated like a batch_size
The experiment uses the new tensor size of 30 sec * 250Hz = 7500

  • timeit time means the time taken for %timeit to run the tensor with batch_size
  • Tq time means the maximum expected time for request to wait in the queue before profiled
  • Ts time means the time request get executed from ensemble
  • Total time = Tq + Ts

1patient_latency_vs_obs_w_30sec

@SatriaPriambada
Copy link
Collaborator Author

This is the latency profile for different observation_window_30sec after the fix of calculate throughput

The experiment uses tensor size of 30 sec * 250Hz = 7500
Number of client is 1 patient
Model are ResNet1D with base_filters = 128, kernel_size = 16, n_block = 8

  • timeit time means the time taken for %timeit to run the tensor with batch_size
  • Tq time means the maximum expected time for request to wait in the queue before profiled
  • Ts time means the time request get executed from ensemble
  • Total time = Tq + Ts

1patient_latency_vs_obs_w_30sec

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.

2 participants