For 256/512/1024 bytes of datagram, there is no error in the receiving side.
But 64/128 bytes of datagram, there occurs missed packets in the receiving
side.
So, I added some debugging code to check every ethernet packet to count the
number of packets with specified UDP port in BSP. But results is just the
same with above.
Anyone has some ideas about this problem?
Thanks.
chkim in korea.
Speaking only for myself,
Joe Durusau
Not collisions - they are completely benign. The ethernet MAC engine
will automatically retransmit them.
>
> Speaking only for myself,
>
> Joe Durusau
>
> chihwankim wrote:
>
> > I have two MPC8260 boards A and B. I open UDP socket both of them and try to
> > transmit and receive UDP packets for each size of datagram. I assume that A
> > is transmitting UDP datagram to B every each 10ms and B is receiving
> > datagram from A.
Are you sure you are sending one every 10ms?
That is only 100/sec nothing should fail at that data rate!
> >
> > For 256/512/1024 bytes of datagram, there is no error in the receiving side.
> > But 64/128 bytes of datagram, there occurs missed packets in the receiving
> > side.
So big packets are ok, but you get errors with small ones.
Mmmmmm....
If you really do have the tx rate capped properly then something is
definitely awol in the receiving system.
If you don't have the tx rate capped, then you are probably seeing
the effect of marginally different costs in transmitting and
receiving packets. (cost/byte + cost/packet)
Check with some LAN monitor software that the packets are all txed.
David
Are these custom 8260 designs or evaluation boards ? And the software (i.e. the
drivers) ?
Did you do the port, or are they stock ? Are you sure you have the latest
drivers ? I know WRS
has fixed at least 1 or 2 bugs in the FCC driver...
I'm assuming this is Ethernet on the FCC, not SCC. And do you only have 1 FCC
active ?
>> >
>> > For 256/512/1024 bytes of datagram, there is no error in the receiving side.
>> > But 64/128 bytes of datagram, there occurs missed packets in the receiving
>> > side.
>
>So big packets are ok, but you get errors with small ones.
>Mmmmmm....
>
>If you really do have the tx rate capped properly then something is
>definitely awol in the receiving system.
>
>If you don't have the tx rate capped, then you are probably seeing
>the effect of marginally different costs in transmitting and
>receiving packets. (cost/byte + cost/packet)
>
>Check with some LAN monitor software that the packets are all txed.
The original poster said he added some code in the BSP to
count packets with the correct UDP port - was that on the Tx or Rx side ?
If it was the Rx, you might want to add code to the Tx side to make
sure all packets are getting Tx'd. Also, do you see any MAC layer
Tx or Rx errors ? If you're sure the packets are being Tx'd, you might
{ip,udp}StatShow and see if they tell you anything.
See what statistics are available to you from the driver on both Tx and
Rx sides, that may give some clue.
hth,
Dan Gold go...@ensemble.com
The result shows that PC received all the datagram from 8260 A without any
missing, but 8260 B still has missed packets. The ratio is just the same
with 8260 to 8260 case.
And I added a code in BSP ethernet driver to check TX packets with specified
UDP port, and the count is just the same with
application-transmitted-packets.
For understanding, below is the result of udpstatShow() when TX count=5328,
RX count=5324(4 missing)
----------------------------------------------------------------
TX side
-> udpstatShow
UDP:
5343 total packets
15 input packets
5328 output packets
0 incomplete header
0 bad data length field
0 bad checksum
12 broadcasts received with no ports
0 full socket
3 pcb cache lookups failed
3 pcb hash lookups failed
RX side
-> udpstatShow
UDP:
5324 total packets
5324 input packets
0 output packets
0 incomplete header
0 bad data length field
0 bad checksum
1 broadcasts received with no ports
0 full socket
5323 pcb cache lookups failed
3 pcb hash lookups failed
----------------------------------------------------------------
What can I do further?
thanks.
"Dan Gold" <nos...@newsranger.com> wrote in message
news:yEk%7.11864$cD4....@www.newsranger.com...
They were close enough to each other to work most of the time!
Packet loss was 3-4%.
--
Regards,
Graham Baxter (VxWorks and pSOS BSP'S)
Freelance Software Engineer
gba...@NOSPAM.bcs.org.uk
thanks.
chkim
"Graham Baxter" <gba...@NOSPAM.bcs.org.uk> wrote in message
news:3C3F1A42...@NOSPAM.bcs.org.uk...