Multiple UDP listener problems with uIP stack

[lilltroll]

TCP runs on the XDK.
I send an arrays of data of arbitrary size over TCP from MATLAB -> XMOS receives the array, add one to each number add sends it back - MATLAB controls the result.

Beginners questions

Does it handle multiple parallel calls?

As I have understood it, an advanced httpd on a multi threaded OS typically create a new thread for each incoming access with a maximum limit of parallel access. Is that the socket numbers ??

Is the TCP/IP layer "full" TCP with control of data integrity/resend without duplication or losing data ?

[BEBDigitalAudio]

By "parallel calls", I suppose you speak of parallel TCP connections.
In that case, the answer is yes. Just create as many TCP sockets as you need (each TCP socket will handle a dedicated connection)
For example, if you create five TCP sockets listening to port 80, the board will be able to handle five parallel TCP connection (so five clients will be able to connect in parallel to your server)

Concerning the retransmission of lost packets, it is implemented, but I did not test it (right now, I have no use of TCP, so I concentrate on UDP only).

MERRY CHRISTMAS TO ALL XCORE MEMBERS :P

[lilltroll]

Working with the UDP for the moment. Sending a short package from the host, and thereafter sends a package back with 256 int32.

With a little inline modification in the most often accessed socket methods I get around 25Mbit receiving Ethernet load on the host, attacking the XMOS with 5000 short packages. (I stream the data to host RAM, checking the data integrity is done offline to not disturb the measurement)

The XTAG USB link doesn't seem to like being connected to the computer together with an twisted Ethernet cable directly.
The XTAG is stable for some seconds. When I used a switch in between on the Ethernet side, I didn't have any problem.

[BEBDigitalAudio]

I am using the XSockets to stream digital audio over RTP (and thus, over UDP)
I made some quick measurements, but as far as I remember, I was able to send more than 25Mbps (was around 40 Mbps if I remember well)

I am using a cross cable for the network, and I did not have any problem (whatever I use the XTAG or not)
Moreover, I do not see why the XTAG should be disturbed when you use a cross cable.

What happens with the software under your test configuration ?

[BEBDigitalAudio]

Version 0.4 of the XSOCKETS library is available for download

Here are the main changes from previous version :

Status changed to alpha release
Bugs corrected in some low level functions
New functions added in client

More details available in release_notes.txt file

[lilltroll]

I am using the XSockets to stream digital audio over RTP (and thus, over UDP)
I made some quick measurements, but as far as I remember, I was able to send more than 25Mbps (was around 40 Mbps if I remember well)

I am using a cross cable for the network, and I did not have any problem (whatever I use the XTAG or not)
Moreover, I do not see why the XTAG should be disturbed when you use a cross cable.

What happens with the software under your test configuration ?

Speed: Are you using larger packages than 1024 bytes?
Everything involving the XTAG connection fails, programming, flashing, the program looses the Console connection after just some seconds and so on. It's only working for 3-10 s. If I remove the Ethernet cable it works again.

I haven't controlled how the shield of the USB cable and the Ethernet cable is terminated. Maybe Ethernet signalling decreases SNR in the USB transmission due to ground loops since I use a shielded Ethernet cable. (Ethernet signal side has signal transformers)
But with the switch between the ground loop is maybe handled "correctly".
But I do not expect the SNR difference to be so large that it destroys the USB-com.

[BEBDigitalAudio]

Liltroll,

yes, my RTP application is using PCM packets around 1024 bytes.

Concerning the XTAG failure, I do not think that the shield is the origin of the problem. Ethernet links are isolated on both sides by transformers, and the risk of ground loops is really minimal, even through the decoupling capacitors between shield and ground.

But the console crash can come from another problem. I have seen on my own development system that the serial link used for the console is a real pain, since there is no buffer on the serial port (the full message must be transferred before the thread resumes)

To give an idea, when I switch off the console output on my echo test program, the latency of XSOCKETS on a UDP socket is around 300 microseconds (so we can roughly say 150 microseconds to process the incoming message, and 150 microseconds to send it back).

When I set a console message in each loop iteration (so I get one debug message on the console for each message coming from UDP), the latency reaches an incredible value of around 200 milliseconds (around 700 times worse :shock: )

I am trying to avoid the console as much as possible due to that.

In your case, I think that the console is making the Ethernet buffer overflow, because messages are not processed fast enough (and when you remove the cable, it gies enough time to the processor to purge the queue)

[lilltroll]

Hmm, I will try it on my Core i7 or check with another tool. I only used the Win7 Activity monitor for Network monitoring.

