Fwd: Jumbo Frames in UDPcast? - Udpcast

21 Apr 2010

---------- Forwarded message ----------
From: Michael Gunter &lt;vir.iratus1686(a)gmail.com&gt;
Date: Wed, Apr 21, 2010 at 1:11 AM
Subject: Re: [Udpcast] Jumbo Frames in UDPcast?
To: Alain Knaff &lt;alain(a)knaff.lu&gt;

After some further testing, it seems that our bottleneck is in the
compression and writing to the hard drive. To test, we set it up so we were
transferring /dev/zero through the nic into the /dev/null of another
machine. This revealed transfer speeds reaching close to 1 GB a second, but
of course, nothing was being read from the hard drive, compressed, or
written to a hard drive. We also did a test transferring a file without lzop
compression (which I forgot to mention we were using originally with an MTU
of 1500) and it did transfer at speeds almost double our normal transfer
speeds, so around 400 MB a second. The only problem is, sending the
uncompressed data at twice the speed took pretty much the same amount of
time as sending it compressed in smaller frames. We also took into account
the possibility of overhead and lowered the --blocksize to a safe 8500. I
have been looking into possibly combining GSO (Generic Segmentation
Offloading) with UDPcast to try and remove some of the overhead on the
processor, but have yet to actually try it yet. Does anyone know if it would
effectively increase the transfer speed or if it can even be done? Thank you
very much for your responses thus far.

On Tue, Apr 20, 2010 at 10:21 PM, Alain Knaff &lt;alain(a)knaff.lu&gt; wrote:

...
  On 20/04/10 23:48, Michael Gunter wrote:
  I'm a student and work at a school where we
image our machines using
 UDPcast. It has been a great tool for installing entire classrooms  quickly,
  but we recently upgraded all of our hardware and
are now running gigabit
 ethernet. We've configured the eth0 to have an MTU of 9000 with the
 following line

 ifconfig eth0 mtu 9000

 on both the sending and receiving computers. After preparing the machines  we
  use the udp-sender command to copy the master
hard drive over the network
 and include the switch

 --blocksize=9000 
 Just one remark: each frame has a certain amount of "overhead" (Udpcast
 headers, IP headers, Ethernet headers), so in order to avoid
 fragmentation (and performance loss), you need to stay slightly under
 your MTU.

 So, for example:
  --blocksize 8952

 but it doesn't seem to affect our transfer speeds at all. Without  changing
  the MTU or blocksize it sends at around 180 Mbps
and after changing the  MTU
  and blocksize it still sends at about the same
speed. Is there possibly
 another bottleneck we've overlooked such as bus speeds or hard drive
 transfer speeds? Or does UDPcast not support jumbo frames? I saw  somewhere
  in the archives that the blocksize can be reduced
if your network doesn't
 support 1500 byte frames, but never anything about increasing the size.
 Please advise, thank you very much!

 _______________________________________________
 Udpcast mailing list
 Udpcast(a)udpcast.linux.lu
 https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast 
 Regards,

 Alain