Rodney M. Dyer wrote: > At 02:28 PM 12/17/2007, Jeffrey Altman wrote: >> For each file operation CIFS sends anywhere from three to five requests. >> As a result there is significant overhead that increases the round trip >> time and limits the overall throughput. > > What I'm getting at is that once a 100 MB file is opened and is being > actively read from the server, if at any time your CPU is idle op'ing, > waiting on the file contents from the server, then there is nothing you > can do to improve on that. CPUs and memory bandwidth are so fast these > days that the biggest "cost" is in I/O where the CPU sits and idles its > time away. The only thing you do by improving the fetch/request > algorithm is make Windows more efficient at performing other application > operations, not your own.
That is not true at all. If the CIFS interface reads 64KB at a time and refuses to request the next 64KB until the previous one has been delivered and the CM is reading 1MB at a time, then there is significant overhead caused by the CIFS interface. Why should I lose hundreds of microseconds per 64KB simply because the CIFS protocol is dumb? >> > On a related note, I've always wondered why the AFS file servers do not >> > have "read cache" on the server side, so when one person requests a >> > file, the second person sees the same file from the servers cache. Or >> > is that handled by the server OS cache (via the swap)? >> >> I would hope your file server's operating system provides file caching. > > Block caching, not file caching. The problem here is that the OS cache > can't see inside the contents of the vicep to perform file cache > operations. You wouldn't do file caching in the file server. you would perform block caching. I'm not going to cache a 250GB file, I'm going to cache that parts of the file that have been used recently. >> And when you copy the MSM or MSI to local disk it works or when you run >> the install from a .readonly volume it works from a volume in which >> the client user only has 'rl' privileges. > > Not always. The previous error mentioned in the last message was from > just such a volume. Then file a bug report because otherwise I have no idea I should be looking for issues. >> If you try installing from a read/write volume and the application >> can't obtain the lock it wants, you get that error. >> >> We don't have byte range locking on the file servers. When we do, this >> will get better. >> >> In the meantime, don't use read/write volumes for distribution of >> .MSI/.MSM packages. > > We never do that, we always use "RO" replications for distribution of > application packages. And the access is usually "system:anyuser rl" or > "install_account rl". There should be no locking issues here. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
