Mailing List Archive

On 31 Oct 2002 at 1:36, Robert Middleswarth wrote:

> As some who has worked with 10 Mbps ethernet it isn't 100 Mbps yes
> wouldn't a problem unless you try to also xfer a saved image at the same time.

Or maybe something along the lines of Videolan

http://www.videolan.org/intro.html

--
Harondel J. Sibble
Sibble Computer Consulting
Creating solutions for the small business and home computer user.
help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com
(604) 739-3709 (voice/fax) (604) 686-2253 (pager)

On 30 Oct 2002 at 19:28, Robert Kulagowski wrote:

> Harondel, want to put together a combined Readme for Mandrake
> 8.x/9.0?

Heh, sure, however that'd mean I'd have to install MDK 9.0 just to make sure,
I understand all the instructions and that they worked for me. That won't
happen anytime soon (prolly several weeks) as I don't have a machine that's
not dedicated to some task that I can currently spare.

Mind you, I do have a Duron 750 cpu lying around from my upgrade of my MythTV
box and 512mb PC133 is wholesale cdn$80 and I can get one of the ECS KT333
boards for about cdn$90.....

Hmmm.....

Oh great, just what I need, _another_ computer ;-)


--
Harondel J. Sibble
Sibble Computer Consulting
Creating solutions for the small business and home computer user.
help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com
(604) 739-3709 (voice/fax) (604) 686-2253 (pager)

Harondel J. Sibble wrote:

>Hmmm.....
>
>Oh great, just what I need, _another_ computer ;-)
>
>
I know what you mean I have 9 working computer right now and setting up
a 10th for my mythtv testing/development server.

Robert Middleswarth

Craig McLaughlin wrote:

>On Wed, 2002-10-30 at 22:29, Robert Middleswarth wrote:
>
>
>>You are right that 1 Well Comprised Video Signal could be sent from a
>>Video Sever to a Video client without to much trouble. but we aren't
>>talking about that. We are talking about multipule pc talking back and
>>forth. So 1 PC could be asked to Xfer Saved data and Xfer Live Data and
>>Receive Live Data using a Codec that was designed for speed not size.
>> Althought we are talking about 100 based network cards they do start to
>>slow down in the 3-4 Meg range. Granted if you are talking about 1
>>Machine for Encodeing and 1 Machine that only displayed then yes there
>>would be no problem but that isn't what Mythtv is doing at this time and
>>if I read right not what Robert Kulagowski was talking about.
>>
>>
>
>100Mbps NICs slow down in the 3-4 Meg range? What kind of environment
>have you seen *that* in? I've seen that kind of poor performance on
>some older machines running Win9x, but my little pentium 166 firewall is
>routinely asked to push upward of 30, and handles it just fine... I
>suspect you may be seeing IP stack issues and not hardware issues...
>
>I regularly toss very large datasets around my network here, and often
>saturate my 100Mbps switch without too much trouble (note: my 100Mbps
>switch is actually a cheapo one that only has a 200Mbps backplane).
>
>
I just tried this at home I xfer 3 7??M files from a Redhat 7.3 Box to a
Redhat 8.0 Box and my Xfer rates were 5mb accroding to the FTP Client.
NFS might be faster then FTP but still the max I am getting is 5mb over
my cheapo switch and intel / reltek 8139 cards.

If you use the rtjpeg codex which produces files optmized for Speed not
size you aren't going to be able to do more then 2 streams. If I am
rembering correctly I have seen number for 2.5 to 3.33 megs for MPEG4 so
if you say only 3 Megs for rtjpeg and say get around 6 Megs can be
xfered then 2 Stream would work fine but more then that would require
some form of load balancing multi-nic card. If I screwed up the number
some place let me known as conversion between Bytes and Bits get
confusing and could make my number off by a factor of 8.

After running that test I was think there might be some limits based on
HD Speed and I think both machines have DMA off so that could be
improved. However I doubt it will go from 5 to 30.

Hi Robert,

> I just tried this at home I xfer 3 7??M files from a Redhat 7.3 Box to a
> Redhat 8.0 Box and my Xfer rates were 5mb accroding to the FTP Client.
> NFS might be faster then FTP but still the max I am getting is 5mb over
> my cheapo switch and intel / reltek 8139 cards.

1. Your FTP is almost certainly disk-bound, not net-bound.
2. FTP usually reports results in megabytes, not megabits, so check this.
3. Unless something is really old or broken in your network, you should be
able to expect to achieve close to full network rates for the proposed
application (multiple clients sending to/from a file server) from the
network cards/stacks.

