You are not logged in.
Hi
I modified theCSMA code ( ofdm reference design _04) according to my requirements not touching the original code.performed an experiment of trafering UDP packets.its like for every packet that the emac gets from ethernet, its transmiting max possble times(max resend lets say its 8) even if gets the ack,it completes transmitting the same packt maxresend times and than strts transmitting the next pckt. so its like if emac gets 100 packts to send acks received are like let say 500.
to solve this i removed the line
if(warpmac_inTimeout()) and replaced warpmac_clearTimer(TIMEOUT) (i think this function is not defined) with warpmac_clearTimer().
now it gets out of the loop if it receives ACKPAcket.
but still sometimes i am getting more acks than that of the pckts that emac has to send.
Can you explain this??
Thanks
Offline
this was hapning originally before i made the mentioned changes
sending a nonARP packet
WANNAUSECOOPMAC is 0 - hence not being used
the packet sent on first go
the packet has been sent after some backoffs...
the packet has been sent after some backoffs...
the packet has been sent after some backoffs...
the packet has been sent after some backoffs...
Total Gain = 40
packet type:ACKPACKET
the packet has been sent after some backoffs...
the packet has been sent after some backoffs...
the packet has been sent after some backoffs...
Total Gain = 38
packet type:ACKPACKET
the packet has been sent after some backoffs...
???????????????????
Offline
SRS wrote:
this was hapning originally before i made the mentioned changes
sending a nonARP packet
WANNAUSECOOPMAC is 0 - hence not being used
the packet sent on first go
the packet has been sent after some backoffs...
the packet has been sent after some backoffs...
Is this text being printed by a WARP node during a packet exchange? If so, this modification to the MAC code is likely the source of your problem. the xil_printf() function is blocking- it only returns after the print via UART finishes. In order to print the text "the packet sent on first go\r\n", at least 261 bits of data are sent over the UART interface. At a serial datarate of 57600bps, this print requires at least 4.5ms. In other words, the receiving node will have sent an ACK long before the transmitting node finishes printing the debug message.
For debugging behavior on MAC timescales, we use an oscilloscope to observe digital outputs corresponding to packet events (Tx, Rx, etc.). These signals are routed to the digital debug header on the FPGA board for exactly this purpose.
Offline
actually if we look at the output on tetermpro
sending a nonARP packet<<<<<-------------------------this is the o/p wen a new packet is about to be transmitd (1)
WANNAUSECOOPMAC is 0 - hence not being used
the packet sent on first go<<<<<<<<<-----------------------here pckt is sent frst time
the packet has been sent after some backoffs...<<<<-------second time
the packet has been sent after some backoffs...
the packet has been sent after some backoffs...
the packet has been sent after some backoffs...
Total Gain = 40
packet type:ACKPACKET<<<<<<<<<<------------here i receive ack for this pckt
the packet has been sent after some backoffs...<<<<------here transmission of the same pckt(it sud have been (1) here, a new pckt)
the packet has been sent after some backoffs...
the packet has been sent after some backoffs...
Total Gain = 38
packet type:ACKPACKET
the packet has been sent after some backoffs...
???????????????????<<<<<<<<<<<<<<<<<-------this is printed wen maxresend has been achieved (s0 inspite i received ack for the pckt, it sending the same pckt till maxresend is achieved and then strts sending a new pckt)
Can you explain this behaviour that it is not getting out of the loop even after receiving acks?
Thanks
Offline
The printout above suggests that the transmitting node is receiving an ACK, but it's arriving a very long time after the first packet transmission.
I'll repeat my earlier point- you cannot include xil_printf statements inside the routines that must handle MAC events in real-time. The behavior of MAC code is not meaningful when the vast majority of processing time is dedicated to waiting on xil_printf() to complete.
Offline