[linux-cifs-client] Re: sequential read performance - read ahead ?

Sam Liddicott sam at liddicott.com
Tue Sep 16 21:45:21 GMT 2008


I meant to get this into the conversation earlier but my mobile phone 
wouldn't send email. (Darn MS WM6)

I've done quite a bit of work on read-ahead using the cifs proxy.

In cases where the network link would otherwise be idle it can make 
quite a difference.

The optimum transfer rate with optimal read ahead is close to the 
network link speed.

Normal performance without read ahead usually leaves the link idle for 
RTT*bandwidth.

At regular domestic DSL rates tuned read-ahead can save 25% to 50% of 
the normal load time, and at >100ms latencies the benefit can be much 
higher.
As MS showed at samba XP they have >1second RTT for 155Mb/s links, 
giving 15MB "storage" in transit. In such cases if you are not paying by 
the byte, and if the link has bandwidth to spare it can be worth reading 
many megabytes as soon as the file is opened.

If the link was never idle however, read-ahead gives no average 
performance gain (any gain is done by making other things worse) and can 
even make smb worse by creating a queue in the return direction of the 
samba connection (a queue of things the client hasn't asked for and may 
not even want) which can delay responses to other smb requests that may 
be important.

It's further complicated in that read-aheads on the same tcp connection 
must be regulated so the serer doesn't think the client is run-away (on 
account of the number of pending requests) and start throttling the client.

A "tuned" read-ahead reads only enough to keep the link full, which 
means co-operating with ALL network connections using the client 
downlink and the server uplink, something clearly non-trivial

Its a pathalogical problem I think, unless the server is on the same LAN 
as the client.

My conclusion is that read-aheads cannot easily be done in an "optimal" 
fashion at all, and it's hard to avoid getting wrong often.

I note, though that windows clients do read-ahead, maybe a simple 
calculation based on rtt/read-size (to sample most recent effective 
instantaneous bandwidth) would be the simplest safeish way to calculate 
how far ahead to read.

Sam


More information about the linux-cifs-client mailing list