Dear developpers,
we are academic researchers working in automated program analysis.
We are currently interested in checking compliance of inline asm chunks
as found in C programs.
While benchmarking our tool and technique, we found 2 significant compliance
issues in UDPCAST. We report them to you, as well as adequate patches
with explanations.
* All these bugs are related to compliance between the block of asm and its
surrounding "contract" (in gcc-style notation). They are akin to undefined or
implementation-defined behaviours in C: they currently do not manifest
themselves in your program, but at some point in time with compiler
optimizations becoming more and more aggressive or changes in undocumented
compiler choices regarding asm chunks, they can suddenly trigger a
(hard-to-find) bug.
* The typical problems come from the compiler missing dataflow information
and performing undue optimizations on this wrong basis, or the compiler
allocating an already used register. Actually, we demonstrate "in lab" problems
with all these categories of bugs in case of inlining
(especially with LTO enabler) or code refactoring.
* Some of those issues may seems benign or irrealistic but it cost nothing
to patch so, why not do it?
We would be very interested to hear your opinion on these matters.
Are you interested in such errors and patches?
Also, besides the patches, we are currently working on a code analyzer
prototype designed to check asm compliance and to propose patches when the
chunk is not compliant. This is still work in progress and we are finalizing it.
The errors and patches I reported to you came from my prototype.
In case such a prototype would be made available, would you consider using it?
Best regards
Frédéric Recoules
hey, I have a doubt about UDPCast
Actually a few questions...
When have u made the last atualization in the software?
You still do it?
Can I use it for clone modern machines (2010-201X)?
Please answer as soon as possible, thank you
Can you please elaborate?
<Snip>
1) Is it possible to do the clone right through the server? I realize that there's dhcp configuration. When can I use it?
</snip>
From: udpcast-request(a)udpcast.linux.lu
Sent: February 18, 2019 6:00 AM
To: udpcast(a)udpcast.linux.lu
Reply to: udpcast(a)udpcast.linux.lu
Subject: Udpcast Digest, Vol 126, Issue 2
Send Udpcast mailing list submissions to
udpcast(a)udpcast.linux.lu
To subscribe or unsubscribe via the World Wide Web, visit
https://www.udpcast.linux.lu/mailman/listinfo/udpcast
or, via email, send a message with subject or body 'help' to
udpcast-request(a)udpcast.linux.lu
You can reach the person managing the list at
udpcast-owner(a)udpcast.linux.lu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Udpcast digest..."
Today's Topics:
1. Re: UDPCast (Gabriela Pinto)
----------------------------------------------------------------------
Message: 1
Date: Sun, 17 Feb 2019 08:36:31 -0400
From: Gabriela Pinto <gabi.souzap18(a)gmail.com>
To: Erik Jacobson <erik.jacobson(a)hpe.com>
Cc: udpcast(a)udpcast.linux.lu
Subject: Re: [Udpcast] UDPCast
Message-ID:
<CAGudYSbdpczNsw9d3d84PhXBmGNkqVa7WthDStC0dkhYLhW4mA(a)mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi,
I'm an student from Brazil, in the informatic area. I'm doing a work about
UdpCast, and I want to know some more about it. So I'll make you a few more
questions, ok?
1) Is it possible to do the clone right through the server? I realize that
there's dhcp configuration. When can I use it?
Em qui, 14 de fev de 2019 15:43, Erik Jacobson <erik.jacobson(a)hpe.com
escreveu:
> We have a couple custom modifications to udpcast but those don't impact
> basic normal function.
>
> We are using it for current distros (including sles15).
>
> It is working OK for us on the aarch64 architecture as well as x86_64.
>
> Thank you,
>
> Erik
>
> On Thu, Feb 14, 2019 at 02:40:05PM -0400, Gabriela Pinto wrote:
> > hey, I have a doubt about UDPCast
> > Actually a few questions...
> > When have u made the last atualization in the software?
> > You still do it?
> > Can I use it for clone modern machines (2010-201X)?
> >
> > Please answer as soon as possible, thank you
> > _______________________________________________
> > Udpcast mailing list
> > Udpcast(a)udpcast.linux.lu
> > https://www.udpcast.linux.lu/mailman/listinfo/udpcast
>
>
------------------------------
Subject: Digest Footer
_______________________________________________
Udpcast mailing list
Udpcast(a)udpcast.linux.lu
https://www.udpcast.linux.lu/mailman/listinfo/udpcast
------------------------------
End of Udpcast Digest, Vol 126, Issue 2
***************************************
THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.
Bonjour,
Je suis Vannapha, chargé de projet à l'Antenne AUF de Vientiane, je me
permet de vous contacter pour m'aider à résoudre mon problème. Je voudrais
faire le clonage d'un portable DELL core i5 (sous exploitation Ubuntu 16)
sur un ordinateur All in One Dell Core i3 via swhitch en utilisant UDP
Cast, mais le problème est que le moment où il faut choisir la la langue,
le clavier ne marche plus, même j'ai changé le nouveau clavier. J'ai
l'impression que UDP Cast ne connaît pas surtout les pilotes des
ordinateurs récents, est-ce que vous avez le moyen de mettre à jour UDP
Cast ? La version UDP Cast que j'ai utilisé est daté en 2009. Merci de
votre aide.
Bien cordialement,
--
Vannapha BOUPHAPANYA
Chargé de projet
Antenne AUF de Vientiane
Faculté d'Ingénierie
Bâtiment R1 - Campus de Sokpaluang, Université Nationale du Laos
BP: 7451 - Vientiane - RDP Lao
Tél : (856-021) 31 46 99
Mobile:(856-020) 28 03 51 93 - 020 77 71 31 30
E-mail : vannapha.bouphapanya(a)auf.org
*******************************************************
Adoptez l'éco-attitude.
PLEASE DO NOT PRINT THIS E-MAIL UNLESS A TRULY NEEDED
Hi steve
Please check the archives and the online documentation. (ie the command line page.)
Since you are using Windows, try --max-bitrate bitrate 10m|20m|40m. Etc...
Original Message
From: Dubois Steve
Sent: Tuesday, August 30, 2016 07:57
To: Brent Kimberley
Cc: 'udpcast(a)udpcast.linux.lu'
Subject: RE: Problem: UDPCast transfer breaks DHCP leases
Hi,
Thankyou for your answer, but I am using UDPCast in windows commandline, there are no examples included with the windows command-line programs.
Could you be a little bit more specific please?
Can you give me an example how to set these commandline parameters?
Much thanks in advance,
Steve Dubois
-----Oorspronkelijk bericht-----
Van: Brent Kimberley [mailto:Brent.Kimberley@Durham.ca]
Verzonden: vrijdag 26 augustus 2016 15:22
Aan: Dubois Steve
CC: 'udpcast(a)udpcast.linux.lu'
Onderwerp: Problem: UDPCast transfer breaks DHCP leases
>> We are facing a problem when using UDPCast in multicast mode. When I start a transfer from one pc to another, no problem.
>> I contacted network-support and they presume it could be a conflict with the VVPR (Virtual Router Redundancy Protocol) which also uses multicast.
>> udp-sender --ttl 1 and udp-receiver --ttl 1 udp-sender --ttl 2 and
>> udp-receiver --ttl 2 udp-sender --mcast-rdv-address 224.0.0.3 and udp-receiver --mcast-rdv-address 224.0.0.3 But the problem persists.
If possible, can you please verify what happens when udp-sender transmits at 10%, 20%, 40%, 80%, and/or 100% of the smallest pipe?
--max-bitrate bitrate
--rate-governor module.so:key1=value1,key2=value2 --bw-period seconds THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.
>> We are facing a problem when using UDPCast in multicast mode. When I start a transfer from one pc to another, no problem.
>> I contacted network-support and they presume it could be a conflict with the VVPR (Virtual Router Redundancy Protocol) which also uses multicast.
>> udp-sender --ttl 1 and udp-receiver --ttl 1 udp-sender --ttl 2 and udp-receiver --ttl 2 udp-sender --mcast-rdv-address 224.0.0.3 and udp-receiver --mcast-rdv-address 224.0.0.3
>> But the problem persists.
If possible, can you please verify what happens when udp-sender transmits at 10%, 20%, 40%, 80%, and/or 100% of the smallest pipe?
--max-bitrate bitrate
--rate-governor module.so:key1=value1,key2=value2
--bw-period seconds
THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.
Hello,
We are facing a problem when using UDPCast in multicast mode. When I start a transfer from one pc to another, no problem.
But when I start a transfer from one pc to two or more pc's, new booted clients can't get a ip-address from the DHCP-server anymore.
We have a rather complicated network, with lots of subnets.
I contacted network-support and they presume it could be a conflict with the VVPR (Virtual Router Redundancy Protocol) which also uses multicast.
I already played with several settings, like:
udp-sender --ttl 1 and udp-receiver --ttl 1
udp-sender --ttl 2 and udp-receiver --ttl 2
udp-sender --mcast-rdv-address 224.0.0.3 and udp-receiver --mcast-rdv-address 224.0.0.3
But the problem persists.
The problem only starts when the actual transfer is initiated. While udp-receiver is waiting for the clients to connect
there is no problem yet, but as soon as data is being transferred (multicast), new booted clients in the network can't find
the DHCP-Server, don't get an IP-addresses, can't PXE boot anymore.
I hope somebody understands what is going on here, and if there is a solution.
We really need udpcast in our environment.
Thanks in advance for all help.
Steve Dubois
ICT Manager Education City of Ghent
Belgium.
Hi there Richard,
I have been looking into Data-Diodes using UDPcast as well over the past
few weeks. I have seen speeds as high as 70Mbps on a 100Mbps ethernet
link. It is usually more like 50+Mbps as this example shows. The file sent
is 29,428,629 after uuencoding.
The receiver side CMD:
# time udp-receiver --interface p3p1 --start-time 30 --nosync --stat-period
2 --pipe /bin/uudecode
Udp-receiver 20120424
Compressed UDP receiver for (stdout) at 10.37.49.21 on p3p1
Connected as #0 to 10.37.49.20
bytes= 29 428 629 ( 54.48 Mbps))
Transfer complete.
real 0m4.680s
user 0m0.166s
sys 0m0.200s
The sender side CMD:
]# time uuencode -m ./bigtestfile test33file | udp-sender --interface p1p1
--pointopoint --stat-period 3 --async --max-bitrate 100M --fec 16x16
--mcast-data-addr 10.37.49.21
stripes=16 redund=16 stripesize=128
Udp-sender 20120424
UDP sender for (stdin) at 10.37.49.20 on p1p1
Broadcasting control to 10.37.49.255
Ready. Press any key to start sending data.
Starting transfer: 00000029
bytes= 29 428 629 re-xmits=0000000 ( 0.0%) slice=1024 - 00
Transfer complete.
I am using 3 ethernet NICs to accomplish this: Two on the sender side, and
One on the receiver. This is point to point and only about 8 feet in
distance. The purpose of the 2 NICs on the sender is this: only one
actually send the data 2 wires Tx. This NIC must receive "carrier" or
somehow know that it is in fact connected to a network. Therefore the
second NIC has its 2 wires Tx connected to the Rx side of the transmitting
or sending NIC. Additionally all NICs involved must have their ethernet
device attributes set the same manually. In my case that is 100Mbps half
duplex with no autoneg there may be other attributes involve depending on
the actual device used. All 3 NICs have and Ethernet ip address and
ifconfig {device} up to bring them up.
Since you are working with an actual Data Security Diode is a "Canary
GT-10SD". How would you characterize this poor man's data diode?
Also FYI: , no joy with upd-sender option "--nokbd". the sender is sending
but with checksum errors.
______________________________
Martin Tullier
Hi Rich,
Your implementation should be run well below "5GT/s".
* Look at the name plate of your back plane, storage, adapter, network adapter, logic, etc...
* Check the data flow(s).
* Determine Who is chewing up What - Where - Why - When - How - Rest ...
* perhaps one or more of components are running in an energy efficient mode ;-)
THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.
>> We can't get the network transmission [to exceed] 2-3 % [of nameplate]
What does iperf report?
Have you tried a link local subnet?
>> 1000Mbps
Have you tried Send Unreliable Datagram(UD) with immediate (or multicast)?
-----Original Message-----
From: Brent Kimberley
Sent: Wednesday, February 24, 2016 12:28 PM
To: 'richard.k.evans(a)nasa.gov'
Cc: udpcast(a)udpcast.linux.lu
Subject: RE: Udpcast Digest, Vol 123, Issue 1
Hi Richard,
Your performance on a general purpose machine should exceed the following.
384mbps @9000
395mbps @4096
352mbps @1456
312mbps @1024
193mbps @256
63mbps @64
Best Regards,
Brent
<snippet>
@REM cd %TEMP%
@REM fsutil file createnew test1.tx 2199023255552 @REM dir test1.tx
@REM cd %TEMP%
.\udp-sender.exe -b <blocksize> --autostart 5 --stat-period 2000 --max-bitrate 1000m --async --fec 8x8 --mcast-rdv-addr 127.0.0.1 --mcast-data-addr 127.0.0.1 --interface 127.0.0.1 --file test1.tx
@REM cd %TEMP%
.\udp-receiver.exe --file test.<blocksize>.rx --nosync --mcast-rdv-addr 127.0.0.1 --stat-period 2000 --interface 127.0.0.1
@REM del test*.* udp*.exe
</snippet>
< receiver observations>
UDP receiver for test.64.rx at 127.0.0.1 on Software Loopback Interface 1 Connected as #0 to 127.0.0.1 bytes= 2 097 152K ( 63.23 Mbps)) Transfer complete.
UDP receiver for test.256.rx at 127.0.0.1 on Software Loopback Interface 1 Connected as #0 to 127.0.0.1 bytes= 2 097 152K (193.83 Mbps)) Transfer complete.
UDP receiver for test.1024.rx at 127.0.0.1 on Software Loopback Interface 1 Connected as #0 to 127.0.0.1 bytes= 2 097 152K (312.40 Mbps) Transfer complete.
UDP receiver for test.4096.rx at 127.0.0.1 on Software Loopback Interface 1 Connected as #0 to 127.0.0.1 bytes= 2 097 152K (395.57 Mbps)) Transfer complete.
UDP receiver for test.9000.rx at 127.0.0.1 on Software Loopback Interface 1 Connected as #0 to 127.0.0.1 bytes= 2 097 152K (384.52 Mbps) Transfer complete.
UDP receiver for test.1456.rx at 127.0.0.1 on Software Loopback Interface 1 Connected as #0 to 127.0.0.1 bytes= 2 097 152K (352.54 Mbps) Transfer complete.
</receiver observations>
Message: 1
Date: Thu, 18 Feb 2016 18:39:30 +0000
From: "Evans, Richard K. (GRC-H000)" <richard.k.evans(a)nasa.gov>
To: "udpcast(a)udpcast.linux.lu" <udpcast(a)udpcast.linux.lu>
Cc: "Evans, Richard K. \(GRC-H000\)" <richard.k.evans(a)nasa.gov>
Subject: [Udpcast] maximum asynchronous speed and Jumbo Frames
Message-ID:
<DC3FB55EE7FEFD409A6FC1EA00D50D0B0F5C4510(a)NDJSMBX203.ndc.nasa.gov>
Content-Type: text/plain; charset="iso-8859-1"
Hello, I am using the UDPCast in asynchronous mode to transmit large data files through a Data Security Diode (mono-directional network).
Here is the command we use to transmit:
Udp-sender.exe --async --fec 8x8 --max-bitrate 1000m --mcast-rdv-addr 224.2.2.1 --mcast-data-addr 224.2.2.2 --interface <ipTx> --file myfile.dat
The Receive command I use is:
udp-receiver.exe --nosync --mcast-rdv-addr 224.2.2.1 --interface <ipRx> --f myfile.dat
Overall, this works well but we have noticed that we can't get the network transmission speed up above 2-3 % (22Mbps) of the Gigabit Ethernet adapter's full capability (1000Mbps). We also know that we are not processor limited, nor are we disk speed limited or anything else we can think of.
I know that the asynchronous mode application is for satellite transmissions that are understandably slower than what a file transfer purely over Gibabit Ethernet can do, so I am writing here to ask if any one has any thoughts or insights about what might be the core issue that keeps the process running so slow.
Fwiw, the Data Security Diode is a Canary GT-10SD, but for tuning UDPCast, we bypass the diode with a direct cable connection between Tx and Rx machines. So the performance of the system I am describing is without the diode in place.
Thanks in advance, folks.
-Rich
- Richard Evans, NASA GRC - Plum Brook Station ? http://www.linkedin.com/in/rkevans
???216.973.4398
------------------------------
_______________________________________________
Udpcast mailing list
Udpcast(a)udpcast.linux.lu
https://www.udpcast.linux.lu/mailman/listinfo/udpcast
End of Udpcast Digest, Vol 123, Issue 1
***************************************
THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.