So if we take 4 mega_bits_ per second for the compressed video stream, we
could have a home PVR network with, say, 2 recorders and 4 viewers running
simultaneously for a total of 24 megabits using only 25% of our network.
The average IDE drives will be the bottleneck long before the network.

In '97 using PPro 200s and run of the mill 100TX cards/hubs I wrote an app
that just dumped video/audio directly from the grabber to the net using
multicast udp, and on the other end reassembled frames and dumped them to
the screen/sound card. At 320x240 this took ~40mbps. The hardware had no
trouble whatsoever handling this. Today's systems won't even blink.

Jaime

On Friday 01 November 2002 04:52 pm, Robert Middleswarth wrote:
> I just tried this at home I xfer 3 7??M files from a Redhat 7.3 Box to a
> Redhat 8.0 Box and my Xfer rates were 5mb accroding to the FTP Client.
> NFS might be faster then FTP but still the max I am getting is 5mb over
> my cheapo switch and intel / reltek 8139 cards.
>
> If you use the rtjpeg codex which produces files optmized for Speed not
> size you aren't going to be able to do more then 2 streams. If I am
> rembering correctly I have seen number for 2.5 to 3.33 megs for MPEG4 so
> if you say only 3 Megs for rtjpeg and say get around 6 Megs can be
> xfered then 2 Stream would work fine but more then that would require
> some form of load balancing multi-nic card. If I screwed up the number
> some place let me known as conversion between Bytes and Bits get
> confusing and could make my number off by a factor of 8.
>
> After running that test I was think there might be some limits based on
> HD Speed and I think both machines have DMA off so that could be
> improved. However I doubt it will go from 5 to 30.

It takes roughly 2 minutes 20 seconds to transfer a 1.4 gigabyte file (a one
hour show) using ftp from my mythtv box to my webserver. The webserver's got
a _slow_ disk, too, maxes out at 14MB/s according to hdparm. Anyway, that's
10.6 megabytes/sec, only something like 25.8 times more than the ~420
*kilobytes*/sec that the stream would require to transfer/playback the file
live. I don't think there'll be any problems transfering a few files live to
different settop boxes, if that's what you wanted to do.

If you don't have DMA turned on, you're limited in transferring large amounts
of data to disk speed. Which, without DMA turned on, is usually painfully
slow, as you've just seen.

Isaac

On Fri, 2002-11-01 at 13:52, Robert Middleswarth wrote:
> >I regularly toss very large datasets around my network here, and often
> >saturate my 100Mbps switch without too much trouble (note: my 100Mbps
> >switch is actually a cheapo one that only has a 200Mbps backplane).
> >
> >
> I just tried this at home I xfer 3 7??M files from a Redhat 7.3 Box to a
> Redhat 8.0 Box and my Xfer rates were 5mb accroding to the FTP Client.
> NFS might be faster then FTP but still the max I am getting is 5mb over
> my cheapo switch and intel / reltek 8139 cards.

I strongly suspect that you're seeing 5M BYTES/s, not 5M BITS. As James
da Silva pointed out, many FTP clients these days report bytes, not
bits. So 5MB ~~ 40Mbits, not even counting things like TCP overhead.
One way to check would be to time the transfers and do the math by hand.

> If you use the rtjpeg codex which produces files optmized for Speed not
> size you aren't going to be able to do more then 2 streams. If I am
> rembering correctly I have seen number for 2.5 to 3.33 megs for MPEG4 so
> if you say only 3 Megs for rtjpeg and say get around 6 Megs can be
> xfered then 2 Stream would work fine but more then that would require
> some form of load balancing multi-nic card. If I screwed up the number
> some place let me known as conversion between Bytes and Bits get
> confusing and could make my number off by a factor of 8.

Check your math, as I suggest above. And your systems, as suggested
below. I mean, if you want to get a multi-nic network in place, and
load-balance (don't do it in hardware, you can set it up with something
like firehose, as others have suggested), that's fine... but why waste
the money and complicate things that aren't that complicated?

> After running that test I was think there might be some limits based on
> HD Speed and I think both machines have DMA off so that could be
> improved. However I doubt it will go from 5 to 30.

Well, perhaps you should try it before you decide:

DMA off:
/dev/hdb1:
Timing buffered disk reads: 64 MB in 7.55 seconds = 8.48 MB/sec

