Gigabit Ethernet has some issues if not tweaked.....but default the MTU size of a ethernet frame with Gigabit ethernet is still 1500bytes. So if you fire heaps of packets down a gig link the machine ends up with lots (and lots) of interupts per second which in the end sends the CPU usage way up.
However these things can be tweaked, mainly by increasing the MTU size upto 9000 bytes (so called Jumbo Frames), which means the CPU has less packets per second to deal with. So, if you had a grunty enough box and prefably a 64bit pci slot to put such a card in you would be able to get larger files around quicker, especially if set to full duplex over a crossed cable. If you are going to use this in a older/slower machine on a 32bit bus then there probably isn't much to gain.....I'm going to be running some tests in the coming weeks with GigE on a linux box ... so will get the results back here if interested. Also if you have a bunch of cards lying around (and some spare slots) you could look to do some channel bonding of multiple interfaces....just a thought. re Francois > 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 acceleratios the CPU usage way up. However these things can be tweaked, mainly by increasing the MTU size upto 9000 bytes (so called Jumbo Frames), which means the CPU has less packets per second to deal with. So, if you had a grunty enough box and prefably a 64bit pci slot to put such a card in you would be able to get larger files around quicker, especially if set to full duplex over a crossed cable. If you are going to use this in a older/slower machine on a 32bit bus then there probably isn't much to gain.....I'm going to be running some tests in the coming weeks with GigE on a linux box ... so will get the results back here if interested. Also if you have a bunch of cards lying around (and some spare slots) you could look to do some channel bonding of multiple interfaces....just a thought. re Francois > 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 dedin 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 wcate 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 ill 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 mak >> >> 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 Proe 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] gress 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
