Subject:
|
LNP congestion avoidance improved
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Mon, 13 Dec 1999 01:38:45 GMT
|
Viewed:
|
914 times
|
| |
|
|
Hi there,
on my way to a reliable LNP layer (and gdb, hopefully), i did some tests
about how well LNP congestion avoidance works:
I compiled 2 functionally identical programs, one on my linux-box, one
on my RCX.
Both of them setup an adressing handler for packets from the other side
and then go into an endless loop. Inside the loop, they just send
addressing layer packets to the other side again and again by calling
lnp_addressing_write()
My expectation after studying the LNP code was, that both senders would
be able to sucessfully deliver packets, approximately at the same rate.
Astonishingly, there was not even 1 packet delivered due to collisions
or frame errors, total congestion seemed to happen. After some
investigation i think i found the problem, it´s in lnp_logical.c:
lnp_logical_write() sets allow_tx to a point somewhat far in the future,
once a collision is detected. However, if any byte (or a frame error) is
seen afterwards, allow_tx is set to sys_time+LNP_BYTE_SAFE, which may be
smaller than the value already set. The next send-job already waiting
will be started too early, and that´s it...
If only two entities are involved in the communication, you might argue
this will never happen, because both of them will see the collision and
immediately stop transmission. However, at least with linux it´s
obviously not easy to disable the transmitter immediately. Furthermore,
depending on the value of the bytes sent, one of the entities could see
it´s byte correctly come back (and continue transmission), the other
not. If there were more than two senders on the scene, imho this
argument wouldn´t apply anyways.
My fix: if rx_handler() detects a collision or rx_error() is invoked,
do:
new_tx = sys_time+LNP_BYTE_SAFE;
if (new_tx > allow_tx) allow_tx = new_tx;
naturally spoken: never decrease allow_tx !
This fixes the problem for me, both PC and RCX now deliver most of there
packets successfully. ( I´m still wondering why the PC wins the race a
little bit more often than the RCX, approximate packet delivering ratio
is 5:4 ).
BTW, to make this work at all i had to do another fix to my linux LNP
implementation: during initialisation, set the uart type to 16450, this
means, disable the hardware FIFO of the uart. ( Ben Laurie suggested
this, thanks again, Ben !). Of course, this will not work for other
uarts, and is not portable 8-(
cheeers, Martin
|
|
Message has 1 Reply:
 | | Re: LNP congestion avoidance improved
|
| Great! While it is too late for the class I'm helping out with, and it currently looks like it won't be offered again, I'm still looking forward to playing with this in the spring. Thanks so much for the time invested, Martin- Luis (...) ###...### (...) (25 years ago, 13-Dec-99, to lugnet.robotics.rcx.legos)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
