Subject:
|
Re: NQC vs Spirit communication speed
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Fri, 11 May 2001 16:41:26 GMT
|
Viewed:
|
2175 times
|
| |
|
|
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 (again, typical for NQC since its ported
to a variety of OSes).
There are a few ways this can be tripped up...
1) If the initial timeout is too short, then the first packet will
always fail...in fact if it is "just wrong", then the second retry
obliterates the reply from the first packet (IR is a shared medium).
2) A long retry time can really slow things down since it will wait at
least that long under certain circumstances (even if a valid reply was
received earlier).
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.
* If you don't want dynamic timing, override by setting an explicit
timeout. (clear the fDynamicTimeout field in the class)
* 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. Actually, one of my
gripes with the RCX packet format is that you can't always tell the
length of a packet without also interpreting the contents of the packet.
This makes it difficult to partition the delivery of packets from the
use of packets. So not all of the packet times will take advantage of
predictive replies. I think I included data for the ones NQC commonly
uses, but probably not for the stuff you are doing. Look at the
PredictReplyLength() method - it needs to return the expected number of
bytes for a given bytecode. The default is 1000, which really just
means keep reading until the timeout.
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.
Dave Baum
In article <GD6Io5.4Hu@lugnet.com>, "John Hansen" <JohnBinder@aol.com>
wrote:
> This is more a general RCX communication question, actually. As I
> mentioned
> here previously, I've ported the NQC communication code to Delphi for the
> purposes of modifying RcxCC to not use the Spirit OCX.
>
> At present I have a version of RcxCC that does everything the original
> version does without ever using Spirit. It uses my "FakeSpirit" class
> that
> uses my port of the NQC RCX_Link, RCX_Cmd, and Serial code. I'm
> relatively
> satisfied with the results. But there is a slight problem.
>
> The original RcxCC (which uses Spirit) appears to communicate with the
> brick
> much faster than my modified RcxCC does. Polling for information using
> my
> Spirit replacement is much slower than doing so via Spirit. I've
> profiled
> the application and the vast majority of the time is spent in the serial
> class' read method. It appears to retry a lot - almost always (if not
> always) failing on the first send. But Spirit somehow seems to do the
> exact
> same operations in virtually no time at all.
>
> Can anyone shed some light on this matter?
>
> Thanks in advance for your help,
>
> John Hansen
--
reply to: dbaum at enteract dot com
|
|
Message has 2 Replies:
 | | Re: NQC vs Spirit communication speed
|
| (...) I looked into this a bit more and the poll bytecode (0x12) didn't have a case in the PredictReplyLength() switch. If you add... case 0x12: // poll return 2; then poll will be a lot faster. If you run into other bytecodes that you use a lot, (...) (23 years ago, 11-May-01, to lugnet.robotics.rcx.nqc)
| | | Re: NQC vs Spirit communication speed
|
| (...) 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. (...) (23 years ago, 11-May-01, to lugnet.robotics.rcx.nqc)
|
Message is in Reply To:
| | NQC vs Spirit communication speed
|
| This is more a general RCX communication question, actually. As I mentioned here previously, I've ported the NQC communication code to Delphi for the purposes of modifying RcxCC to not use the Spirit OCX. At present I have a version of RcxCC that (...) (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
|
|
|
|
