repeat transmission of UDP packets

[Alan Knowler]

Hi,

New user of YAT, wondering if this is possible... (can't find much in the way of help / instructions)

I'd like to send a short UDP packet repeatedly for n times. A bit like hitting Send Text / F3 repeatedly.
Can this be done? Ideally with a specified delay between each Tx, and if changing the UDP packet content.

I've found that if I create a text file containing multiple lines then whole text is sent as one UDP packet - which isn't what I want.

Thanks

[Alan Knowler]

Answering my own question (didn't look hard enough...) LineRepeat is my friend)

[Maettu]

Glad you found this. Note the screenshots at https://sourceforge.net/projects/y-a-terminal/ as well as Help > Quick Reference... which give you an idea what you can achieve with YAT.

[Alan Knowler]

Seems that if I reduce the Delay to 10ms or less then the UDP packets I'm transmitting tend to merge into 1 packet, for instance;
Text1!(Delay(10))!(EOL)Text2!(Delay(10))!(LineRepeat(100))
Transmits the following;

Text1Text2
Text1Text2
Text1
Text2Text1Text2
Text1Text2
[...]

Slower Tx Delay intervals don't result in this and I see the expected behaviour;
Text1
Text2
Text1
Text2
Text1
Text2
Text1
Text2

Anything I can do to improve the transmission when using Delays of 10ms or less

Thanks

[Maettu]

Hi Alan,

Some considerations:

• By default, YAT UDP/IP terminals configure EOL = None and Break lines on every chunk (Terminal > Settings... > Text...)
• Did you capture the above shown lines with e.g. Wireshark? Or are these the lines as shown in YAT?
• Do you necessarily require the data being sent in separate packets? While the terminal does flush on each Delay or after EOL, the underlying UDP/IP socket abstraction indeed performs buffering (in order to optimize throughput). For serial COM ports, USB Ser/HID and TCP/IP this has never been an issue. COM ports and USB Ser/HID only care about chunking when software flow control is active, or some COM/USB converter has hardware limitations. TCP/IP is intended to be a stream, chunking is done by TCP anyway. But looks like I have to reconsider this for UDP/IP. Shouldn't be that much work, should easily be doable for the upcoming YAT 2.5.1 release.
• Keep in mind that Windows (and .NET) has limited real-time capabilities. Timing in the low ms cannot be guarenteed. YAT tries its best to be as fast as feasible (View > Disable Formatting improves a lot) and provide time stamps as close to reality as possible (View > Show Time *). But there really are limits.

Best regards,
Matthias

[Anonymous]

Matthias,
Many thanks for taking the time to reply so comprehensively .
- The capture is the YAT Display window, however the UDP server that I've written also receives the YAT output as shown on the YAT Display.
- 'Do you necessarily require the data being sent in separate packets? ' Yes - the data I receive on my UDP server (that I'm testing with YAT) expects discrete UDP packets, I'm stress testing this so trying to fire fairly small packets (<40 byte payload) from different clients with short inter-packet gaps.

[Maettu]

Got it, definitely makes sense for UDP/IP => change request #472 "UDP/IP shall retain messages as chunked by the terminal" created.

[Maettu]

Hi Alan,

I have implemented the above stated change and provided preliminary binaries via Dropbox. Please check whether they fulfill your requirements and let me know.

Note that YAT Release Notes.txt lists all changes from YAT 2.5.0 to the preliminary binaries.

Best regards,
Matthias

[Maettu]

PS: There is one important thing I would like to point out. With YAT 2.5.0, stressing UDP/IP throughput among a YAT UDP/IP client/server pair was around 60'000 bytes/second. With the change newly implemented, the throughput dopped to around 3'000 bytes/second, i.e. around 20 times less.

The root cause for this drop is pretty simple: To achieve maximum throughput, YAT 2.5.0 buffered data and created datagrams of maximum safe IPv4/IPv6 size (508/1212 bytes). With the newly implemented change, there are typically many more datagrams to send, resulting in many more system calls, resulting in lower throughput.

With your uses cases, do you think this drop to around 3'000 bytes/second is acceptable? Personally, I think YAT should make this behavior configurable, e.g. UDP Data Send Mode: Retain packets by sending individual datagrams (packet mode) vs. Optimize throughput by maximizing datagrams (serial stream mode) with some additional information on the behaviors. What do you think should be the default setting?

Both modes have pros and cons. And there are use cases for both modes. The serial stream modes is e.g. used when using a UDP/IP port for logging data from a device. In this case, packet chunking is irrelevant. For uses cases as seeing further above, the packet mode is the only feasible approach.

[Anonymous]

Maettu,
Many thanks for doing this, could you let me know where I can find the dropbox for this version; if I use the Download link then I get the previous version.

[Maettu]

Hi Alan,

I added you as knobbly@users.sourceforge.net to the YAT dropbox folder yesterday. You should have received an email. In the past, this approach did work.

In case this didn't work, I have just sent you the YAT dropbox folder as link via the SourceForge Send Message feature.

Also note that I have just refined the above idea for providing a UDP Data Send Mode in YAT.

Best regards,
Matthias

[Maettu]

Alan, any update on this one? Please note my questions 3 posts further up.

[Alan Knowler]

Maettu,
Yes – works a treat thank you!
The throughput is fine for my purposes, as my data packets are fairly small (around 20 to 50 bytes) for short bursts with short inter-packet delays, so 3k is not a problem. As you suggest making this configurable would add a degree of flexibility.
Thanks again for taking time to implement this.

[Maettu]

Alan,

Very good! Let me know if you find anything not working good enough.

Best regards,
Matthias