[asio-users] blocking udp client

[Apostolos Manolitzas]

Hello all,

based on the example
http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/example/cpp03/timeouts/blocking_udp_client.cpp
I forked the pattern to my application, but by using the linux perf tool
<https://perf.wiki.kernel.org/index.php/Main_Page> I noticed that in the
loop

// Block until the asynchronous operation has completed.
do io_service_.run_one(); while (ec == boost::asio::error::would_block);

it spends most of it's time.

|| operator unspecified_bool_type() const // true if
error

|
{

| return m_val == 0 ? 0 :
unspecified_bool_true;

6.84 | 72e: test
%eax,%eax

| // Block until the asynchronous operation has
completed.

|
do

|
io_.run_one();

| while (ec == basio::error::would_block);

is there any better pattern to implement the udp reception with timer?
or do you think that I should not worry about the performance.


thanks,

-Apostolos

[Apostolos Manolitzas]

Hello all,

based on the example
http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/example/cpp03/timeouts/blocking_udp_client.cpp
I forked the pattern to my application, but by using the linux perf tool
<https://perf.wiki.kernel.org/index.php/Main_Page> I noticed that in the
loop

// Block until the asynchronous operation has completed.
do io_service_.run_one(); while (ec == boost::asio::error::would_block);

it spends most of it's time.

||
operator unspecified_bool_type() const // true if
error

|
{

| return m_val == 0 ? 0 :
unspecified_bool_true;

6.84 | 72e: test
%eax,%eax

| // Block until the asynchronous operation has
completed.

|
do

|
io_.run_one();

| while (ec == basio::error::would_block);

is there any better pattern to implement the udp reception with timer?
or do you think that I should not worry about the performance.


thanks,

-Apostolos

[Apostolos Manolitzas]

Post by Apostolos Manolitzas
Hello all,
based on the example
http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/example/cpp03/timeouts/blocking_udp_client.cpp
I forked the pattern to my application, but by using the linux perf tool
<https://perf.wiki.kernel.org/index.php/Main_Page> I noticed that in the
loop
// Block until the asynchronous operation has completed.
do io_service_.run_one(); while (ec == boost::asio::error::would_block);
it spends most of it's time.
|| operator unspecified_bool_type() const // true if
error
|
{
unspecified_bool_true;
6.84 | 72e: test
%eax,%eax
| // Block until the asynchronous operation has
completed.
|
do
|
io_.run_one();
| while (ec == basio::error::would_block);
is there any better pattern to implement the udp reception with timer?
or do you think that I should not worry about the performance.
thanks,
-Apostolos

I am sorry for the double post.

-Apostolos

[Gruenke,Matt]

The cost of that loop should be proportional to the packet rate. Since the program is listening on just one connection and doing no other real work, most of the time is going to be consumed by overhead.

I do feel the style of that example isn't great. For one thing, I find it a bit confusing the way would_block is used to detect whether the read has completed. Also, I prefer to embed the loop as a state machine, where the next async_read() is issued in the handle_receive() function (which I'd make a non-static member). But I understand that the point of the example is to show how to use async_read() inside a blocking function.

As for efficiency improvements, I'd use a larger buffer and only touch the timer when it expires. At timer expiry, you check the current time against the next timeout. If the connection has not timed out, then issue an async_wait() to occur at that next timeout. This only works if a later read doesn't have a shorter timeout than an earlier one (I should also note that I don't actually know how expensive deadline_timer::expires_from_now() is - it might already do something clever).

Generally speaking, the async interface provides a powerful programming model, but not without cost. If you want the absolute highest possible throughput or efficiency, then you'll need to look elsewhere. That said, the overhead of ASIO is not unreasonable for most purposes.


Matt


________________________________

This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.

[Niklas Angare]

Post by Apostolos Manolitzas
based on the example
http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/example/cpp03/timeouts/blocking_udp_client.cpp
I forked the pattern to my application, but by using the linux perf tool

Your message is hard to read and I'm not familiar with the Linux perf tool.
However you should keep in mind that information from a profiler may be very
misleading if you don't take into account that the application may spend a
large part of the time waiting for the network, not using any CPU time. 80 %
of a microsecond is not a lot of time, for example :)

Regards

Niklas Angare

[Apostolos Manolitzas]

Post by Niklas Angare

Post by Apostolos Manolitzas
based on the example
http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/example/cpp03/timeouts/blocking_udp_client.cpp
I forked the pattern to my application, but by using the linux perf tool

Your message is hard to read and I'm not familiar with the Linux perf tool.
However you should keep in mind that information from a profiler may be very
misleading if you don't take into account that the application may spend a
large part of the time waiting for the network, not using any CPU time. 80 %
of a microsecond is not a lot of time, for example :)
Regards
Niklas Angare

Thank you guys for the answers.

After some extra research it seems that this is a known issue regarding
the timeout pattern, much mentioned in SO [1],[2],[3],[4]. Furthermore,
they suggest a solution with the use of std::future.

-Apostolos



[1]
http://stackoverflow.com/questions/291871/how-to-set-a-timeout-on-blocking-sockets-in-boost-asio?lq=1
[2] http://stackoverflow.com/questions/6041016/boost-asio-timeout
[3]
http://stackoverflow.com/questions/4553162/c-boost-asio-how-to-read-write-with-a-timeout
[4]
http://stackoverflow.com/questions/22965899/can-i-read-from-a-socket-synchronously-using-boost-asio-with-a-timeout-on-a-mult

[Gruenke,Matt]

I disagree. Since your concern is single-connection performance, I can't see how it's a win to involve another thread. I'd recommend just modifying the example to use the timer strategy I mentioned.

If you need better performance than that, then you can skip ASIO and write your own sockets & event multiplexing code. That will let you avoid the overhead of composing & copying around all of those functors. But you'd probably need to be writing some high-throughput dataplane code, for that amount of overhead to be an issue.


Matt


-----Original Message-----
From: Apostolos Manolitzas
Sent: June 10, 2014 04:51
To: asio-***@lists.sourceforge.net
Subject: Re: [asio-users] blocking udp client

Thank you guys for the answers.

After some extra research it seems that this is a known issue regarding the timeout pattern, much mentioned in SO [1],[2],[3],[4]. Furthermore, they suggest a solution with the use of std::future.

-Apostolos



________________________________

This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.