Do they even make 1Gbs hubs? That is the craziest idea I've ever heard of. Why spring for 1Gbs if your just gonna end up using a hub? Stick with a switch!
~Rob -----Original Message----- From: Mike Payson [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 27, 2003 8:09 PM To: [EMAIL PROTECTED] Subject: Re: [Freevo-users] Parts for First freevo So, to clarify, are you saying that running at Gig speeds, the card will use up lots of cycles, regardless of the actual bandwidth used? Also, I think you are saying that using it in 10/100 mode will not use up the extra cycles? I have no problem using it that way (it's how everything is set up now since I haven't sprung for the Gig hub yet), but I was concerned that down the road I might run into bandwidth issues. It doesn't sound like that is going to be a big problem, though. On Tuesday 27 May 2003 11:49 am, James Pulley wrote: > 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 ------------------------------------------------------- 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
