Subject:
|
Re: LNP congestion avoidance improved
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Mon, 13 Dec 1999 00:57:18 GMT
|
Viewed:
|
1141 times
|
| |
|
|
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
On Mon, 13 Dec 1999, Martin Cornelius wrote:
>
> 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
>
>
#######################################################################
Profanity is the one language that all programmers understand.
-Anonymous
#######################################################################
|
|
Message is in Reply To:
 | | LNP congestion avoidance improved
|
| 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 (...) (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
|
|
|
|