I have to say that I have underestimated the benefit of Ethernet and overestimated how hard it would be to start using it. Platform independent, and at least TCP/UDP package will be supported by all hosts OS.
With USB, you need different drivers for each OS, and different OS includes different OS support - and you might end up in waiting for someone else to write a OS USB driver, that will not be functioning in the next OS version. A TCP/IP stack is also included in most available program languages.

In some hours I have write a PC application that can communicate the way I want with the XMOS side.
For Pear-to-Pear it have never failed using UDP. Will try to add more PC clients requesting data at the same time.

I can recommend the XDK, even if it hasn't a competitive price compared to solutions from other vendors, but the touch-LCD makes it easy to use the screen and change parameters without recompiling compared to using the console. Maybe not as good looking as an iPad, but handy yo be in a box, with clamp-diodes and protection on the external ports. I always manage to drop something conducting on non boxed boards exactly at the wrong place.

A 1-bit Xor buffer (Inverts the pixel) only takes 9.6 kB, and most of the rest can be done with a quad line-buffer, rendering lines in realtime even at frame-rates of 50-60Hz. I just started my first project using my own makefile, so I hope I can make some modules and GIT it soon.
Give me some more weeks, and I will get some deeper understanding of the OSI-stack as well. After that only the CPLD will be a blackbox in the XDK box.

[Folknology]

Love this quote:

I have to say that I have underestimated the benefit of Ethernet and overestimated how hard it would be to start using it. Platform independent, and at least TCP/UDP package will be supported by all hosts OS.

+1 TCP/IP universal open interface Mika
;-)

regards
Al

[BEBDigitalAudio]

You have already made the first step to become an unconditionnal IP lover like me then, liltroll.

What I will write here is a little bit out of topic, but this will help you to understand why I can not bear anymore USB or FireWire. Here is a little (true) story...

Once upon a time :?
Ooops, a long time ago (15 years), a company named Philips designed a computer peripheral bus, based on I²C standard (I can not remember the name right now...). In parallel, Intel (along with Microsoft) was designing a concurrent solution named USB.

The company where I was working at this time was deeply involved in computer communication. One day, we received an invitation from Intel for a presentation in Paris, where the guys from Intel tried to convince us that USB1.0 (1Mbps...) was the future and they started to present us some dedicated components made by them. We bought a SDK (quite expensive) from Intel, because they were making a special offer just for this presentation.

At this time, all USB interfaces must be based on 80C52 core (because the USB core must be licensed from Intel). After a few weeks of hard investigation (since almost no support was available from Intel), we tried to connect our test setup to a PC, for which we bought an expensive USB expansion board (they were not so common at these times, believe me)

And then, my smile quickly fade down, because the computer was simply unable to do anything with our board. Since there was a driver for the computer (running under Win95) provided by the board manufacturer (a company named Intel...), I could not understand why nothing was working. After some calls in USA (because Intel Europe was knowing absolutely nothing about USB), we learned that we had to write a specific driver for Windows for our board. What???? But why is there a driver for the board then?
Intel "forgot" to tell us during the meeting that the board driver is just an API driver, but at kernel level, over which another driver has to be written. We then discovered to joy of writing a VxD driver (for which we had to become a MSDN member, to get access to the SDK...)

It took us around 6 months before we could get something almost working under Win95 (any crash in the driver leading to a superb blue screen). Our sales department was already looking to sell this product (typical sales behaviour) when we discovered another very, very funny thing. There was a constant coded in our firmware, named ManufacturerID. The value in this constant had to be changed, otherwise the BIOS was displaying that our board was made by Intel.

And then we discovered that Intel also "forgot" to tell us that we had to request our own Manufacturer's ID to the USB standard group, but this could be done only if we became members of this group, because we needed also a magical value, named Product ID, which can be obtained only from them.
So, after a full year of development, we still did not have any working product, but we had paid already a lot of hidden fees...

But another funny thing was coming... in a very short time, Microsoft released Win98 and Win Me... which was supposed to use a different driver model, needing another development chain. The maintenance of the driver was becoming horrific, even before our product was released.

I left the company just before XP was announced, and my colleagues told me that XP driver's model was once again different... and the USB API was once again changing, because of USB2.0 development :shock:

When you compare Ethernet to USB, it appears like heaven!
No drivers to deal with... you can easily port your code from Windows to Mac to Linux to anything else. And even time critical applications are becoming quite common over Ethernet (look to AVB)

Our product, the KissBox, currently runs over a standard microcontroller (with an ASIC next to it), and it gives better performance over MIDI than USB (the RTP-MIDI processing in our Box is lower than 1 ms... and the new version, based on a XS1 is already giving latencies lower than 300 microseconds, without any optimization :D )