From: "Daniel Glöckner" <daniel-gl@gmx.net>
To: Jean Delvare <jdelvare@suse.de>
Cc: video4linux-list@redhat.com, v4l-dvb-maintainer@linuxtv.org
Subject: Re: bttv driver questions
Date: Mon, 1 Sep 2008 14:35:44 +0200 [thread overview]
Message-ID: <20080901123544.GA447@daniel.bse> (raw)
In-Reply-To: <200809011144.54233.jdelvare@suse.de>
[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]
On Mon, Sep 01, 2008 at 11:44:53AM +0200, Jean Delvare wrote:
> > It's not that much faster. Of the 250MB/s a lot is lost to overhead,
> > especially when there are mostly short packets.
>
> The very same is true of the PCI side, isn't it? Out of the 133 MB/s
> of PCI bandwith I don't expect to get more than 100 MB/s effective.
You are right. PCI is only faster for transfers of 4 bytes or less.
The throughput formula for memory writes without waitstates on PCI is
400/3*x/(x+8) MB
and for memory writes with infinite credit without ECRC on PCIe
250*x/(x+20) MB,
where x is the burst size and must be a multiple of four in both
protocols.
> Actually there may be up to 8 masters. Latency counter values of 254
> and 20 are rather extreme values.
The equilibrium pattern for latency values between 20 and 254 at a
trigger of 4 in my simulation is the same.
> I guess that your computations assume that the BT878 returns the bus
> control as soon as its FIFO is empty?
Yes
> Not sure what you call "maximum fill"? If the FIFO triggers at 32, I
> have a hard time believing that it always gets the control within the
> next 0.17 µs (2 pixels).
There is an initial phase of about 2000 PCI cycles where the FIFO fill
may be higher (this is not the case for a trigger of 4). Afterwards they
acquire the bus in a uniform pattern and stay below the quoted values.
At a trigger of 32 the bus is idle between requests, so access is granted
immediately.
> Again, I fail to see how we care about the idle cycles. I agree that
> we don't have to pay attention to having a lot of them, because the
> BT878s are alone on that side of the bridge, but we also don't need
> to maximize the "raw" bus usage. What matters is that the bus can
> take the bandwidth peaks and that the FIFOs do never overflow.
It's not about maximizing the bus usage. I suggest to use a low trigger
to keep the FIFO usage low. The high bus usage is just a side effect,
which can be neglected if the Bt878s are on a secondary bus (and either
the primary bus is faster or the bridge can merge writes).
> Care to share your simulation tool with me? This seems to be a very
> valuable tool for the problem I am trying to solve.
Attached.
Cycle description, FIFO overflows and periodic bus idleness estimations
on stderr. FIFO fill for all masters in every cycle on stdout.
Daniel
[-- Attachment #2: pcisim.c --]
[-- Type: text/plain, Size: 2891 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
static int busstate;
static int nextbusstate;
static int gnt;
static unsigned long long clk;
#define N 5
static struct master {
int req;
int fifofill;
int trigger;
int latval;
int latcnt;
int phase;
unsigned long long step; /* fixed point 32 bit mantissa */
unsigned long long accu;
} masters[N];
static void simulate(int i)
{
masters[i].fifofill+=masters[i].accu>>32;
masters[i].accu&=0xffffffff;
if(masters[i].fifofill>140) {
fprintf(stderr,"%llu [%i dropped %i]\n",clk,i,masters[i].fifofill-140);
masters[i].fifofill=140;
}
if(busstate==0 && gnt==i && masters[i].fifofill>=masters[i].trigger) {
nextbusstate=1;
masters[i].phase=1;
}
if(busstate==1) {
switch(masters[i].phase) {
case 1:
masters[i].phase=2;
masters[i].latval=masters[i].latcnt;
fprintf(stderr,"%llu %i addr\n",clk,i);
break;
case 2:
masters[i].fifofill--;
fprintf(stderr,"%llu %i data, %i remaining\n",clk,i,masters[i].fifofill);
}
if(masters[i].latval>0)
masters[i].latval--;
if(masters[i].phase && (masters[i].fifofill==1 || (!masters[i].latval && gnt!=i)))
nextbusstate=2;
}
if(busstate==2 && masters[i].phase) {
masters[i].fifofill--;
fprintf(stderr,"%llu %i final data, %i remaining\n",clk,i,masters[i].fifofill);
if(gnt==i && masters[i].fifofill>=masters[i].trigger) {
nextbusstate=1;
masters[i].phase=1;
} else {
nextbusstate=0;
masters[i].phase=0;
}
}
masters[i].req=(masters[i].fifofill>=masters[i].trigger || (masters[i].phase && nextbusstate==1 && masters[i].fifofill>1));
masters[i].accu+=masters[i].step;
}
int main()
{
int i;
unsigned long long idle;
int wasactive;
clk=idle=0;
busstate=0;
gnt=0;
wasactive=0;
srandom(time(0));
for(i=0;i<N;i++) {
masters[i].req=0;
masters[i].trigger=4;
masters[i].fifofill=random()%masters[i].trigger;
masters[i].latcnt=64;
masters[i].phase=0;
#define PAL(w) (((unsigned long long)(w)<<31)*3/5200)
#define NTSC(w) (((unsigned long long)(w)<<31)*30/52856)
masters[i].step=NTSC(640);
masters[i].accu=random()%masters[i].step;
}
while(1) {
int nextgnt=gnt;
if(wasactive) {
for(nextgnt=(gnt+1)%N;nextgnt!=gnt;nextgnt=(nextgnt+1)%N)
if(masters[nextgnt].req)
break;
if(nextgnt!=gnt)
wasactive=0;
}
for(i=0;i<N;i++) {
printf("%i%c",masters[i].fifofill,i+1==N?'\n':'\t');
simulate(i);
}
gnt=nextgnt;
if(!busstate && nextbusstate)
wasactive=1;
clk++;
if(!nextbusstate) {
if(busstate)
fprintf(stderr,"%llu turnaround\n",clk);
else {
fprintf(stderr,"%llu idle\n",clk);
idle++;
}
}
if(!(clk&511))
fprintf(stderr,"[%llu bus idle %f%%]\n",clk,100.0*idle/clk);
busstate=nextbusstate;
}
return 0;
}
[-- Attachment #3: Type: text/plain, Size: 164 bytes --]
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
next prev parent reply other threads:[~2008-09-01 12:36 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200808251445.22005.jdelvare@suse.de>
2008-08-26 0:40 ` [v4l-dvb-maintainer] bttv driver questions Andy Walls
2008-08-26 23:29 ` Daniel Glöckner
2008-08-27 2:20 ` Trent Piepho
2008-08-27 2:59 ` Robert William Fuller
2008-08-28 19:43 ` Trent Piepho
2008-08-27 3:45 ` Andy Walls
2008-08-28 19:48 ` Trent Piepho
[not found] ` <200808281611.38241.jdelvare@suse.de>
2008-08-28 20:20 ` Daniel Glöckner
2008-08-28 21:42 ` hermann pitton
[not found] ` <200808301201.47561.jdelvare@suse.de>
2008-08-30 15:12 ` Daniel Glöckner
2008-08-31 16:37 ` Andy Walls
[not found] ` <200809011144.54233.jdelvare@suse.de>
2008-09-01 12:35 ` Daniel Glöckner [this message]
[not found] ` <200809012126.06532.jdelvare@suse.de>
2008-09-01 22:54 ` Daniel Glöckner
[not found] ` <200809021109.31007.jdelvare@suse.de>
[not found] ` <200809021305.12318.jdelvare@suse.de>
2008-09-03 22:29 ` Daniel Glöckner
[not found] ` <200809051436.18549.jdelvare@suse.de>
2008-09-05 15:51 ` Daniel Glöckner
2008-09-05 19:16 ` [v4l-dvb-maintainer] " Trent Piepho
[not found] ` <200808281658.28151.jdelvare@suse.de>
2008-08-29 12:09 ` Andy Walls
2008-08-29 22:23 ` Trent Piepho
2008-08-30 0:10 ` Daniel Glöckner
[not found] ` <200808300954.19361.jdelvare@suse.de>
2008-08-30 16:44 ` Daniel Glöckner
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=20080901123544.GA447@daniel.bse \
--to=daniel-gl@gmx.net \
--cc=jdelvare@suse.de \
--cc=v4l-dvb-maintainer@linuxtv.org \
--cc=video4linux-list@redhat.com \
/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.