[pvrusb2] Problem with wintv-hvr-1950
Mike Isely
isely at isely.net
Tue Mar 10 23:33:35 CDT 2009
On Tue, 10 Mar 2009, Roger wrote:
> On Tue, 2009-03-10 at 08:37 -0500, Mike Isely wrote:
>
> > > root at beagleboard:/# cp /dev/video0 /home/root/test.mpeg
> >
> > I usually use 'cat' here out of habit, but the 'cp' command should work
> > (and I doubt that using 'cp' could result in the problems below).
>
> The old behavior of cp would try coping the device file to the new
> location, which would obviously fail.
Really? Maybe a cp -a would do that, but a plain vanilla cp?...
>
> Interesting that cp can now be used to "cat" a device file.
>
> -rwxr-xr-x 1 root root 31K Aug 5 2008 /bin/cat
> -rwxr-xr-x 1 root root 76K Aug 5 2008 /bin/cp
What does that listing have to do with anything?
>
> Using cp instead of cat is going to cost you more then twice the memory.
> And, again although negligible, it might cost a few extra CPU cycles
> each time it loops.
You have to consider things like this in the proper context. On a
modern computer (e.g. anything 386 class or better - perhaps 1994 or
better) the staging memory used by a command like cp is going to be
trivial compared to everything else going on. Also, we're copying data
whose rate is completely limited by the bit rate of the hardware (e.g.
20Mb/sec worst case, 6Mb/sec typical) and that rate is a fly-speck
compared to the overhead of perhaps another buffer copy. So extra
buffer copies aren't really going to hurt anything. If this were an
uncompressed HD stream that would be a different matter of course, but
it isn't. An old 30MB RLL hard drive from 1987 could sustain this rate
:-) Plus how do you know that cp will cost twice the memory? Whether
it's cat or cp, the data still has to take one trip in and out of user
space, so that's 2 buffer copies no matter what one might do.
I'd be surprised if there were any measurable performance difference
between the two when reading pvrusb2-generated live data.
-Mike
--
Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
More information about the pvrusb2
mailing list