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.
Could udp-sender.exe and/or udp-receiver.exe be converted to Windows service? How does it work? Thanks in advance.
Very respectfully,
JR Aratea
"Protect society, the commonwealth, and the infrastructure."
FOR OFFICIAL USE ONLY - PRIVACY SENSITIVE This electronic transmission may contain information intended only for the person or persons named above. Any misuse or unauthorized disclosure may result in both civil and criminal penalties. **If you receive this transmission in error, please notify the sender at the telephone number or e-mail address listed. Thank you.
Do UDP-sender.exe and udp-receiver.exe be converted to Windows service? How does it work? Thanks in advance.
Very respectfully,
JR Aratea
"Protect society, the commonwealth, and the infrastructure."
FOR OFFICIAL USE ONLY - PRIVACY SENSITIVE This electronic transmission may contain information intended only for the person or persons named above. Any misuse or unauthorized disclosure may result in both civil and criminal penalties. **If you receive this transmission in error, please notify the sender at the telephone number or e-mail address listed. Thank you.
Good afternoon,
I need to add more network adapters in udpcast list, as is the step by step
procedure?
Adriano das Neves.
---
Este email está limpo de vírus e malwares porque a proteção do avast! Antivírus está ativa.
https://www.avast.com/antivirus
Hello to the great team behind udpcast (hope this mail reaches you)
I have a question about an odd thing that I have seen while using udpcast.
As you can see there are 1544 and 96 length frames mixed together , I
suspect that this may cause some errors on my setup.
Could you tell me if these mixed lengths are a result of how udpcast works?
What exactly is happening here? because this is unexpected for me.
mac #5: frame-len=1538 (nzld=0), subframe-len=1544
mac #6: frame-len=1538 (nzld=0), subframe-len=1544
mac #7: frame-len=1538 (nzld=0), subframe-len=1544
mac #8: frame-len=90 (nzld=0), subframe-len=96
mac #9: frame-len=90 (nzld=32), subframe-len=96
mac #10: frame-len=90 (nzld=32), subframe-len=96
^ sample , this pattern of interwoven lengths 1544/96 repeats itself in the
transmission.
Thanks and best regards.
Jeff.
We use udpcast in an environment somewhat based on systemimager but
highly modified.
We have run in to a very sad situation where a particular model of switch
decides it doesn't want to pass the multicast data packets and none of them
get through. It is an extremely hard problem to duplicate because it seems
to work 99% of the time.
The end result when we hit the problem is the udp-receiver "waits forever".
So I've begun to consider setting some additional timeouts in the system
to try to work around this switch problem.
I investigated receive-timeout and start-timeout. Since I'm never able
to reproduce the problem "on demand", I emulated the problem by using
iptables to block the data stream packets.
I found that receive-timeout isn't in play in a situation where not one
data channel packet has been sent. However, start-timeout is in play.
There seem to be a couple select()-like situations that use the start-timeout.
Prior to the "Connected as" message in udp-receiver, if you hit start-timeout
there, udp-receiver will exit with an exit code that can be captured by a
script for a re-try. However, the selectWithConsole() call in
dispatchMessage(), while returning a 0 on select timeout, the caller
(netReceiverMain()) doesn't test the return value of the timed out transfer.
It turns out selectWithConsole is where I hit the timeout for the "no
multicast data packets transferred" problem.
After digging further, I realized this is likely because there are threads
involved and this makes it more complicated to handle status.
I'm rusty with my C but I came up with a work around to get us going. I am
not suggesting that this is a good solution, but it does solve it for me
and could be used as an illustration of my problem. Maybe some of you
experts can quickly come up with the correct solution.
Basically, I exit with 100 if zero bytes were transferred. Then I can test
that easily in our scripts and re-try if needed in some sort of loop.
I realize the correct solution is to exit with an error code if the
selectWithConsole() call in dispatchMessage() times out, but it looked
hard to deal with when combined with my C-programming rust.
Other suggestions welcome. Attached is my "patch" for illustration reasons
and not a suggested "fix" for the problem.
Erik
Hallo guys,
Exsist an 64bit windows Version from udpcast?
Greetings
Frank Aust
EDV-Beratung agnw&sgnw
Mettmann + Goldbach + Saulgrub
Welfenweg 9, 82442 Saulgrub
fon 08845 7578340, fax 08845 7578342
www.sgnw.de, mail(a)sgnw.de
Sitz des Unternehmens: Saulgrub, Inhaber: Klaus Heitkötter,
Steuernummer: 119/227/30387
Dear udpcast-Team
I just wanted to make an Image with your custom udpcast configurator. As I Started our System with the boot cd the program couldn't find the right network Module. So I had to select the Right One manually. The Problem is that I Need Modules for
Intel(R) Dual Band Wireless-AC 7260
Intel(R) ethernet Connection i218-lm
Is there a Way to integrate Those Modules by myself or is it possible to add Those ?
Mit freundlichen Grüßen/Kind regards
Tobias Hues
I don't know about rhel-7-x86_64 but with both fc-20 32bit and 64 I get the
following error after doing ./configure then make.
In file included from console.c:7:0:
console.h:25:9: error: unknown type name ‘fd_set’
fd_set *read_set, struct timeval *tv,
^
make: *** [console.o] Error 1
My fix was to console.h to add
#include <sys/select.h>
After adding that line, and rerunning make it compiles on both the 32bit and
64bit fedora 20 machines I have. Don't know if this patch is effecting the
whole thing, or if this addition might cause problems building on other
systems. Just found where fd_set was defined and added the include.
On 16 Jul 2014 at 15:39, Alain Knaff wrote:
Date sent: Wed, 16 Jul 2014 15:39:00 +0200
From: Alain Knaff <alain(a)knaff.lu>
To: udpcast(a)udpcast.linux.lu
Subject: Re: [Udpcast] Patch that fix build on rhel-7 and fc-20
(fd_set
problem)
> On 16/07/14 15:22, Olivier LAHAYE wrote:
>>
> >Hi,
>>
> > Here is a patch to udpcast that fixes the build problem on
> > rhel-7-x86_64 and fc-20-x86_64.
>>
> > Please review the patch, merge it to the source-tree and provide a
> > updated tarball.
>>
> > Thanks in advance.
>>
> >Olivier.
>>
>
> Could you maybe first start with explaining what "the" build problems
> on rhel-7 and fc-20 are?
>
>Thanks,
>
>Alain
>
>_______________________________________________
> Udpcast mailing list
>Udpcast(a)udpcast.linux.lu
>https://www.udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast
+----------------------------------------------------------+
Michael D. Setzer II - Computer Science Instructor
Guam Community College Computer Center
mailto:mikes@kuentos.guam.net
mailto:msetzerii@gmail.com
http://www.guam.net/home/mikes
Guam - Where America's Day Begins
G4L Disk Imaging Project maintainer
http://sourceforge.net/projects/g4l/
+----------------------------------------------------------+
http://setiathome.berkeley.edu (Original)
Number of Seti Units Returned: 19,471
Processing time: 32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)
BOINC@HOME CREDITS
ROSETTA 17621215.996525 | SETI 29126476.308997
ABC 16613838.513356 | EINSTEIN 28060690.358937