Udpcast April 2010

udpcast@udpcast.linux.lu

6 participants
6 discussions

castomize udpcast iso image
by Gianluigi Autuori 17 Jul '11

17 Jul '11

I want to use Udpcast from iso image in this scenario: - first pc boots from udpcast iso image -second pc boots from ethernet using pxe that sends him udpreceiver How can I do it? thanks

3 2

Re: [Udpcast] About Udpcast FLAG_SN
by 一人游走 24 Apr '10

24 Apr '10

I tried to convert it to object-oriented (Delphi), Sender has been completed. Good results, the performance did not decrease, the structure is more clear. Also deepened my understanding of it! Thanks Alain! ------------------ Original ------------------ From: "Alain Knaff"<alain(a)knaff.lu>; Date: 2010年4月24日(星期六) 晚上9:30 To: "HouSoft"<hou(a)yryz.net>; Subject: Re: [Udpcast] About Udpcast FLAG_SN HouSoft wrote: > Hi AiLan: > > Why use FLAG_SN, do not DSC_REDUCING or DSC_REDUCING the slice of size? > > Thanks! FLAG_SN (--full-duplex) means that the network supports full duplex, i.e. that acknowledgment data sent back from the receivers does not disturb new data sent from the sender to the receiver. This is the case with most networks today (when using a switch rather than a hub). Updcast can take advantage of this by starting to send the next slice before all acknowledgments of the previous one have been received. DSC_REDUCING is used by the algorithm to find the optimal slice size. This algorithm is only used on half-duplex networks, and works by starting at a certain size, than keeping to add 25% slice size until transmission errors start showing up, and then reducing until transmission errors are gone. Such errors due to large slices can occur under certain timing conditions on half-duplex networks, and thus this algorithm is not needed in full duplex. Moreover, in full duplex mode, the slice size has no impact on performance, as the next slice can be transmitted right away, without needing to wait for the acknowledgments of the previous once. Regards, Alain

1 0

About Udpcast FLAG_SN
by HouSoft 24 Apr '10

24 Apr '10

Hi AiLan: Why use FLAG_SN, do not DSC_REDUCING or DSC_REDUCING the slice of size? Thanks!

2 1

Source for Windows
by HouSoft 22 Apr '10

22 Apr '10

using mysys to compile the source files,it's easy! -------------- http://msys-cn.googlecode.com/files/MSYS-Update.rar ------------- ./configure make ------------------ Original ------------------ *From:*"Holdridge, Michael B"<Michael_Holdridge(a)baylor.edu>; *Date:*2010年3月21日(星期天) 中午1:41 *To:*"udpcast(a)udpcast.linux.lu"<udpcast(a)udpcast.linux.lu>; *Subject:*[Udpcast] Source for Windows Is the source code supposed to compile in Windows without modification or would I have to port the code? Or are there sources for Windows available? I have tried using Dev C++ to compile the source files but am not having any luck. I’m fairly new to Linux and and have little experience with C, so I am not sure where to start. I know there are Windows binaries to download but this is not what I am looking for. I have been asked for a solution to distribute large game analysis videos to multiple workstations simultaneously. Udpcast does this perfectly, but I would like to make it more end user friendly. Any help would be greatly appreciated. Thanks, Michael Holdridge

3 3

Fwd: Jumbo Frames in UDPcast?
by Michael Gunter 21 Apr '10

21 Apr '10

---------- Forwarded message ---------- From: Michael Gunter <vir.iratus1686(a)gmail.com> Date: Wed, Apr 21, 2010 at 1:11 AM Subject: Re: [Udpcast] Jumbo Frames in UDPcast? To: Alain Knaff <alain(a)knaff.lu> 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 <alain(a)knaff.lu> 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 >

1 0

Jumbo Frames in UDPcast?
by Michael Gunter 21 Apr '10

21 Apr '10

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 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!

3 2

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Udpcast April 2010