Closed interactive-matter closed 12 years ago
sorry, there was something else wrong/right does not work anymore - giving really up
I don't have the code here but by the name I'm guessing it is the client queue size.
The memory management has undergone several revisions and so the count of the buffers is no longer as relevant as it used to be.
I'll give you more details on Monday.
David Norman Bristol
On 15 Dec 2011, at 17:45, "Interactive Matter" reply@reply.github.com wrote:
I have solved the mysteries of my issue #20:
I had to set
define NUM_MII_RX_BUF 5
define NUM_MII_TX_BUF 5
but I had set it to
define NUM_MII_RX_BUF 20
define NUM_MII_TX_BUF 2
(which I copied from some other ethernet_conf.h)
It took me 2! complete days to discover this. It would be extremely great to have some kind of warning like 'running out of tx buffers' or so. Because from anything in the source I was not able to tell what the problem was.
And what does 5 mean? 5 frames? 5 bytes?
I am a bit puzzled …
Reply to this email directly or view it on GitHub: https://github.com/xcore/sc_ethernet/issues/23
This is the number of TX/RX packets buffered in the MAC. It's possible that TX packets were being dropped because the size was only 2. There are dropped packet counters that you can enable to detect this but they aren't printed by default because they would reduce performance.
I have solved the mysteries of my issue #20:
I had to set
define NUM_MII_RX_BUF 5
define NUM_MII_TX_BUF 5
but I had set it to
define NUM_MII_RX_BUF 20
define NUM_MII_TX_BUF 2
(which I copied from some other ethernet_conf.h)
It took me 2! complete days to discover this. It would be extremely great to have some kind of warning like 'running out of tx buffers' or so. Because from anything in the source I was not able to tell what the problem was.
And what does 5 mean? 5 frames? 5 bytes?
I am a bit puzzled …