Page 1 of 1

Emesh Bandwidth Program

PostPosted: Wed Jul 30, 2014 6:15 pm
by baseballguy
Hi,

I have a question about measuring bandwidth in the Emesh programs. In the emesh_bandwidth_bisection program, I wanted to track the network bandwidth while running different benchmarks (such as PARSEC). However, I looked into the code and noticed that it had statements (result1 = (37500000)/time;) that give a relatively fixed bandwidth. I was wondering if anyone had any other code or if I could modify the existing code to track the bandwidth without having that number restriction?

Thanks

Re: Emesh Bandwidth Program

PostPosted: Sat Aug 02, 2014 5:18 pm
by greytery
Those numbers in the eMesh examples are the programmer's calculation/estimate of the amount of data transmitted across the eMesh (i.e. inside the Epiphany) divided by the time the program took to complete the transfer to give the bandwidth per second.
As the examples are structured, it's necessary to estimatate the total at the host program level because there are no internal counters maintained in the programs that run on the cores. Since each program transmits exactly the same amount of data each time, and there is nothing else going on, then the results are 'relatively fixed' for each example.
I'd say these were demonstrations rather than benchmarks because they are not indicative of what the acheivable bandwith would be under 'real' conditions.

To modify the components of the programs that run on the Epiphany cores, you'd need to add counters to hold the amount of data sent/received by each core over each core-to-core link making up the whole eMesh network, then pull those counters back to the host at the end of the run, for accumulation and display. (No, I do not have sample code). You would probably find that different cores and different links show different values for bandwidth.

After a cursory look at the PARSEC benchmark suite and its documentation, I can't see that it's concerned with bandwidth at all - just on running the various problems (13 different workloads) with as many threads or as much parallellism as possible in order to measure how fast the overall jobs take.
The actual amount of data being transmitted during the benchmark will differ between implementations of the PARSEC benchmark suite on different platforms (ARM, Intel, SPARC, Itanium, etc) - so is not comparable, and so not something that the benchmark designers seem to feel needs to be measured.

Cheers,