On Tue, May 15, 2012 at 01:04:36PM +0200, Alfredo Finelli wrote:
> - Wonderful emacs org-mode table :-) for a summary of average values:
>
> | Program | time (s) | speed (Mbit/s) | cpu % |
> |-----------------------+----------+----------------+-------|
> | Curl binary, no proxy | 297 | 4.407 | 1.59 |
> | apt-cacher, standard | 270 | 4.848 | 95.29 |
> | apt-cacher, 0.01 | 262 | 4.996 | 2.28 |
> |-----------------------+----------+----------------+-------|
>
>
>
> > I wonder if the timeout of 0.00001 is just too small for your
> > system. What version of perl and IO::Select do you have?
>
> perl 5.14.2-9
> perl-base 5.14.2-9
>
> > strace on the libcurl process on my system shows:
> >
> > select(8, [0], NULL, NULL, {0, 10}) = 0 (Timeout)
> > poll([{fd=2, events=POLLIN|POLLPRI}], 1, 0) = 0
> > clock_gettime(CLOCK_MONOTONIC, {567815, 68106232}) = 0
> > clock_gettime(CLOCK_MONOTONIC, {567815, 68133052}) = 0
> > clock_gettime(CLOCK_MONOTONIC, {567815, 68160152}) = 0
> > clock_gettime(CLOCK_MONOTONIC, {567815, 68186692}) = 0
> > select(8, [0], NULL, NULL, {0, 10}) = 0 (Timeout)
> > poll([{fd=2, events=POLLIN|POLLPRI}], 1, 0) = 0
> > clock_gettime(CLOCK_MONOTONIC, {567815, 69133499}) = 0
> > clock_gettime(CLOCK_MONOTONIC, {567815, 69160599}) = 0
> > clock_gettime(CLOCK_MONOTONIC, {567815, 69189654}) = 0
> > clock_gettime(CLOCK_MONOTONIC, {567815, 69216754}) = 0
> > select(8, [0], NULL, NULL, {0, 10}) = 0 (Timeout)
> >
> > The obvious significant difference from your strace are the calls to
> > clock_gettime. It looks to me as if select() on your system is not
> > observing the 10us timeout, but I don't know why. Can you test what is
> > the smallest timeout value that is observed?
>
> I have now a 35MB complete trace for the full running time and I can
> affirm that it contains not even one call to clock_gettime. The first
> 200 lines are in the attached file , the rest is very similar except at
> the end, after the download is finished.
>
> The developer manpages for system calls also contain a tutorial for
> select(), the page is called 'select_tut'. Not wishing to criticize
> anyone I quote from it:
>
> Many people who try to use select() come across behavior that is
> difficult to understand and produces nonportable or borderline
> results.
>
> It is easy to introduce subtle errors that will remove the
> advantage of using select(), so here is a list of essentials to
> watch for when using select().
>
> 1. You should always try to use select() without a timeout. Your
> program should have nothing to do if there is no data
> available. Code that depends on timeouts is not usually
> portable and is difficult to debug.
> [...]
>
> At least we know that it is difficult to debug :-).
Thanks.
>From a purely selfish apt-cacher point of view we don't call select()
>directly, it
is only through IO::Select. Although I am reluctant to deflect the
blame, I think this maybe a perl-base bug.
Could you try this script and play with the timeout value in
$select->can_read(). Obviously it should print an elapsed time for each
loop of the order of the can_read timeout. I get something of the
correct order right down to 1us (perl 5.10.1). What do you get?
Mark
#!/usr/bin/perl
use warnings;
use strict;
use IO::Select;
use IO::Socket::UNIX;
use Time::HiRes qw /clock_gettime CLOCK_REALTIME/;
my $socket = '/tmp/test.socket';
unlink $socket;
my $server = IO::Socket::UNIX->new(Proto => 'tcp',
Local => $socket,
Listen => SOMAXCONN,
Reuse => 1)
or die "Unable to create listener socket: $!";
my $select = IO::Select->new($server)
or die "Unable to create select: $!";
my $count = 10;
while ($count--) {
my $start = clock_gettime(CLOCK_REALTIME);
my $ret = $select->can_read(0.0001);
my $end = clock_gettime(CLOCK_REALTIME);
print $end-$start, " seconds elapsed\n";
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
