From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Manu Abraham <abraham.manu@gmail.com>
Cc: Julian Scheel <julian@jusst.de>, linux-media@vger.kernel.org
Subject: Re: New DVB-Statistics API
Date: Wed, 09 Dec 2009 11:02:08 -0200 [thread overview]
Message-ID: <4B1F9FD0.4020702@redhat.com> (raw)
In-Reply-To: <1a297b360912090342r3c73496x3abe8ccba62b701@mail.gmail.com>
Manu Abraham wrote:
> On Wed, Dec 9, 2009 at 3:43 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Even with STB, let's assume a very slow cpu that runs at 100 Megabytes/second. So, the clock
>> speed is 10 nanoseconds. Assuming that this CPU doesn't have a good pipeline, being
>> capable of handling only one instruction per second, you'll have one instruction at executed
>> at each 10 nanoseconds (as a reference, a Pentium 1, running at 133 Mbps is faster than this).
>
> Incorrect.
> A CPU doesn't execute instruction per clock cycle. Clock cycles
> required to execute an instruction do vary from 2 cycles 12 cycles
> varying from CPU to CPU.
See the description of an old Pentium MMX processor (the sucessor of i586, running up to 200 MHz):
http://www.intel.com/design/archives/processors/mmx/docs/243185.htm
Thanks to superscalar architecture, it runs 2 instructions per clock cycle (IPC).
Newer processors can run more instructions per clock cycle. For example, any Pentium-4 processor,
can do 3 IPC:
http://www.intel.com/support/processors/pentium4/sb/CS-017371.htm
>> So, even on such bad hardware that is at least 20x slower than a netbook running at 1Gbps,
>> what determines the delay is the amount of I/O you're doing, and not the number of extra
>> code.
>
>
> The I/O overhead required to read 4 registers from hardware is the
> same whether you use the ioctl approach or s2api.
It seems you got my point. What will determinate the delay is the number of I/O's, and not the
amount of instructions.
> Eventually, as you have pointed out yourself, The data struct will be
> in the cache all the time for the ioctl approach. The only new
> addition to the existing API in the ioctl case is a CALL instruction
> as compared to the numerous instructions in comparison to that you
> have pointed out as with the s2api approach.
True, but, as shown, the additional delay introduced by the code is less than 0.01%, even on
a processor that has half of the speed of a 12-year old very slow CPU (a Pentium MMX @ 100 MHz
is capable of 2 IPC. My calculus assumed 1 IPC).
So, what will affect the delay is the number of I/O you need to do.
To get all data that the ioctl approach struct has, the delay for S2API will be equal.
To get less data, S2API will have a small delay.
Cheers,
Mauro.
next prev parent reply other threads:[~2009-12-09 13:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-08 9:16 New USB-Statistics API Julian Scheel
2009-12-08 12:24 ` New DVB(!!)-Statistics API Julian Scheel
2009-12-08 13:22 ` New DVB-Statistics API Mauro Carvalho Chehab
2009-12-08 21:46 ` Manu Abraham
2009-12-08 23:43 ` Mauro Carvalho Chehab
2009-12-09 11:42 ` Manu Abraham
2009-12-09 13:02 ` Mauro Carvalho Chehab [this message]
2009-12-09 22:12 ` Julian Scheel
2009-12-09 23:38 ` Mauro Carvalho Chehab
2010-02-03 9:49 ` New DVB-Statistics API - please vote Mauro Carvalho Chehab
2010-02-03 10:40 ` Hans Verkuil
2010-02-03 12:37 ` Manu Abraham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B1F9FD0.4020702@redhat.com \
--to=mchehab@redhat.com \
--cc=abraham.manu@gmail.com \
--cc=julian@jusst.de \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.