Hello,

 

generally unRAID 4.0 works just fine for me. However, the network speed is lower than I hoped it would be. If I do a parity check, I'm getting 65MB/s. Clearing was even faster, IIRC. So my harddisks are clearly able to deliver 65MB/s. However, even with a direct gigabit connection (without a switch/router in between) to my XP Desktop PC or Vista Notebook, I'm not able to get more than 20-25MB/s, even when only reading from the unRAID tower.

 

Is that normal, that gigabit only delivers 20MB/s? Sure, it's plenty enough for HD streaming/playback. But I already have stuttering sometimes if I play a HDTV video while copying something to the unRAID tower at the same time. Ok, I can avoid copying while watching video. So I can live with that. But honestly, shouldn't network be faster than 20MB/s if the harddisks clearly can do 65MB/s?

 

Maybe I need to optimize the settings somehow? Or maybe XP/Vista is not good enough for this kind of stuff? Or maybe Samba is too slow a protocol? Maybe NFS would be a better choice?

 

Thanks!

i was wondering the same thing. is there anyway to get even close to using the full gigabit connection? im only gettign 20-25MB/s and gigabit can get around 125MB/s

Ethernet can only deliver about 25% of wireline capacity, except in certain circumstances.

 

It depends on Round Trip Latency... most of the time you can't get below about 2 ms, and that limits you to 200 Mbps, even with a receive window of 64K bytes.  Cut your latency to 0.5 ms, and you can get 500Mbps.

Ethernet can only deliver about 25% of wireline capacity, except in certain circumstances.

 

It depends on Round Trip Latency... most of the time you can't get below about 2 ms, and that limits you to 200 Mbps, even with a receive window of 64K bytes.  Cut your latency to 0.5 ms, and you can get 500Mbps.

 

A reasonable analogy is traveling by car.  Even if it were legal, I cannot drive from my house to my office at my car's top speed of 155mph (which I have actually hit for prolonged periods of time while in Germany).

 

Pedestrians, traffic, stop signs, traffic lights, turns, etc. all slow me down to the point where my effective average speed is more like 40mph.

 

What gets people confused is that 10Mbit and 100Mbit ethernet speeds are fairly sustainable so they expect that from GigE.  Back to the car analogy, it is like a car with a 1.5mph or 15mph top speed - cars like that can achieve darn near those speeds for huge stretches of time, but my 155mph car cannot.

 

 

Cheers,

Bill

The amount of round-trip time from A to B is your latency.  On a local LAN, with no crap devices in the way, it should be about 2 ms.

TCP is a guaranteed delivery windowing protocol.... On TCP, your "window" is how much data you can send in a batch, before you have to wait for the other end to respond that they got OK.

 

Sending a 64Kbit Window takes:

 

On 10mbps = 64ms

On 100mbps = 6.4ms

On 1000mbps = .64ms

 

Your latency will be the same for all, because it depends on the speed of electrons in the wire (assuming no devices in the way) and not the transmission frequency of the Ethernet.

 

So the amount of round-trip time lost in latency is:

 

On 10mbps = 3%  (2/66)

On 100mbps =24%  (2/8.4)

On 1000mbps = 76%  (2/2.64)

 

76% of the time on GigiBit Ethernet is spent waiting, after sending the last bit of a 64kbit window, to hear back from the receiving box.  Which means the rest of the time (25%) of the time is spent doing work.

 

Now look at it another way.  Data that took 66 ms on 10Mb, takes only 8.4ms on 100Mb... (8 times as fast).  The difference from 100Mb to GigaBit is only a factor of 3 however.

 

 

This is an incredibly concise and easy to understand explanation.  Thanks very much bubbaQ - I really never understood why gigabit was so darn slow!

 

What is the next great hope for faster networking speeds at the consumer level?

This is an incredibly concise and easy to understand explanation.  Thanks very much bubbaQ - I really never understood why gigabit was so darn slow!

 

What is the next great hope for faster networking speeds at the consumer level?

Eliminate the window latency by deploying a transfer method that does not wait for confirmation before sending the next window.  Send all as fast as possible, listen for problems asynchronously and resend where needed, listen for the final "got everything" message before saying "done".

 

Did tokenring do something similar?

 

 

Bill

I know a little about token ring.

 

There literally is a token that moves though the network. You can only talk when you have the token. There is zero chance of collision. Token ring tends to perform well under heavy traffic but poorly when there is little traffic. 

Send all as fast as possible, listen for problems asynchronously and resend where needed

 

And that was basically what Novell IPX burst-mode was .... best damn LAN protocol ever put into production.

This is an incredibly concise and easy to understand explanation.  Thanks very much bubbaQ - I really never understood why gigabit was so darn slow!

 

What is the next great hope for faster networking speeds at the consumer level?

Eliminate the window latency by deploying a transfer method that does not wait for confirmation before sending the next window.  Send all as fast as possible, listen for problems asynchronously and resend where needed, listen for the final "got everything" message before saying "done".

 

Did tokenring do something similar?

 

 

Bill

 

Sounds like ATM.

That makes perfect sense, except that the 64k window size problem should have been fixed by RFC1323 Window Scaling (http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Window_scaling)

 

I'm no expert, but I know I've seen windows box to windows box achieve in the 700 megabits per second, so I know they must support it...  I'd be surprised if Linux (and therefore UnRaid) didn't support the same.. 

 

Perhaps it's time to get out the old WireShark and see if I can't track down those bytes in TCP handshake with the UnRaid to see what they're agreeing on...

 

-Steve

 

 

The amount of round-trip time from A to B is your latency.  On a local LAN, with no crap devices in the way, it should be about 2 ms.

TCP is a guaranteed delivery windowing protocol.... On TCP, your "window" is how much data you can send in a batch, before you have to wait for the other end to respond that they got OK.

 

Sending a 64Kbit Window takes:

 

On 10mbps = 64ms

On 100mbps = 6.4ms

On 1000mbps = .64ms

 

Your latency will be the same for all, because it depends on the speed of electrons in the wire (assuming no devices in the way) and not the transmission frequency of the Ethernet.

 

So the amount of round-trip time lost in latency is:

 

On 10mbps = 3%  (2/66)

On 100mbps =24%  (2/8.4)

On 1000mbps = 76%  (2/2.64)

 

76% of the time on GigiBit Ethernet is spent waiting, after sending the last bit of a 64kbit window, to hear back from the receiving box.  Which means the rest of the time (25%) of the time is spent doing work.

 

Now look at it another way.  Data that took 66 ms on 10Mb, takes only 8.4ms on 100Mb... (8 times as fast).  The difference from 100Mb to GigaBit is only a factor of 3 however.

 

 

True, but Windows does not support RFC 1323 w/o hacking the registry.  I tested it with various flavors of XP over the years (including SP2 and SP3) and never got significant improvement, likely to to fubars by Micro$oft.

 

I've done over 600Mb/sec on Windows, but not TCP/IP and certainly not Samba.

 

I'd love if it did work.... perhaps it does in Win7... but I haven't tried it.

Really..  That stinks..  I just ASSUMED it did..  Now I'm wondering how I achieved the fast speeds in my tests  (separate from UnRaid, just between 2 windows boxes)

 

Oh well.  Thanks for the info..

 

--SJ

Really..  That stinks..  I just ASSUMED it did..  Now I'm wondering how I achieved the fast speeds in my tests  (separate from UnRaid, just between 2 windows boxes)

 

As I said, under XP, you had to hack the registry to ENABLE the support for RFC 1323.  I don't know about Vista and Win7.