<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 23, 2014 at 9:09 AM, Gary Buhrmaster <span dir="ltr"><<a href="mailto:gary.buhrmaster@gmail.com" target="_blank">gary.buhrmaster@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Dec 23, 2014 at 4:55 PM, Simon Hobson <<a href="mailto:linux@thehobsons.co.uk">linux@thehobsons.co.uk</a>> wrote:<br>
.....<br>
<span class="">> A fourth option (which requires a capable switch) is to configure 2off gigabit NICs as a trunk to give a 2Gib/s link to/from the switch, which means you'd need two transfers to/from two separate devices to be able to saturate it - a single device on a gigabit link will only be able to use 1/2 the 2G link. The first option is simpler though.<br>
<br>
</span>This is not assured to work.  In order to assure in-order packet delivery,<br>
proper switches will hash various values in the packet and deliver packets<br>
from one stream across only one link.  If you get "lucky" (luck has nothing<br>
to do with it, but for those not steeped in the details, it feels like magic)<br>
the two streams may use different links.  If not, you have exactly the<br>
same issue (all traffic on one link).  With enough traffic, from enough<br>
different sources, it seems balanced, but with traffic from only a few<br>
sources, not so much.<br>
<br>
But the real issue here is that at this point you have a symptom,<br>
without understanding the root cause.  There can be many causes<br>
of losing packets, from CPU limitations, to TCP/UDP packet buffer<br>
sizes, to ethernet device "issues", to disk limitations, to switch<br>
(lack of) buffer, head-of-line blocking, etc.  Until one actually does<br>
the diagnosis to understand what is going on, you may mitigate<br>
against an issue you are not having.  I have no doubt that some<br>
of the proposed alternatives have solved specific issues for some<br>
of the posters, but that may not be the issue the OP is having.<br></blockquote></div><br></div><div class="gmail_extra">If he just wants to limit the bandwidth used by the file copy process (assuming slower performance is not a problem) then the underlying cause shouldn't *necessarily* matter so much. It seems like there should be some equivalent of ionice for network bandwidth. I did a quick search and came across Trickle (<a href="http://monkey.org/~marius/pages/?page=trickle">http://monkey.org/~marius/pages/?page=trickle</a>), which runs in user space. Not sure if it would work for cp, but it might be worth investigating. There were some other more involved solutions using iptables and tc but the simplest workable solution is usually best.<br><br></div><div class="gmail_extra">Karl<br></div></div>