Hola:
De la siguiente direccion pueden descargarse las imagenes booteables de
floppy, cd y otras con udpcast instalado, incluye las instrucciones,
segun esta pagina:
http://www.udpcast.linux.lu/bootmedia.html
Pre-requisites
If you use UDP-Cast to duplicate OS installations, all participating
machines should be *rigorously identical* hardware-wise. Most notably:
* Their hard disks should have the same size and layout (sectors,
heads, cylinders). Number of sectors and heads of source system
should stay identical, whereas number of cylinders of target
system only be greater or identical. N.B. If you are only
transferring Linux partitions (no other system), there is no need
for matching sectors and heads. Only the overall size of the
target system must be equal or bigger than that of the source system.
* Any peripherals (network cards, keyboards, mice) should be identical.
* If the template machine (sender) has more peripherals (such as for
instance a CD-Rom drive) than the client machines, their drivers
should be uninstalled before the multicast.
* See also the notes on special notes
<http://www.udpcast.linux.lu/windows.html> about copying Windows
machines
Note about copying to hard disks with different geometry:
* If the new disk (or partition) is bigger, the copied system won't
actually make any use of the additional space. In order to do
that, you need to resize the partition using a partition resizing
tool such as Partition Magic or PartEd
<http://www.gnu.org/software/parted/>
* When copying a linux system to a partition or disk with differing
geometry, be sure to use the linear option in /etc/lilo.conf. If
for some reason you can't use this, be sure to rerun lilo on the
target system after the copy (boot from a rescue disk).
Tuning hints
1. Chose the proper duplex mode: if your network has a Hub, use
--half-duplex, if it has a switch, use --full-duplex. If the
network is mixed (central switch, hubs around), use --half-duplex
2. If you have a switch:
* enable "IGMP snooping".
* If hubs are connected to your switch, disable flow control
on the ports to which the hubs are connected. Disable flow
control is also necessary (on all ports where udp-senders
site) if IGMP snooping is not available or not working
correctly.
* Disable /Broadcast Storm Control/ (or else the switch might
consider the udpcast session as a broadcast storm, and slow
it down...)
* If too many retransmissions happen in full-duplex mode,
consider lowering the slice size using the --slice-size
option (default is 112).
y el manual de su linea de commados es este:
Udpcast commandline options
This page describes the options for the command line versions of
udpcast. The commandline version of udpcast is 100% compatible with the
boot disk version. You can for instance start the sender from the
bootdisk, but have a receiver run from commandline on the fileserver, in
order to get an archive copy of the sender's disk image. Later you may
start a commandline sender on the fileserver, and bootdisk receivers on
the client boxes, in order to restore their image from the archived
copy. Of course, you may also directly udpcast an image from a master
client to copies, in this case bother sender and receiver would run from
the boot disk.
The boot disk version's menues only give access to the most common
command line option (file name and pipe mode (compressions)). In order
to access the other options, use the "Additional parameters" dialog box
to enter them, just like you would type them into a shell window.
Udp-sender
Udp-sender is used to broadcast a file (for instance a disk image) to
multiple udp-receivers on the local LAN. In order to do this, it uses
Ethernet multicast or broadcast, so that all receivers profit from the
same physical datastream. Thus, sending to 10 destinations does not take
more time than it would take to send just 2.
Basic options
--file /file/
Reads data to be transmitted from /file/. If this parameter is not
supplied, data to be transmitted is read from stdin instead.
--pipe /command/
Sends data through /pipe/ before transmitting it. This is useful for
compressing/decompressing it, or for stripping out unused blocks.
The /command/ gets a direct handle on the input file or device, and
thus may seek inside it, if needed. Udpcast itself also keeps a
handle on the file, which is used for an informal progress display.
The /command/'s stdout is a pipe to udpcast.
--log /file/
Logs some stuff into /file/.
--autostart /n/
Starts transmission after /n/ retransmissions of hello packet,
without waiting for a key stroke. Useful for unattended operation,
where udp-sender is started from a cron-job for a
broadcast/multicast at a scheduled time.
Networking options
The following networking options should be supplied both on the sender
and the receivers:
--portbase /portbase/
Default ports to use for udpcast. Two ports are used: /portbase/ and
/portbase+1/ . Thus, /Portbase/ must be even. Default is 9000. The
same /portbase/ must be specified for both udp-sender and udp-receiver.
--interface /interface/
Network interface used to send out the data. Default is eth0
--broadcast
Use Ethernet broadcast, rather than multicast. Useful if you have
Ethernet cards which don't support multicast.
By default, udpcast uses multicast. This allows sending the data
only to those receivers that requested it. Ethernet cards of
machines which /don't/ participate in the transmission automatically
block out the packets at the hardware level. Moreover, network
switches are able to selectively transmit the packets only to those
network ports to which receivers are connected. Both features thus
allow a much more efficient operation than broadcast. This option
should only be supplied on the sender.
--ttl /time to live/
Sets the /time-to-live/ parameter for the multicast packets. Should
theoretically allow to use UDPCast beyond the local network, but not
tested for lack of a multicast router.
--mcast-all-addr /address/
Uses a non-standard multicast address for the control connection
(which is used by the sender and receivers to "find" each other).
This is *not* the address that is used to transfer the data.
By default mcast-all-addr is the Ethernet broadcast address if ttl
is 1, and 224.0.0.1 otherwise. This setting should not be used
except in very special situations, such as when 224.0.0.1 cannot be
used for policy reasons.
The following networking options should be supplied only on the sender:
--mcast-addr /address/
Uses the given address for multicasting the data. If not specified,
the program will automatically derive a multicast address from its
own IP (by keeping the last 27 bits of the IP and then prepending 232).
--pointopoint
Point-to-point mode. Only a single receiver is allowed, but the data
will be directly send to this receiver (in unicast mode), rather
than multicast/broadcast all over the place. If no async mode is
chosen, and there happens to be only one receiver, point-to-point is
activated automatically.
--nopointopoint
Don't use point-to-point, even if there is only one single receiver.
--full-duplex
Use this option if you use a full-duplex network. T-base-10 or 100
is full duplex if equipped with a switch. Hub based networks, or
T-base-2 networks (coaxial cable) are only *half-duplex* and you
should not use this option with these networks, or else you may
experience a 10% performance hit.
N.B. On high-latency WAN links, the full-duplex option can lead to
substantial performance improvements, because it allows udp-sender
to send more data while it is still waiting for the previous batch
to get acknowledged.
--half-duplex
Use half duplex mode (needed for Hub based or T-base-2 networks).
This is the default behavior in this version of udpcast.
-b /blocksize/
Choses the packet size. Default (and also maximum) is 1456.
Unidirectional mode (without return channel)
The options described below are useful in situations where no "return
channel" is available, or where such a channel is impractical due to
high latency. In an unidirectional setup (i.e. without return channel),
the sender only sends data but doesn't expect any reply from the receiver.
Unidirectional options must be used together, or else the transfer will
not work correctly. You may for example use the following command line:
udp-sender --async --max-bitrate 10m --fec 8x8
--async
Asynchronous mode. Do not request confirmations from the receiver.
Best used together with forward error correction and bandwidth
limitation, or else the receiver will abort the reception as soon as
it misses a packet. When the receiver aborts the reception in such a
way, it will print a list of packets lost in the slice causing the
problem. You can use this list to tune the forward error correction
parameters
<http://users.soe.ucsc.edu/%7Ekent/test/udpcast.html#fectune>.
--max-bitrate /bitrate/
Limits bandwidth used by udpcast. Useful in asynchronous mode, or
else the sender may send too fast for the switch and/or receiver to
keep up. Bitrate may be expressed in bits per second (--bitrate
5000000), kilobits per second (--bitrate 5000k) or megabits per
second (--bitrate 5m). This is the raw bitrate, including packet
headers, forward error correction, retransmissions, etc. Actual
payload bitrate will be lower.
--fec /interleavexredundancy/stripesize/
Enables forward error correction. The goal of forward error
correction is to transmit redundant data, in order to make up for
packets lost in transit. Indeed, in unidirectional mode, the
receivers have no way of requesting retransmission of lost packets,
thus the only way to address packet loss is to include redundant
information to begin with. The algorithm is designed in such a way
that if /r/ redundant packets are transmitted, that those can be
used to compensate for the loss of /any/ r packets in the same FEC
group (stripe).
In order to increase robustness of the FEC algorithm against burst
packet losses, each /slice/ is divided in /interleave/ stripes. Each
stripe has /stripesize/ blocks (if not specified, stripesize is
calculated by diving /slice-size/ by /interleave/). For each stripe,
/redundancy/ FEC packets are added. Stripes are organized in such a
fashion that consecutive packets belong to different stripes. This
way, we ensure that burst losses affect different stripes, rather
than using all FEC packets of a single stripe. Example: --fec 8x8/128
--rexmit-hello-interval /timeout/
If set, rebroadcasts the HELLO packet used for initiating the
casting each /timeout/ milliseconds.
This option is useful together with /asyc mode/, because with async
mode the receiver won't send a connection request to the sender (and
hence won't get a connection reply). In /async mode/, the receivers
get all needed information from the /hello/ packet instead, and are
thus particularly dependant on the reception of this packet, makeing
retransmission useful.
This option is also useful on networks where packet loss is so high
that even with connection requests, sender and receiver would not
find each other otherwise.
Udp-receiver
Udp-receiver is used to receive files sent by udp-sender (for instance a
disk image).
Basic options
--file /file/
Writes received data to /file/. If this parameter is not supplied,
received data is written to stdout instead.
--pipe /command/
Sends data through /pipe/ after receiving it. This is useful for
decompressing the data, or for filling in unused filesystem blocks
that may have been stripped out by udp-sender. The /command/ gets a
direct handle on the output file or device, and thus may seek inside
it, if needed. Udpcast itself also keeps a handle on the file, which
is used for an informational progress display. The /command/'s stdin
is a pipe from udp-receiver. Example: udp-receiver -p "gzip -dc"
--log /file/
Logs some stuff into /file/.
--nosync
Do not open target in synchronous mode. Useful when dumping to an
image file on a mounted filesystem, rather than to a raw partition.
Networking options
--portbase /portbase/
Default ports to use for udpcast. Two ports are used: /portbase/ and
/portbase+1/ . Thus, /Portbase/ must be even. Default is 9000. The
same /portbase/ must be specified for both udp-sender and udp-receiver.
--interface /interface/
Network interface used to send out the data. Default is eth0
--ttl /ttl/
Time to live for connection request packet (by default connection
request is broadcast to the LAN's broadcast address. If ttl is set,
the connection request is multicast instead to 224.0.0.1 with the
given ttl, which should enable udpcast to work between LANs. Not
tested though.
--mcast-all-addr /address/
Uses a non-standard multicast address for the control connection
(which is used by the sender and receivers to "find" each other).
This is *not* the address that is used to transfer the data. By
default mcast-all-addr is the Ethernet broadcast address if ttl is
1, and 224.0.0.1 otherwise. This setting should not be used except
in very special situations, such as when 224.0.0.1 cannot be used
for policy reasons.
Tuning options (sender)
The following tuning options are all about slice size. Udpcast groups
its data in /slices/, which are a series of blocks (UDP packets). These
groups are relevant for
* data retransmission: after each slice, the server asks the
receivers whether they have received all blocks, and if needed
retransmits what has been missing
* forward error correction: each slice has its set of data blocks,
and matching FEC blocks.
--min-slice-size /size/
minimum slice size (expressed in blocks). Default is 16. When
dynamically adjusting slice size (only in non-duplex mode), never
use smaller slices than this. Ignored in duplex mode (default).
--max-slice-size /size/
maximum slice size (expressed in blocks). Default is 1024. When
dynamically adjusting slice size (only in non-duplex mode), never
use larger slices than this. Ignored in duplex mode (default).
--default-slice-size /size/
Slice size used (starting slice size in half-duplex mode).
Tuning the forward error correction
There are three parameters on which to act:
redundancy
This influences how much extra packets are included per stripe. The
higher this is, the more redundancy there is, which means that the
transmission becomes more robust against loss. However, CPU time
necessary is also proportional to redundancy (a factor to consider
on slow PC's), and of course, a higher redundancy augments the
amount of data to be transmitted.
interleave
This influences among how many stripes the data is divided. Higher
interleave improves robustness against burst loss (for example, 64
packets in a row...). It doesn't increase robustness against
randomly spread packet loss. *Note*: interleave bigger than 8 will
force a smaller stripesize, due to the fact that slicesize is
limited to 1024.
stripesize
How many data blocks there are in a stripe. Due to the algorithm
used, this cannot be more than 128. Reducing stripe size is an
indirect way of augmenting (relative) redundancy, without incurring
the CPU penalty of larger (absolute) redundancy. However, a larger
absolute redundancy is still preferable over a smaller stripesize,
because it improves robustness against clustered losses. For
instance, if 8/128 is preferable over 4/64, because with 8/128 the 8
FEC packets can be used to compensate for the loss of any of the 128
data packets, whereas with 4/64, each group of 4 FEC packets can
only be used against its own set of 64 data packets. If for instance
the first 8 packets were lost, they would be recoverable with 8/128,
but not with 4/64.
Considering these, change parameters as follows:
* If you observe long stretches of lost packets, increase interleave
* If you observe that transfer is slowed down by CPU saturation,
decrease redundancy and stripesize proportionnally.
* If you observe big /variations/ in packet loss rate, increase
redundancy and stripesize proportionnally.
* If you just observe high loss, but not necessarily clustered in
any special way, increase redundancy or decrease stripesize
* Be aware that network equipment or the receiver may be dropping
packets because of a bandwidth which is too high. Try limiting it
using max-bitrate
* The receiver may also be dropping packets because it cannot write
the data to disk fast enough. Use hdparm to optimize disk access
on the receiver. Try playing with the settings in
/proc/sys/net/core/rmem_default and /proc/sys/net/core/rmem_max,
i.e. setting them to a higher value.
------------------------------------------------------------------------
--
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.
______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
