[linux-dvb] Re: Network: a new hope

[Emard <emard@softhome.net>]

HI people,

I have verified DMA and it works true 100% error free in my case
and there is absolutely no 32-bit DWORD skippings

While DMA doesn't skip DWORDs, dvb_net shows considerable amount of 
packet loss for PID_Bandwidth > TS_Bandwidth/2

I have P4 with well working concurrent PCI switch implementation,
and I didn't need to tune PCI latency (my bios sets it to 32 for SAA7146).

It was tested on kernel 2.4.22 and latest cvs sync from today.

Regarding the recommendation to test, the parameters

> TS_WIDTH  = 376 (2*188)
> TS_HEIGHT = 512 (1024/2)

were already there in the dvb-kernel :), TS_HEIGHT=1024 is not used 
in recent dvb-kernel 

> With this BRS configuration, the SAA7146A produces the least "DMA glitches"
> on my machine, and even allows me to use a burst of 128 Dwords (with a
> threshold of 32 Dwords), which was _not_ possible with
> Width=188/Height=1024!
> 
> I suspect this configuration is working best, because it has no number
> greater than 512 in it, and the BRS seems to have an issue with line or
> pixel counts exceeding 511/512...

You can try using something like
setpci -s xx:xx.x LATENCY_TIMER=0x40
or other values for budget card, disk pci adapter and other pci devices
that may be in high bandwidth usage. General rule is increase budget's
latency to about 0x40 and lower any other latencies (0x20 or 0x10) as long
as the PC can still run stable.


**** MAIN ISSUE: DMA verification ****

> I'd suggest putting the "DMA verification" code in place first, though, and
> _then_ starting to change the BRS configuration values to see if it indeed
> improves the results.

I have used this strategy: read the pointer value of the DWORD in dma buffer
and write the address of DWORD into the DWORD itself (using appropriate cast's). 
This is not true random generation but for the test it was sophisticated enough 
to prove there were no skipped DWORD's.

Here's the patch:

--- budget-core.c.orig	2003-11-07 20:35:40.000000000 +0100
+++ budget-core.c	2003-11-07 20:34:47.000000000 +0100
@@ -67,6 +67,7 @@
         u8 *mem = (u8 *)(budget->grabbing);
         u32 olddma = budget->ttbp;
         u32 newdma = saa7146_read(budget->dev, PCI_VDP3);
+        u32 overwrite;
 
         /* nearest lower position divisible by 188 */
         newdma -= newdma % 188;
@@ -82,11 +83,32 @@
         if (newdma > olddma) { /* no wraparound, dump olddma..newdma */
                         dvb_dmx_swfilter_packets(&budget->demux, 
         	                mem+olddma, (newdma-olddma) / 188);
+        	        for(overwrite = olddma; overwrite < newdma; overwrite += 4)
+        	        {
+        	        	if( *((u32 *)(mem + overwrite)) == (u32)(mem + overwrite) )
+        	        		printk("stale data found in DMA window at 0x%08x\n", overwrite);
+				else
+					*((u32 *)(mem + overwrite)) = (u32)(mem + overwrite);
+			}
         } else { /* wraparound, dump olddma..buflen and 0..newdma */
 	                dvb_dmx_swfilter_packets(&budget->demux,
         	                mem+olddma, (TS_BUFLEN-olddma) / 188);
                         dvb_dmx_swfilter_packets(&budget->demux,
                                 mem, newdma / 188);
+        	        for(overwrite = olddma; overwrite < TS_BUFLEN; overwrite += 4)
+        	        {
+        	        	if( *((u32 *)(mem + overwrite)) == (u32)(mem + overwrite) )
+        	        		printk("stale data found in DMA window at 0x%08x\n", overwrite);
+				else
+					*((u32 *)(mem + overwrite)) = (u32)(mem + overwrite);
+			}
+        	        for(overwrite = 0; overwrite < newdma; overwrite += 4)
+        	        {
+        	        	if( *((u32 *)(mem + overwrite)) == (u32)(mem + overwrite) )
+        	        		printk("stale data found in DMA window at 0x%08x\n", overwrite);
+				else
+					*((u32 *)(mem + overwrite)) = (u32)(mem + overwrite);
+			}
         }
 }
 

I left it running for over 20 minutes on netsystem 12721Mhz and I haven't
observed a single stale data dword in the buffer. The algorithm works,
e.g. if you replace (u32)(mem + overwrite) with just (u32)(overwrite) 
then it will print some stale data every 10-60 seconds because simple low 
values can occur more frequently.

On the other hand, on this TS dvb_net shows significant corruption of order
of 20% packets being lost, and I think that budget demux and dvb_net should
be put into the stress verification as well.

It would be nice if we could capture problematic TS dump and replay it into
the demux to be able to single-step in order to pinpoint where and how exactly 
do the network packets loose themselves

Emard


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.