Unless you have hardware acceleration associated with your GigE device
the cycles required to chop a up a one gigabit stream into ~1500
byte chucks has to come from the main processor. The harder your
processor works for ring 0 operations(generally hardware service
interrupt requests which muct be handled), the fewer processor cycles
are available for ring 3 (application, generally software interrupt
requests which can be deferred for higher priority processes) level
processes.
Stick an unintelligent GigE card in a box and you will need ~2Ghz
of processor just to service the interrupts associated with the service
of the network card and the IP stack at full throttle. You may
find that you need far less I/O than you perceive is the case.
It sounds like you will be decouping storage from playback, which
should offload load from the server (Video I/O is generally expensive
is using the built in CPU), which is good. There are only a finite
amount of cycles in your CPU and start stealing from video (or disk
or....) to service network and the result is harsh video and audio
drops.
Items to consider....
Most GigE adapters are backward compatible with 10/100 (and are
often labled 10/100/1000). Even a multiple 10/100 adapter is likely
to be more efficient than an unintelligent GigE interface because
all of these types of cards are co-processed and you could dedicate
one port to each replay unit and still have one port open for the
upload of data from a regular network (assuming a four port card).
Try the lower speed first. Since you will be using the one box
as a server, go for higher end components such as 10-15000 rpm hard
drives with intelligent caching controllers, make sure you use an
intelligent GigE adapter which can offload the framing and stack
service from the main processor on board. Have you considered a
dual Xeon for your server if using the onboard GigE so you'll have
cycles to burn? You should also be able to take advantage of any
OS you wish for the server as long as you can create a mount point
for your LINUX freevo replay units.
Ordinarily with streaming services I would advise clients to consider
the option of multicasted services which are more pipe efficient
than unicast streaming services. Users can subscribe to an existing
multicast service (one feed on the pipe), whereas they need to initiate
a new unicast service (multiple feeds of the data on the pipe).
I don't have enough knowledge on the components of freevo to say
whether the replay components can take advantage of an existing multicast
stream, although this would be a nice feature if Mom & Dad wanted
to check on what the kids are watching......).
I have two replayTV units in my home - my next unit will be a freevo
for which I purchases a an AOPEN motherboard with a tube output stage.
The two replay units do just fine passing data from one to the
other for replay in a 10Mbit switched network. (A 30 minute TV show
takes about 10 minutes to pass the network as an MPEG2 file.)
Just because GigeE is a built in solution does not mean that it is
the most efficient or the best solution.
James Pulley, iTest Solutions
At Tuesday, 27 May 2003, you wrote:
>I'm planning a server that will serve multiple set-top boxes (probably
no more
>then two or three). Most likley, not all would be active at the
same time,
>but it's possible. Each will most likely be viewing a different
program. I'm
>assuming that Gig-e will work better for this then 100Mbit, but
I'm not
>really sure.
>
>My Motherboard (Asus A7V8X) has built-in gig-e. Are you saying that
this will
>hurt my systems performance, even if I'm not filling up the pipe?
>
>-Mike
>
>On Tuesday 27 May 2003 06:41 am, James Pulley wrote:
>> Unless you have a "really nice" hardware-accelerated Gig-E card I
>> would go with a 100Mbit NIC instead. Usually to fill a given pipe
>> size requires 2x (x86) processor speed to fill a given pipe at
standard
>> ethernet frame sizes (no Jumbo Frames). So, to fill a gigabit
ethernet
>> pipe requires at least a 2Gigahertz processor. Performance Testing
>> is my profession. It is all too common that people will slap in
>> a Gig-E card and then starve their app for CPU cycles on the same
>> box.
>>
>> There are many codecs designed for mulicast that work very well in
>> T-1 and above pipe sizes. Any particular reason you need the gig-
>> E pipe (other than copying files faster?)
>>
>> James Pulley, iTest Solutions
>>
>> At Monday, 26 May 2003, you wrote:
>> >On Sunday 25 May 2003 06:51 am, Stian Davidsen wrote:
>> >> <snip>
>> >>
>> >> > The most important consideration
>> >> > is the PCI bus is only 33mbps, so you may have issues running
>>
>> say 2 tv
>>
>> >> > cards and something else like a firewire or mpeg encoder card
>>
>> at the same
>>
>> >> > time..
>> >>
>> >> The PCI bus is 132 MB/s = 1gbps.
>> >> So unless you use both a gigabit nic and a firewire card on
the same
>> >> bus, you're probably in the clear.
>> >
>> >How about a Gigabit nic and two tv cards? This is intended as a
>>
>> server, so
>>
>> >there won't be much in the way of video out, sound out, etc.
>> >
>> >-------------------------------------------------------
>> >This SF.net email is sponsored by: ObjectStore.
>> >If flattening out C++ or Java code to make your application fit in a
>> >relational database is painful, don't do it! Check out ObjectStore.
>> >Now part of Progress Software. http://www.objectstore.net/sourceforge
>> >_______________________________________________
>> >Freevo-users mailing list
>> >[EMAIL PROTECTED]
>> >https://lists.sourceforge.net/lists/listinfo/freevo-users
>>
>> ===================================================================
>> EASY and FREE access to your email anywhere: http://Mailreader.com/
>> ===================================================================
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: ObjectStore.
>> If flattening out C++ or Java code to make your application fit in a
>> relational database is painful, don't do it! Check out ObjectStore.
>> Now part of Progress Software. http://www.objectstore.net/sourceforge
>> _______________________________________________
>> Freevo-users mailing list
>> [EMAIL PROTECTED]
>> https://lists.sourceforge.net/lists/listinfo/freevo-users
>
>-------------------------------------------------------
>This SF.net email is sponsored by: ObjectStore.
>If flattening out C++ or Java code to make your application fit in a
>relational database is painful, don't do it! Check out ObjectStore.
>Now part of Progress Software. http://www.objectstore.net/sourceforge
>_______________________________________________
>Freevo-users mailing list
>[EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/freevo-users
>
===================================================================
EASY and FREE access to your email anywhere: http://Mailreader.com/
===================================================================
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Freevo-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-users
