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

Network benchmarks #318

Closed
brycelelbach opened this issue Jul 10, 2012 · 5 comments
Closed

Network benchmarks #318

brycelelbach opened this issue Jul 10, 2012 · 5 comments

Comments

@brycelelbach
Copy link
Member

[reported by heller] [Trac time Fri Feb 17 14:47:36 2012] In order to optimize distributed performance, we need benchmarks to measure characteristics of the underlying network.
This will allow HPX to be tuned to different kind of networks.

@brycelelbach
Copy link
Member Author

[comment by blelbach] [Trac time Sun Apr 8 18:30:11 2012] I've spoken with heller in emails/irc about what he wants here, that info needs to be moved into the ticket.

@ghost ghost assigned brycelelbach Aug 22, 2012
@brycelelbach
Copy link
Member Author

< heller> wash: transferred bytes/s, overhead of serialization, percentage of useful traffic vs. traffic from the application
< heller> wash: how many parcels sent per message
<@wash> heller: okay, transfered bytes, parcels sent per message, these are both easy I think
< heller> message sizes
< heller> etc
<@wash> heller: keep going, any others that come to mind
< heller> i wouldn't know how to measure bandwidth ;)
<@wash> heller: by transfered bytes/s you mean transfered bytes per second?
< heller> wash: also, how much maintenance overhead is in a parcel
<@wash> and by message sizes you mean average message size?
< heller> etc
< heller> no
< heller> not average
< heller> well sure
< heller> average is something to consider as well
<@wash> how else would it work?
<@wash> you want to store the size of every parcel?
< heller> but i also want some time dependent graph
< heller> I am, for example not interested in what is happening on startup or shutdown
<@wash> heller: hm, can you elaborate on how that would work?
< heller> save it to a file :P
< heller> with a timestamp
< heller> and postprocess it
<@wash> let's go back to transferred bytes/second
<@wash> by that you mean message sizes / time right?
<@wash> we used to have these counters, katelyn implemented them I believe
< heller> it is more than that
< heller> it is not how much time it takes to send one message
< heller> cause there might be concurrent connections
< heller> I am interested in how much bytes per second go over the netowrk interface
<@wash> heller: so that one is easyish
<@wash> average message sizes is easyish
<@wash> average parcels sent per message is easy
< heller> wash: we need to answer these questions: "What is the overhead of sending data with HPX?", "How does HPX utilize the network?", "What is the overhead of AGAS (aka, maintenance actions vs. real actions)?"
< heller> stuff like this

@brycelelbach
Copy link
Member Author

So:

  • Transferred bytes/s
  • Overhead of serialization
  • Percentage of useful traffic vs traffic from the application (heller, can you elaborate?)
  • Parcels sent per message
  • Message sizes
  • Bandwidth (hard)

We want to have the option of both collecting individual data points (pros: more info, cons: I/O bound, more overhead) and keeping a running average (pros: less overhead, cons: less info).

Research questions we need to answer:

  • "What is the overhead of sending data with HPX?" (we need to define "data")
  • "How does HPX utilize the network?"
  • "What is the overhead of AGAS (aka, maintenance actions vs. real actions)?" (this is to some degree understood, at least more so than parcel overheads)

@hkaiser
Copy link
Member

hkaiser commented Apr 10, 2013

The following pieces of information have been made available now:

  • Transferred bytes - This is available from the performance counter /data/count/<connection_type>/<operation> (see Performance counters). In order to get the size per second this number needs to be divided by the result of /runtime/uptime.
  • Overhead of serialization - This information is available from /serialize/time/<connection_type>/<operation> and /serialize/count/<connection_type>/<operation>
  • Parcels sent per message - This information is available from /parcels/count/<connection_type>/<operation> and /messages/count/<connection_type>/<operation>
  • Message sizes - This is available from the performance counter /data/count/<connection_type>/<operation>
  • Bandwidth

@sithhell
Copy link
Member

i think we can close this now. Everything has been implemented and the benchmarks are available here: https://github.com/STEllAR-GROUP/hpx_benchmarks/tree/master/benchmarks/network

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants