D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] OT: Network cable.

 

On Sun, 11 Apr 2010, Julian Hall wrote:

Hi All,

Simple question. My new NAS box has Gigabit rather than the 10/100Mbit of my previous NAS. However the new one came with exactly the same cable (standard CAT5) as the old one. Given that the PC is well within the 2m length of cable is there any point in replacing it with CAT5e which AFAIK is the proper cable for Gigabit? I ask simply because the increase in speed isn't as much as I would have expected - 2/3x - when I would have expected a fair bit more. Not 10x (although that would have been nice) but a mere 2/3x does seem low and I wondered if the cable was the fault.

The cable will be fine for 2m.

At Gb levels you're up against various hardware and software limitations - firstly the disk head-bandwidth of the drive itself - and depending on the drives you use that might be in the region of 3-80MB/sec. depending on drive and interface type. The nice dual-platter WDC ones can stream at 120MB/sec though.

If you have  local linux box, run this:

  hdparm -tT /dev/sda

(or hda, etc.)

My workstation:

/dev/sda:
 Timing cached reads:   1066 MB in  2.00 seconds = 533.13 MB/sec
 Timing buffered disk reads:  142 MB in  3.02 seconds =  46.97 MB/sec

The first number is the 'raw' speed the system can get data over the hardware bus from the disk controller. The 2nd is the actual disk head bandwidth - so my workstation drive could stream at about 46MB/sec. That's half Gb line speed.

Then there's the processors ability to move date from the disk to the network and vice versa - a cheap low power processor in consumer NAS boxes is really going to struggle here. (Although there are exceptions)

On-top of that might be RAID parity calculations if you're using RAID 5 or 6.

Finally, there's the actual network bit - streaming data down a Gb cable presents a few interesting issues - not to mention the processor load of having to take a 1500 byte packet off the wire and re-assemble it into a TCP stream - enabling jumbo frames helps here though, but not all hardware supports it.

(And as an excercise, work out how many bits there are in 1500 bytes and how much wire-time it represents, and how many 1500 byte packets a second the processors at each end have to cope with)

Gordon

--
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html