[LAD] [LAU] cancelling I/O with libsndfile

Paul Davis paul at linuxaudiosystems.com
Thu Jul 7 14:39:53 UTC 2011


On Thu, Jul 7, 2011 at 10:28 AM, Dan Muresan <danmbox at gmail.com> wrote:
> Hi Paul, thanks for replying.
>
>> to. It seems as though you think there is a difference in the
>> throughput when you read from a filesystem using st_blksize or some
>> other size close to it, and that you either have or could measure it.
>
> I was saying the man page provides the definitive guide to structuring
> request sizes, and sndfile breaks the rules. The rules are there for
> NFS, NTFS, EXT3, JFS, FTPS, SSHFS etc, PLUS future drivers.

I don't consider man pages definitive guides for *anything*. Not even
for system calls that are part of POSIX.

If you want to measure this, go ahead. If what is described on the man
page matches what you find, that's great, and it will be like (as a
rough guess) 90% of the rest of the OS API. But if it doesn't, don't
be suprised. One of the things about open source is that if you
actually spend time reading (in this case, kernel) source, you rapidly
come to discount man pages and other documentation as sources of
definitive information. This might be a bad development (there are
some good arguments to this effect), but it doesn't change the fact
that it happens.

However, I think you're missing Erik's point. He's not claiming that
there isn't a "rule" (your term, though I think its inappropriate) for
setting the i/o size based on st_blksize. He's saying that if you
break the "rule" in the way that is being discussed, you will find it
hard to see any effect of doing so. He may have also explained why
this is likely to be the case in the future too (or I've just imagined
that part). So the situation is not:

   * do it this way, or it will break

its more like:

   1) there's a reason to use value A
   2) there's a different reason to use value B
   3) there's no measurable difference in performance between A and B,
and thus the choice between 1+2 must be made on some other grounds

>> Erik is saying that he doesn't believe that you could measure the
>> difference.
>
> Well, who knows? To be future-proof one must follow standards.

Future-proof and standards surely have almost no relationshiop to each
other. The future is where today's standards are changed, or
discarded. The ghosts of  thousand dead standards will back me up on
this one.

> Now, have you measured that reading exactly 10,000 bytes at a time was
> optimal? That would be an argument against st_blksize being
> meaningful.

Variations of less than about 500 bytes made no statistically
significant difference to measured throughput.

> So you *do* pay attention to even block sizes in Ardour :)

Sure, but its because we care about performance, not standards or
"rules". And I measured it first.



More information about the Linux-audio-dev mailing list