DMA on:
/dev/hdb1:
Timing buffered disk reads: 64 MB in 1.98 seconds = 32.32 MB/sec

(This is just from one system, only tweaking the DMA flag in hdparm, and
only doing read tests... I trust it's sufficient... also, note that this
is Bytes, not bits.)

Also, with regards to codec selection; I'm regularly playing DVDs from
the drive in my laptop which is NFS mounted to one video display box
(which plays the disc using mplayer). Network utilization shows about
6-10Mbits/s. It's running over an 802.11a link to the AP, which then is
on the 100Mb switch.

I really don't know what else to do / say. Your issue appears to be in
your particular setup, which isn't usual. The math and my and others'
experiences show that you *can* run multiple streams around a LAN
without problems or exotic hardware.

--Craig

How about something simple, like a mythbackend and a mythfrontend? The
backend will take care of the recording from the video capture card,
encoding, etc. The frontend does the GUI, decoding, etc. The frontend
machine can even be a thin client, since the files, etc will be stored
on the backend machine. I haven't looked at the code yet, but I can't
imagine that it would that difficult, since I think everything is in
different threads anyway. Create some simple TCP server on the backend
that will send the recorded data when requested and the frontend can
have a little buffer to handle network hiccups... If I find the time
this week, I might play with this.

(I have a personal motivation for this, since I have two machines that
cannot handle 640x480 record and playback simultaneously with mpeg4.
Both are capable of one function full-resolution, but I would want both
functions at that resolution at the same time.)


Robert Kulagowski wrote:

>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Isaac, do you have thoughts on how you're going to proceed? I've
>been thinking of "nice to have" features. Stream of thought stuff
>here...
>
>...
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
>
>iQA/AwUBPcABXPc1NpCTlP0JEQK46ACguCX9LhiIkgXQZE/0hLmkAvYAzSEAoM2a
>EwJLfyqBBIoYmAxf0Wu2KO8S
>=hX7H
>-----END PGP SIGNATURE-----
>
>
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I just tried this at home I xfer 3 7??M files from a Redhat
> 7.3 Box to a
> > Redhat 8.0 Box and my Xfer rates were 5mb accroding to the
> FTP Client.
> > NFS might be faster then FTP but still the max I am getting
> is 5mb over
> > my cheapo switch and intel / reltek 8139 cards.

I know for a fact that the Linux IP stack can push 88 Mbps sustained
using TCP on non-exotic ethernet hardware, so that will give you 11
megabytes a second.

If we assume that you are in fact having problems that aren't related
to math, then this appears to be a classic case of duplex mismatch.
If you really think that your hardware isn't working correctly, and
that you're not getting adequate performance out of 100Mbps, then
make sure you force everything to full duplex.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPcaH8vc1NpCTlP0JEQJOSACfVJc7Qmq+I2XvKcyjxY6KOVXhVEQAn1l6
hHqXo6OE1ZPprYcPNYkY2z6T
=LvcV
-----END PGP SIGNATURE-----

On Sunday 03 November 2002 03:56 pm, rob wrote:
> How about something simple, like a mythbackend and a mythfrontend? The
> backend will take care of the recording from the video capture card,
> encoding, etc. The frontend does the GUI, decoding, etc. The frontend
> machine can even be a thin client, since the files, etc will be stored
> on the backend machine. I haven't looked at the code yet, but I can't
> imagine that it would that difficult, since I think everything is in
> different threads anyway. Create some simple TCP server on the backend
> that will send the recorded data when requested and the frontend can
> have a little buffer to handle network hiccups... If I find the time
> this week, I might play with this.
>
> (I have a personal motivation for this, since I have two machines that
> cannot handle 640x480 record and playback simultaneously with mpeg4.
> Both are capable of one function full-resolution, but I would want both
> functions at that resolution at the same time.)

That's pretty much the method I was planning on -- just making one of the
backend boxes the 'master' and able to coordinate multiple other backend
boxes, if the user feels like setting them up.

Isaac

James da Silva wrote:

>So if we take 4 mega_bits_ per second for the compressed video stream,
>
>
my numbers are off by a factor of 8. Yes there can be some tuning and I
intend to do that with my systems but my mistake was in that I think in
BYTES not bits FTP uses BYTES and so does all the numbers I tend to
think in. Which means that 4 Megbits = 500 Kilobytes whitch means that
my test xfer could have worked with 10 Streams or more not 2.

Robert