You are not logged in.
Hello,
I've programmed a protocol on the warp platform. Now I would like to do some measurements on the performance
of this protocol compared to other protocols.
I have realized that using xil_printf() in Mac-Functions is not a good idea, due to its blocking behaviour.
But how can I get my measurements (e.g., what packets have been received/lost etc.)?
Thanks!
Regards
Guenther
Offline
We use two methods, depending on what's being measured.
For short timescales, like measuring inter-packet latencies, we use an oscilloscope connected to the FPGA board's digital I/O. This allows us to very precisely measure the timing of events at one node (this is how we characterize our the OFDM reference design's DATA-ACK turnaround, for exaxmple).
For longer timescales, we program a node to gather statistics internally, then retrieve these via a printf periodically. You can process keyboard events in the UART handler (like in csmamac.c) or respond to push buttons in the user I/O handlers.
Offline
I'm using ethernet for this purpose. You can easily create custom packets filled with the desired informations and send these via ethernet. On PC side you can use wireshark, for example, to capture these packets, or you program a capture program using the PCAP library. Using PCAP has the advantage, that you can directly convert the packets content into the right format. It works very good and as ethernet works with 100Mbps you don't have performance lost, provided that the packet generation takes not much time, i.e. the packets generated are simple and not too big.
Offline
Domenique's is a great suggestion. There's a helper function in warpmac.c- warpmac_sendRawEthernetPacket(void* packet, unsigned int numBytes). Just pass it a pointer and a length, and it will send the corresponding data over Ethernet without any other processing. You can construct a custom Ethernet frame in memory containing whatever statistics information you need and send it over-the-wire like this.
One thing to keep in mind- depending on your applicaiton, there will be good and bad times during an experiment to use the Ethernet this way. If you're building a wired-wireless bridge, for example, the best time to send a statistics packet would be immediately after sending a wireless->wired packet over Ethernet. During this period, you're almost guaranteed to avoid a conflict, since the wired transmission is so much faster than the next wireless reception.
Offline
Thanks for the advice with the good and bad times for sending the statistics packet. I took time measurements with sending these packets and without and observed no conflicts.
As you described I'm using the warpmac_sendRawEthernetPacket(void* packet, unsigned int numBytes) function to send these packets. Now, when taking measurements this way, until a certain time everything works very fine. But as soon as I exceed a certain measurement time (>~30 min), I get the following error message "DMA threw bus error!", and I have to restart the boards as no packets are forwarded to ethernet anymore. For the measurements I'm using a cbr udp stream, i.e. in 30 min between 1*10^6 and 2*10^6 of these statistic packets were send additionaly to the normal packets that are forwarded to ethernet.
Can this problem be solved or avoided somehow?
Thanks,
Offline
That error gets thrown in warpmac.c and indicates the DMA core itself observed an error on the bus. You can read more about the error conditions in the xps_central_dma datasheet ($XILINX_EDK/hw/XilinxProcessorIPLib/pcores/xps_central_dma_v2_00_b/doc/xps_central_dma.pdf). We haven't seen this error in our testing (we put the check in warpmac while debugging some other stuff).
The current code just returns when the error is observed. Before that point, the function doesn't change any state, so the error likely occurred as a result of earlier code. I'd suggest checking for the return value of warpmac_sendRawEthernetPacket(); if it's XST_FAILURE, add some printfs to check the state of your program (buffer addresses, lengths, etc.). You could also try adding a DMA reset in the case of this error (XDmaCentral_Reset(), from the dmacentral_v1_11_a driver).
Offline
Thank you very much for your proposals.
One question regarding the sending of ethernet frames with
warpmac_sendRawEthernetPacket(void* packet, unsigned int numBytes)
Where does the payload come from (or is packet simply a byte array)?
Thank you very much.
Regards
Günther
Offline
Ok, my error was not to load the data into the warpmac_buffer(int index).
Thanks
Regards
Günther
Offline
The first argument to warpmac_sendRawEthernetPacket() is a pointer to the first byte of the packet you want to send. The memory containing the packet must be accessible on the PLB; it cannot be in the IOCM or DOCM, as the DMA controller used to copy the payload into the EMAC cannot access those memory sections. As you mentioned, using the spare PHY packet buffers (which all reside in the second xps_plb_bram instance) are a good choice. Just be sure not to use the sub-buffers at indicies 0, 1 or 2; these are used by the MAC for Rx/Tx of over-the-air packets.
Offline
Thank you very much!
Now I have another problem:
All is working properly on our computers in the lab (they run with windows xp and have two network cards - one dedicated to a warp board) - there I can receive the status packets I send from the warp nodes with wireshark.
But when I use our laptops (lenovo t61, windows xp) this does not work - wireshark does not receive these packets. I already disabled the firewall, the other connections (w-lan etc.) but it still does not work. I have set the connection to a manual ip address of, e.g, 10.0.0.1 (just like I did on the computers in the lab) - but it simply won't work.
Hopefully, someone has some suggestions.
Thank you!
Regards
Günther
Offline
Are the laptop Ethernet interfaces configured for auto-negotiation? Do they establish a link at 100Mbps/full-duplex with the WARP board? Does the Ethernet driver allow Wireshark to capture packets in promiscuous mode? If you connect the laptop to some other Ethernet device (like another PC), does Wireshark see any packets?
Offline
Although it seems to simple... Do you maybe run the laptops with battery and Windows or any Lenovo Tools disables the Ethernetcard for power saving then? Happened to me once and kept me searching for a while...
Offline
Thank you very much for your replies!
The problem was obviously with the implementation.
I recompiled all sources (also the hardware components) which solved the problem.
Perhaps on the laptap a previous version of the reference desigen got mixed up with the newer one.
Thanks very much!
Regards
Günther
Offline