---------- Forwarded message ----------
From: Michael Gunter <firstname.lastname@example.org>
Date: Wed, Apr 21, 2010 at 1:11 AM
Subject: Re: [Udpcast] Jumbo Frames in UDPcast?
To: Alain Knaff <email@example.com
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 <firstname.lastname@example.org>
On 20/04/10 23:48, Michael Gunter wrote:Just one remark: each frame has a certain amount of "overhead" (Udpcast
> 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
headers, IP headers, Ethernet headers), so in order to avoid
fragmentation (and performance loss), you need to stay slightly under
So, for example:
> 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!