Will your organization be ransomware's next victim? The good news is that these attacks are predicable and therefore preventable. Learn more about how you can stop a ransomware attacks before encryption takes place with our Ransomware Prevention Kit!
COURSE of the MONTH
10 days, 5 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
File transfers very slow
Posted on 2012-12-20
All,
I have a Ctera 800 box and a gigabit cisco sg 300. Cisco is set to auto, flow controll on, LAG on nics and switch ports, no jumbo frames, no port security. The Ctera box is set to auto and LAG. The data gets transfered to another server on the same switch and same server config except for LAG. The transfer rate never gets above 50 Mbps. Any suggestions.
Thanks
I have a Ctera 800 box and a gigabit cisco sg 300. Cisco is set to auto, flow controll on, LAG on nics and switch ports, no jumbo frames, no port security. The Ctera box is set to auto and LAG. The data gets transfered to another server on the same switch and same server config except for LAG. The transfer rate never gets above 50 Mbps. Any suggestions.
Thanks
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
2-
2
5 Comments
Active today
First off I'm pretty sure that lag does nothing for a single file transfer but even then you should be able to hit 110-120MB/s on gigabit. You do mean Bytes and not bits right?
You will also be limite by the read speed o the source and the write speed of the destination. I'd star by eliminating read and write speed by transferring to/from a local drive (or a ram disk if you can)
If all that good, then look at the network.
You will also be limite by the read speed o the source and the write speed of the destination. I'd star by eliminating read and write speed by transferring to/from a local drive (or a ram disk if you can)
If all that good, then look at the network.
Aaron is correct about the LAG giving you no boost in speed. LAG's are great for failover and for increasing the total possible bandwidth, but that bandwidth boost only becomes apparent when multiple sessions are going across the LAG.
On a per-session basis, the algorithm used will choose which physical interface the data will traverse and that choice will never change throughout the session nor can it multiplex the session across multiple physical links. This means your maximum per-session speed can never exceed the speed of an individual link. Also, bear in mind that a 1G switch is 1Gigabit per second, not 1Gigabyte per second. Depending on which application you are using to display the speed of the transfer, it can make the transfer seem very fast... or unusually slow. A 1G switch only equates to 125Megabytes per second absolute max, and to bring that one step further the LAG will only allow a single session to hit 125MBps and this is without the overhead incurred with normal TCP/IP.
A LAG is still great in the fact that you can have multiple sessions going on that can add up to a total bandwidth of all available links, but individual sessions are limited.
The other thing that comes in to play with these situation is latency. To achieve the full gig throughput your latency would need to be .000524288s (.524ms) or less. Even on a direct connection this can be hard to achieve without the right hardware. When latency is getting this low, small latency differences cause big throughput differences. If you had .8ms latency you would have a max throughput of approximately 80MBps. 1.28ms latency would produce a max of 50MBps.
I realize the above is likely not to be your answer, but it's a good baseline to work off of.
On a per-session basis, the algorithm used will choose which physical interface the data will traverse and that choice will never change throughout the session nor can it multiplex the session across multiple physical links. This means your maximum per-session speed can never exceed the speed of an individual link. Also, bear in mind that a 1G switch is 1Gigabit per second, not 1Gigabyte per second. Depending on which application you are using to display the speed of the transfer, it can make the transfer seem very fast... or unusually slow. A 1G switch only equates to 125Megabytes per second absolute max, and to bring that one step further the LAG will only allow a single session to hit 125MBps and this is without the overhead incurred with normal TCP/IP.
A LAG is still great in the fact that you can have multiple sessions going on that can add up to a total bandwidth of all available links, but individual sessions are limited.
The other thing that comes in to play with these situation is latency. To achieve the full gig throughput your latency would need to be .000524288s (.524ms) or less. Even on a direct connection this can be hard to achieve without the right hardware. When latency is getting this low, small latency differences cause big throughput differences. If you had .8ms latency you would have a max throughput of approximately 80MBps. 1.28ms latency would produce a max of 50MBps.
I realize the above is likely not to be your answer, but it's a good baseline to work off of.
No I really mean bits. That is why I can never backup my server in a day. It would take weeks at this rate. We are looking into the database portion of the portal that the server is backing up to. Mind you they are both on the same LAN for now and not transfering over the WAN. Thanks all for the LAG knowledge. Do you think maybe the firmware on the switch? Thanks
Although firmware is always a possibility, I'd say you should try a couple different things first if you can.
Remove the LAG and let the two machines communicate using a regular single connection. This removes/suggests the LAG as a culprit.
Connect the two machines directly together to remove the switch from the situation. This can remove/suggest the switch as a culprit.
Remove the LAG and let the two machines communicate using a regular single connection. This removes/suggests the LAG as a culprit.
Connect the two machines directly together to remove the switch from the situation. This can remove/suggest the switch as a culprit.
Featured Post
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
In this tutorial I will show you with short command examples how to obtain a packet footprint of all traffic flowing thru your Juniper device running ScreenOS. I do not know the exact firmware requirement, but I think the fprofile command is availab…
One of the main issues with network wires is that you never have enough. You run plenty and plan for the worst case but you still end up needing more. What many people do not realize is with 10BaseT and 100BaseT (but not 1000BaseT) networks you …
Add bar graphs to Access queries using Unicode block characters. Graphs appear on every record in the color you want. Give life to numbers.
Hopes this gives you ideas on visualizing your data in new ways ~
Create a calculated field in a query:
…
In this video, Percona Director of Solution Engineering Jon Tobin discusses the function and features of Percona Server for MongoDB.
How Percona can help
Percona can help you determine if Percona Server for MongoDB is the right solution for …
Suggested Courses
Course of the Month10 days, 5 hours left to enroll
762 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.