<div dir="ltr">Hi Ben,<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 6, 2017 at 10:51 PM, Ben Evans <span dir="ltr"><<a href="mailto:bevans@cray.com" target="_blank">bevans@cray.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>My initial question is what are you measuring and where are you measuring it?</div></div></blockquote><div>The tool I'm using is collectl, it in turn is calling perfquery once a minute and at the end reports back the difference between the previous and current reading divided by 256*secondInterval to provide a number of kB/s.<br></div><div>(perfquery reports counters /4 legacy left over from 32b counter days)<br><br></div><div>The lustre stats seem to be gathered more or less the same way, the lustre plugin does a delta of written/read bytes, divides by 1024 * secondInterval to get kB/s.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div><br>
</div>
<div>There are many different layers of caching happening, possibly all at the same time.  If you're benchmarking it's much better to figure out your max sustained read/write speeds than rely on peaks.</div></div></blockquote><div>I'm not benchmarking, was mainly trying to understand how/why my Infiniband graphs weren't showing at least the same amount of traffic as Lustre...<br></div><div><br>Most of the time though the graphs do more or less coincide so I guess maybe there was either a measurement glitch or we do see some limited effects of caching.<br></div><div><br>Thanks,<br></div><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">Eli<br><div><br>
</div>
<div>-Ben</div>
<div><br>
</div>
<span id="m_-8988384249590519371OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span>lustre-discuss <<a href="mailto:lustre-discuss-bounces@lists.lustre.org" target="_blank">lustre-discuss-bounces@lists.<wbr>lustre.org</a>> on behalf of "E.S. Rosenberg" <<a href="mailto:esr+lustre@mail.hebrew.edu" target="_blank">esr+lustre@mail.hebrew.edu</a>><br>
<span style="font-weight:bold">Date: </span>Monday, February 6, 2017 at 3:25 PM<br>
<span style="font-weight:bold">To: </span>"<a href="mailto:lustre-discuss@lists.lustre.org" target="_blank">lustre-discuss@lists.lustre.<wbr>org</a>" <<a href="mailto:lustre-discuss@lists.lustre.org" target="_blank">lustre-discuss@lists.lustre.<wbr>org</a>><br>
<span style="font-weight:bold">Subject: </span>[lustre-discuss] Traffic compression?<br>
</div><div><div class="h5">
<div><br>
</div>
<div>
<div>
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>We started closer monitoring of resources on our cluster and I noticed that there is sometimes a big discrepancy between the read traffic reported by Lustre and the incoming traffic reported by infiniband (which is the interace carrying the Lustre traffic).<br>
<br>
</div>
Currently I have a 4.4GB peak on Lustre while Infiniband at the same time is showing just 1.4GB/s traffic (also there is a 2 minute difference between the 2 peaks)<br>
This is the summation of all the nodes (without the servers) in the cluster.<br>
</div>
The stats are gathered using collectl at a 1 minute interval.<br>
</div>
<br>
</div>
Thanks,<br>
</div>
Eli<br>
<br>
</div>
(There are also lots of stats that match 1:1 which makes me less sure what to make of this)<br>
</div>
</div>
</div>
</div></div></span>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

</blockquote></div><br></div></div>