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