Re: New DVB-Statistics API

[Julian Scheel <julian@jusst.de>]

Am 09.12.09 14:02, schrieb Mauro Carvalho Chehab:
> 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
>    

I don't think you can just take the average IPC rates into account for 
this. When doing a syscall the processors TLB cache will be cleared, 
which will force the CPU to go to the whole instruction pipeline before 
the first syscall instruction is actually executed. This will introduce 
a delay for each syscall you make. I'm not exactly sure about the length 
of the delay, but I think it should be something like 2 clock cycles.
>>> 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.
>    
The number of hardware I/Os is constant for both cases, so we do not 
need to discuss them as pro/con for any of the proposals.
>> 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.
>    
Imho the S2API would be slower when reading all data the ioctl fetches, 
due to the way the instructions would be handled.

Correct me, if I'm wrong with any of this.

Cheers,
Julian