WyomingKnott said:
Just to reiterate what Tokencode wrote, 138 MB/s is 139 megaBYTES per second. A byte is eight bits. 138 x 8 = 1,104, so you are in the gigaBIT per second range.
Actually, most network encoding is 8/10, so you can only transmit one byte per 10 bits, not eight. This is done largely to make sure that the signal is "balanced," not developing a DC current across the wires. See
http://en.wikipedia.org/wiki/8/10_encoding
Actually, im totally aware that 138megabytes are in the range of megabits. The issue is, that occurred under lab test, sequential and most probably read only. in real world, that is hardly the case. i wont go with something that is just enough in the lab test. too risky.
by the way, thanks for reminding me of 10 encoding. that makes my target speed is 80% of 1 gigabit at max(im sure there are other factors to consider)
Quote:
Most of the HDD/Storage manufacture list the transfer rated sequential.
This wont help you much with a real life application
exactly.
Quote:
Here is what you can do to get the fast transfer rate from a server:
1- Hardware raid
2- Network teaming - prefer 802.3ad spec.
hardware raid solution is too expensive. plus ssd doesnt support raid with trim. network teaming is out of the question since im measuring single network line.
Quote:
The PC clients who are reading the data, will their systems even be able to write at 1gbit/sec?
both client and server have the same spec. the thing im doing is actualy for a telco company. they want to prove to their customer that they are giving 1gigs speed to their customer. not best effort, but guarantee.
Quote:
PublicENEMY, jumbo frames are TCP packets with an MTU larger than 1500bytes (standard ethernet MTU) This is the size of the packet being sent on the ethernet network. If you use TCP to transfer your data, for each packet sent you need to get an acknowledgement back before the next packet is sent. If you have any amount of latency, he number of ack/syns per second is limited and since the packet size is also limited your max htroughput is limited. With Jumbo Frams you can change the MTU to let's say 3000 bytes which would effectively double your throughput. This will only work if everything in between the two end-points supports jumbo frames otherwise the packet will be fragmented and the reassembled and can further degrade performance.
Even with NIC teaming, your throughput will be identical if because your latency is reduced. Now keep in mind all of this only applied to a single TCP steam. If you do multiple streams, each stream can support maximum.
Since you stated that drive access time is important I'm assuming this is for some type of database application or something similiar where the read/writes are random and not sequential like when streaming a movie or something?
i did try using tcp and udp but finally settle down with ftp. about jumbo frames, i chose intel fibre channel nic
http://ark.intel.com/products/50396/Intel-Gigabit-EF-Du.... there is no mention of jumbo frames. is this the best nic for the task? are there any other brand better than intel?
this is not for database application. this is for proving that the line can truly provide gigabit speed. the read and write is sequential.
thanks to everybody (tokencode, natx808, FireWire2, WyomingKnott)who answer.