Subject:
|
Re: NQC vs Spirit communication speed
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Fri, 11 May 2001 18:43:24 GMT
|
Viewed:
|
2048 times
|
| |
|
|
In lugnet.robotics.rcx.nqc, Dave Baum writes:
> I'm not sure of the details of your port, so here are some general
> things to look out for:
>
> * Opening/Closing the link frequently will hurt performance because
> you're not giving the link a chance to learn the right timeout. There's
> also extra overhead since it tries to "sync" up on the first packet of a
> freshly opened link. Best strategy is to open once and leave open
> forever. I'm not sure how you'd integrate this into NQC, though.
I'm using AutoLink.Send for most things. Initially I was always closing the
link at the end of each method (which mostly map to the Spirit OCX API).
I've made that configurable and at present I'm running with it set to leave
the link open. When I wish to download a program via NQC I explicitly close
the link prior to executing NQC. Then the next command sent via my class
will reopen the link in AutoLink.Send.
> * If you don't want dynamic timing, override by setting an explicit
> timeout. (clear the fDynamicTimeout field in the class)
Dynamic timing doesn't function if predictive replies are enabled:
bool dynamic = (timeout==0) && fDynamicTimeout && !fPredictive;
In the SetTarget method you set both of them to true. So unless I'm missing
something (a definite possibility) your code never does dynamic timeouts -
except when downloading the firmware when it explicitly turns off predictive
replies temporarily. Couldn't you still dynamically adjust the timeout when
predictive replies are enabled?
> * Enabling predictive replies (set fPredictive field true) can help a
> lot since in many cases the link is able to tell when a complete reply
> is received without waiting for the full timeout.
I'll try putting in values for all the Opcodes I'm using and see if it helps
at all.
> What sort of delays are you seeing? 10 ms, 100 ms, 1 second? If I can
> replicate the same sort of delays using the original NQC source, then
> I'll try to improve things.
I haven't done a good job of precisely measuring delays. I'd estimate
almost a half-second delay in many instances. That may correlate to the 400
millisecond timeout that I've noticed when I stepped through the code.
|
|
Message has 1 Reply:
 | | Re: NQC vs Spirit communication speed
|
| (...) Correct - dynamic timing is turned off when predictive is being used (which is the default). Predictive is relatively new, and I wasn't sure which code you started with (or how you ported/used it), so that's why I explained the dynamic timing. (...) (23 years ago, 11-May-01, to lugnet.robotics.rcx.nqc)
|
Message is in Reply To:
| | Re: NQC vs Spirit communication speed
|
| The retry timing for RCX_Link uses a dynamic backoff, which is a good general purpose solution if you're going to be sending lots of packets (like a typical NQC download) and the latency through the serial driver is unknown and/or unpredictable (...) (23 years ago, 11-May-01, to lugnet.robotics.rcx.nqc)
|
8 Messages in This Thread:
   
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
