how to use dmclock in multi-thread io model?

[zhencao-art]

No description provided.

[GTHubT]

server side or client side? or can you give more detail?
client side: you just need calculate the delta and rho, then send to server.
server side: mclock will gather the io request in priority queues。you just need push the request to mclock，and get request by multithread。

[zhencao-art]

server side or client side? or can you give more detail?
client side: you just need calculate the delta and rho, then send to server.
server side: mclock will gather the io request in priority queues。you just need push the request to mclock，and get request by multithread。

server side
sever is run-to-completed model. i am worry the preformance problem

thx for you reply!

[ivancich]

I'm not sure I fully understand the question. The dmclock server code is thread-safe. You can use the dmclock server code in either pull or push modes.

In pull mode (i.e., using the class PullPriorityQueue), the worker threads can pull their next request from the queue (i.e., by calling pull_request) and then work on them. If the queue is empty, pull_request will return an item with type set to PriorityQueueBase::NextReqType::none. And if all current ops are over the limit, pull_request will return an item with type set to PriorityQueueBase::NextReqType::future and for which data contains the time at which the next operation should be ready (unless additional operations are added to the queue in the meantime).

Does that answer your question?

[zhencao-art]

I already know how to use it. thanks !
if an item with PriorityQueueBase::NextReqType::future has been pull from queue, is the limit not useful? i can not understand that, when that case happens?
I run the test ut case dmclock_server_pull.pull_weight, i modify dmc::ClientInfo info1(0.0, 1.0, 0.0);dmc::ClientInfo info2(0.0, 2.0, 0.0); with dmc::ClientInfo info1(0.0, 1.0, 1.0);dmc::ClientInfo info2(0.0, 2.0, 1.0);, run result:
`
Running main() from gtest_main.cc
Note: Google Test filter = dmclock_server_pull.pull_weight
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from dmclock_server_pull
[ RUN ] dmclock_server_pull.pull_weight
/Users/zhencao/work/dmclock/test/test_dmclock_server.cc:637: Failure
Expected: Queue::NextReqType::returning
Which is: 4-byte object <00-00 00-00>
To be equal to: pr.type
Which is: 4-byte object <01-00 00-00>
unknown file: Failure
C++ exception with description "boost::bad_get: failed value get using boost::get" thrown in the test body.
[ FAILED ] dmclock_server_pull.pull_weight (1 ms)
[----------] 1 test from dmclock_server_pull (1 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (1 ms total)
[ PASSED ] 0 tests.
[ FAILED ] 1 test, listed below:
[ FAILED ] dmclock_server_pull.pull_weight

1 FAILED TEST
`

I know that i misunderstand reservation, weight, limit util i run it， why is its result that?
how to use reservation, weight, limit? client-1 (min iops 100, weight 1, max iops 200), client-2 (min iops 200, weight 2, max iops 400)

[ivancich]

First I'm assuming we're talking about master.

If the limits are all set to 0.0 then there is no limit, and that means you will never get PriorityQueueBase::NextReqType::future when calling pull_request.

You modify the ClientInfo tags so the limit is then 1.0. I also assume that at_limit_param is AtLimit::Wait when you construct your queue. In that case, limits are enforced and you should not be able to pull more than 1 request per second from either client (info1 and info2). If you try to pull requests faster than that you will get PriorityQueueBase::NextReqType::future.

The testing framework was expecting to receive PriorityQueueBase::NextReqType::returning (initially wrote in error: PriorityQueueBase::NextReqType::future), so you get the testing failure.

If you want the parameters you state, then I think you'd want:

dmc::ClientInfo info1(100.0, 1.0, 200.0);
dmc::ClientInfo info2(200.0, 2.0, 400.0);

And with those settings you may get PriorityQueueBase::NextReqType::future from pull_request in which can delay calling pull_request again until the when_ready time or possibly until you add new requests to the queue.

Have you tried it with those settings? And if so, how is it not acting as you'd expected?

[zhencao-art]

I tried it with those settings! it works well.
What do you think of the size of IO? I read the paper, it say that just a little.

Io size & io burst....