On Sep 3, 2013, at 2:40 AM, Lukasz Janyst <[log in to unmask]> wrote:
> Hi Andy,
>
> On 03.09.2013 01:06, Andrew Hanushevsky wrote:
>> 1) All bytes are transferred through a single pipe. That means if I
>> have two clients and one is reading 1K blocks and the other is reading
>> 1M blocks the 1K block client suffers the same latency as if it had been
>> reading 1M blocks. Same is true for writing. One xrdcp can destroy
>> performance for everybody.
>
> You have kXR_oksofar responses that would split large reads into small chunks making it possible to interleave other responses. You use this quite extensively.
This still suffers from head-of-line blocking inherent in a TCP connection. For example, when you call sendfile() on a 1KB read which hits a slow disk, you may be blocking the 1KB read from the page cache from the next client.
>
>> 2) Should a TCP packet get dropped and we go into packet recovery
>> then all clients see the increased latency. Since we have everything
>> going through a single pipe the odds of that happening increase.
>
> True, but single packet loses rarely cause non-negligible performance issues. Multiple packet loses would affect all connections equally.
Yes and no. TCP is remarkably sensitive to packet loss + latency. Multiple TCP streams are likely going to get you an order-magnitude more performance in this case.
As a practical matter, on a WAN (even on R&D networks), your best bet is to have multiple TCP streams. It irritates me to no end - you'd think there would be a better transport protocol after 40 years of internet - but it's a fact of life.
I think it would be a quite interesting *experiment* to compare these things, however!
>
>> 3) Meta operations are, by their nature, serialized by the server.
>> That means they wpuld impact all clients whenever they occur. Since some
>> may take a bit of time to do there may be a substantial delay that
>> penalizes all clients that simply want to do I/O.
>
> I don't understand what you mean by this.
>
>> The extra overhead in doing authentication is no worse than the each
>> client contacting the server directly as would be the case without a
>> proxy. So, that argument is moot. In fact, most sites employ a simple
>> authentication scheme between a proxy and a server which makes the
>> overhead negligible compared to the downside of serializing all the
>> traffic through a single physical socket.
>
> It looks like Alja is using X509.
>
Auth is really a trivial overhead in this case.
>> A physical single socket severely limits any kind of parallelism in most
>> cases. Virtual streams buy you nothing in this case. The bytes are bound
>> to a single physical communication channel that works serially by its
>> design. That means performance is bound by the slowest client.
>
> So does a NIC and Ethernet.
However, NIC / ethernet do not suffer from head-of-line blocking; if the HTTP connection to Google stalls, your SSH session to lxplus is still usable.
Brian
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
|