<br><br><div class="gmail_quote">On Wed, Dec 22, 2010 at 1:32 AM, Oleg Drokin <span dir="ltr"><<a href="mailto:green@whamcloud.com">green@whamcloud.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Ah! This should have been noted somewhere.<br></blockquote><div><br>It was in some brief associated with the data but unfortunately I can't seem to find that.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Well, it's still unfair then! ;)<br></blockquote><div><br>Yea wasn't quite balanced, I was actually trying to test our current Lustre setup against what could be done with some extra parameters and the patch from 16900.  I'm pretty sure max_dirty_mb was set to 128 for both tests.  One thing that isn't clear to me is why the Lustre manual recomments max_dirty_mb = max_rpcs_in_flight x 4.  It seems to be that having them equal or max_dirty_mb slightly larger to handle any off my 1 erros should be sufficient?<br>
 <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
You see, each OSC can cache up to 32mb of dirty data by default (max_dirty_mb osc setting in /proc).<br>
So when you have 4M RPCs, you actually use only 8 RPCs to transfer your entire allotment of dirty pages where as you use 32 for 1M RPCs (and so setting it any higher has no effect unless you also bump max dirty mb). Of course this will only affect the write RPCs, not read.<br>

<div class="im"><br>
</div>Well, I don't think this should matter anyhow. Since we send the RPCs in async manner in parallel anyway, the latency of bulk descriptor get is not adding up.<br></blockquote><div><br>It does make a difference before read ahead has kicked in.  There is a big difference in how things start off even though for sequential load they all peak at the same value.  For instance if I was just accessing a portion of a file or seeking around and reading a few MBs instead of reading it all sequentially  this has a big impact IIRC.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Due to that the results you've got should have been much closer together too. I wonder what other factors played a role here?\<br></blockquote><div><br>I was also pretty interested in that as well.  It seems like hte larger RPC is hiding some other issue besides theoretical data on the wire.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I see you only had single client, so it's not like you were able to overwhelm the number of OSS threads running. Even with the case of 6 OSTs per oss assuming all 42 RPCs were in flight, that's still only 252 RPCs. did you make sure that that's the number of threads you had running by any chance?<br>
</blockquote><div><br>I did not check but this were decent systems (24 GB RAM, 2-quad core nehalems with HT) so I assume it had sufficient threads.  And there were only 6 OSTs total 126 RPCs per OSS.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

How does your rtt delay gets introduced for the test? Could it be that if there are more messages on the wire even at the same time, they are delayed more (aside from obvious bandwidth-induced delay, like bottlenecking a single message at a time with mandatory delay or something like this)?<br>
</blockquote><div><br>The RTT delay is handled by the Obsidian Longbow and was set symmetric to half the RTT on each end (I think they delay receive traffic only not transmit).  The data at 110+ ms seems to have a larger decay then the rest of the data so I'm not sure if someone was happening before that but the rest of the data seems consistent with what I've seen using real distance and not simulated delay, although I only have points to compare it to and not whole range of 0-200ms.  <br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
</div>Probably the difference is the one of GET vs PUT semantic in lnet. there's going to be at least 2 RTTs in any case. One RTT is the "header" RPC that tells OST "hey, I am doing this operation<br>
here that involves bulk io, it has this many pages and the descriptor is so and so", then server does another RTT to actually fetch/push the data (and that might actually be worse than one for one of the GET/PUT case I guess?)<br>
</blockquote><div><br>I need to look at this more but it seems to me that the read case should still be capable of completing in 1 RTT because the server can send the response as soon as it gets the request since all the MD info should be included with the request?<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> I don't have everything setup right now in our test environment but with a little effort I could setup a similar test if your wondering about something specific.<br>
<br>
</div>Would be interesting to confirm the amount of RPCs actually being processed on the server at any one time, I think.<br>
Did you try the direct IO too? Some older version of lustre used to send all outstanding directio RPCs in parallel, so if you did your IO as just a single direct IO write, the latency of that write should be around a couple of RTTs. I think that we still do this even in 1.8.5, so it would make an interesting comparison.<br>
</blockquote><div><br>I didn't try any direct IO but I certainly could.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Bye,<br>
<font color="#888888">    Oleg</font></blockquote></div><br>