Gigabit is nice, but usually not required. Stick with 100Mb. If you really need more speed (and your cards/switch support it), do channel bonding.
Transfer any ~800MB divx file between two Windows boxs (for examples sake) on a 100MB switched network and you'll notice it takes very little time. Considering that most ~800MB divx movies are at least 1.5 hours of video, you have a lot of room to breath here. Even using a codec that doesn't compress the video as much as divx and you'll still be happy. The only trouble you'll run into is latency when the stream first starts. Assuming the receiver has a large enough video buffer you'll be fine. ~Rob -----Original Message----- From: James Pulley [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 27, 2003 11:49 AM To: [EMAIL PROTECTED] Subject: Re: [Freevo-users] Parts for First freevo 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 ------------------------------------------------------- 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
