Any plans to allow multiple Gig NICs?  Or perhaps even more helpful, multiple 100bT NICs for those that don't have GigE...I realize parity writing is probably going to be a bottleneck but I always get a little 'tick' in my neck when I'm not utilizing all capabilities available to me with my hardware

Any plans to allow multiple Gig NICs?  Or perhaps even more helpful, multiple 100bT NICs for those that don't have GigE...I realize parity writing is probably going to be a bottleneck but I always get a little 'tick' in my neck when I'm not utilizing all capabilities available to me with my hardware

Well... since throughput is limited by the fastest harddisk for reading and the parity disk for writing, I guess you can safely say you are most definitely utilizing all capabilities. Unless you create a RAID 0+1 composed of 4 harddisks for your parity drive and also do a RAID 1 on every data disk so to be able to saturate the Gbit line...

 

Link Aggregation must be supported by the switch/router as well... if you have one that supports it, you're likely to have GBit adapters as well, so no need for teaming Fast Ethernet adapters.

Might be prudent to put the time into enabling/adjusting Jumbo Frames from the front end.

This could provide an adjustable performance boost in a small home network.

Jumbo frames are not going to help you.  Bigger is not better.

 

Even if they weren't a total BITCH to get and working, Jumbo frames are not going to get you squat on a local, unrouted subnet.

 

Jumbo frames are a boon to WANs and routed subnets because the reduce interrupts and thus reduce CPU.... i.e. save you money by not having to upgrade your router horsepower.

 

They improve throughput for a given rate of packet loss.... if you already have zero packet loss (typical on a local LAN) then a 9K MTU won't gain you anything perceptible.

 

TCP is a windowing protocol, and uses a sliding window up to 64K (much larger than jumbo frames) that will already take advantage of your zero packet loss environment.

 

If you are pounding packets cross-country from LA to NY, jumbo frames can help as your latency is going to be at least 40 msec.  On your local subnet, your latency is more like 2ms.  None of you are trying to pass a billion packets per second and need big-bucks CPUs in your routers to do it.... so the CPU savings are meaningless.

Jumbo frames are not going to help you.  Bigger is not better.

 

Jumbo frames have proven useful to me, I'd like to share my personal experience ...

 

I equipped intel gigabit nics into each one of my machines ... and transfers rates went from aprox 30-40Mbs to aprox 60-80Mbs

 

this is between an ubuntu server 9.04 and a windows 7 64bit box

 

I have seen similar improvements in my network transfers moving from the default MTU to 4K Jumbo Frames.

I've read about similar improvements with jumbo frames on a local network.

 

In addition, I have not read, nor experienced, jumbo frame improvement on long transcontinental wans. (But this is my personal experience)

With our transcontinental link we had to modify vsftpd to have a new site command to allow manual changing of the window size.

From what I saw unRAID has some tunings which expand the window sizes.

 

FWIW, BubbaQ has a point. when I did a pure network to network transfer test using a windows tool and a linux tool, I recorded 990MB/s transfer. This was purely application to application with no disk I/O. PCIe machine to PCie machine over a 8port switch.

On another test the PCI-X machine showed 770Mb/s.

 

Where Jumbo frames do help is by eliminating some extra overhead in TCP framing which may help certain hardware.

 

On my local network at home, I'm not sure it would show much improvement with 990MB/s between two applications.

 

I would suggest trying it to see how your network hardware reacts.

Once you get latency down to the 2ms and zero packet loss that's typical on a LAN, TCP/IP at gigabit speeds becomes inefficient with real-world applications, and other protocols, such as burst mode IPX, will perform better.  Jumbo packets can't address that because they don't offer significant imrpovement in that environment.  They produce improvements where the latency and packet loss is higher.  If you get significant performance improvements on a local LAN with jumbo frames, it is a symptom of something else, such as high latency, a bad switch or card,  or something is dropping packets intermittently (where jumbo frames will improve performance).

FWIW, BubbaQ has a point. when I did a pure network to network transfer test using a windows tool and a linux tool, I recorded 990[glow=red,2,300]MB[/glow]/s transfer. This was purely application to application with no disk I/O.

 

Guess that should be 990Mb/s. 

 

I have network latency at about 0.5-0.6ms and Jumbo frames doesn't do much within my network.

 

64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.581 ms

64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.575 ms

64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.554 ms

64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.533 ms

 

For the purposes of network speed testing, is there any trick that can accomplih something like...

mount /dev/null /mnt/blackhole

I've seen improvements from switching to good quality nics which support checksum offloading....  but then you end up with nics sharing the same bus as the disk controller.  Also some switches use shared ASIC's so if you aren't careful you'll end up with conflicts there too. (most don't these days)

 

Its not often you see anything approaching saturating a gigabit copper port, nearly 1000 servers at work and its very rare to see any of them using much above 500MB/s even during backups.

Its not often you see anything approaching saturating a gigabit copper port, nearly 1000 servers at work and its very rare to see any of them using much above 500MB/s even during backups.

 

Don't get what are you talking about? Are you saying that 500MB/s go through a GigE port? Or is this 500Mb/s per GigE port? Or do 1000 servers generate 500MB/s through the switch? 

Unlike a hub, a switch doesn't broadcast all packets to all the machines on a network. It switches the packets only between the two computers which are talking to each other. So, traffic between two machines shouldn't affect in any way the speed of traffic between another pair of machines, although they are all connected through the same switch.

Unlike a hub, a switch doesn't broadcast all packets to all the machines on a network. It switches the packets only between the two computers which are talking to each other. So, traffic between two machines shouldn't affect in any way the speed of traffic between another pair of machines, although they are all connected through the same switch.

unless the switch uses one asic for multiple ports.....  Some switches only allow for say 1gb of traffic over two or four ports because there is shared internal hardware in the switch.

Its not often you see anything approaching saturating a gigabit copper port, nearly 1000 servers at work and its very rare to see any of them using much above 500MB/s even during backups.

 

Don't get what are you talking about? Are you saying that 500MB/s go through a GigE port? Or is this 500Mb/s per GigE port? Or do 1000 servers generate 500MB/s through the switch? 

 

50%+ utilisation on any one GigE port.

Unlike a hub, a switch doesn't broadcast all packets to all the machines on a network. It switches the packets only between the two computers which are talking to each other. So, traffic between two machines shouldn't affect in any way the speed of traffic between another pair of machines, although they are all connected through the same switch.

unless the switch uses one asic for multiple ports.....  Some switches only allow for say 1gb of traffic over two or four ports because there is shared internal hardware in the switch.

 

Look for terms like "Switching Fabric" or "Max Aggregate Bandwidth" to determine just how much a switch can deal with.

I can highly recommend the HP ProCurve 1400-24G switches, each port has full bandwidth, or 48Gbps switching capacity. The managed version (with support for GigE Teaming, etc) would be the 1800-24G. They are cheap on ebay.

For the purposes of network speed testing, is there any trick that can accomplih something like...

mount /dev/null /mnt/blackhole

 

No takers?

 

 

I'd like to add my vote for bonding support in official unRAID releases.  It is currently trivial for me to saturate a single gigabit link even when not reading from my cache drive (an SSD).  This may not be important to those that are using unRAID to send media files around, but bonding support is a relatively easy thing to include.