Subject:
|
USB vs Serial Tower Response Time
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Thu, 21 Aug 2003 03:47:24 GMT
|
Reply-To:
|
Dick Swan <dickswa@sbcglobal(NoMoreSpam).net>
|
Viewed:
|
3629 times
|
| |
|
|
Several recent posts have mentioned significantly slower performance
of the USB Tower when compared to the serial Tower. After several
measurements, I've concluded that the USB Tower is "natively" only
slightly slower (~20 milliseconds per message) than the Serial Tower.
However, many PC applications appear to add significant extra delay
(~200 msec) for the USB tower.
A summary of my observations and conclusions:
[1] RCX typically introduces a processing delay of about 0.5
milliseconds (msec) between when it receives the last byte of a
message and before it starts transmission of first character of reply.
[2] For some unknown reason it takes twice as long for first byte of a
reply message to be received as for other reply byte. I speculate
software errors in RCX ROM firmware which "messes up" or drops the
first transmit ready interrupt. [RCX transmission is an interrupt
driven state machine].
[3] I suspect cause of extra USB Tower delay is likely in the USB bus
handling. Typically USB tower is 15-25 msec slower for a short
message. I speculate that USB bus may be polled on a 10 msec interval
and this delay is about the extra delay for the two or three partial
polling intervals in a xmit/reply message pair.
[4] For long messages, the extra delay is insignificant. Download of a
firmware load to RCX via USB took 72 seconds with USB tower and 69
seconds with serial tower. Naturally, a quad speed fast downloader was
used. Use of fast downloader and optimization of the waits in the
downloader are far more important than difference between USB and
serial tower.
[5] PC software can add significantly more delay than above. I traced
messaging on one popular program and it added a 250 msec wait between
USB messages. I tried to improve by changing the settings described in
[7] below but then if failed for long messages (like retrieve datalog
or memory map).
[6] Significant improvement is possible by tweaking the message
parameters (4800 vs. 2400 baud, number of preamble bytes, whether
"complement" bytes are sent). I wrote a ping program that managed 18.1
pings per second using Lego's "parameters" on the serial tower and
12.6 on the USB tower. After optimizing the messaging parameters, I
achieved sustained rates of 74.9 pings/second on Serial Tower and 31.2
on the USB tower.
[7] Lego provides a USB Tower control panel driver that allows
specification of three timeouts (write, first received character and
inter-character reception). I believe these add significantly to the
slow performance of the USB Tower. In my software, I set all three
timers to zero and do my own interval timing dynamically based on the
length of the message and its reply. I suspect the problem with the
Lego timers is that they have to be long enough to accommodate the
largest size message and largest size response which adds unnecessary
delay to short messages??
[8] Receiving preamble bytes (55 FF 00) during message reception
should be optional. When looking for a message, the RCX ROM firmware
ignores all characters until it receives a non-preamble/non-header
byte. It then treats this as the message opcode. I found some PC
programs always expect the preamble bytes and fail the message
reception if they are not received.
My test environment uses "home grown" PC software on a Pentium 4 1.7
GHz system and not the Lego supplied higher level drivers.
The following snippet is an I/O trace from an "alive" (or "ping")
opcode (0x10) from the serial tower.
The left column of numbers is relative time in seconds of the various
"events". The first group of received characters is the "echo"
received from the serial tower for the characters being written. This
is followed by the message reply.
121.552 Send Message **<Alive>** 1 bytes, Complement ON 2400. 10
121.552 Write 7 bytes: 55 FF 00 10 EF 10 EF
121.558 Buffer add: inter-time 5.27; added 55
121.562 Buffer add: inter-time 4.56; added FF
121.567 Buffer add: inter-time 4.53; added 00
121.571 Buffer add: inter-time 4.76; added 10
121.576 Buffer add: inter-time 4.39; added EF
121.581 Buffer add: inter-time 4.66; added 10
121.585 Buffer add: inter-time 4.52; added EF
121.595 Buffer add: inter-time 9.68; added 55
121.595 First reply char received at 121.595. Response 9.68 msec
121.599 Buffer add: inter-time 4.51; added FF
121.604 Buffer add: inter-time 4.58; added 00
121.608 Buffer add: inter-time 4.56; added EF
121.608 Discarded 3 char preamble -- Standard '55 FF 00'
121.613 Buffer add: inter-time 4.54; added 10
121.617 Buffer add: inter-time 4.56; added EF
121.622 Buffer add: inter-time 4.59; added 10
121.622 Reply message **<Reply to <Alive>>** bytes EF
Notice that the inter-character arrival time ("inter-time" in the
trace) is pretty consistent at about 4.5 msec which is the time it
takes to transmit a single character at 2400 baud. The first reply
character (0x55 at time 121.595) has a longer inter-time of 9.68; the
extra interval is delay introduced by the RCX. I've deduced that there
are two components of the RCX messaging delay: [1] is
processing/queueing delay in the RCX for message processing (about 0.4
msec) and [2] the RCX appears to always inserts a delay of about one
character before transmission. When I changed the transmission rate to
4800 baud, the RCX delay shrunk by about 2.3 msec which is the savings
of transmitting one character at the faster rate.
A similar trace for the USB Tower is below. In this case, there are no
"echo-ed" characters because they absorbed within the USB tower and
not reported to the PC. I calculate the reply message response time as
the difference between start of Tower transmission and reception of
first reply character less the time it takes to transmit message of
the specified size.
135.669 Send Message **<Alive>** 1 bytes, Complement ON 2400. 10
135.669 Write 7 bytes: 55 FF 00 10 EF 10 EF
135.669 Starting timer for 'Wait for transmit to finish' of '32' msec
135.727 *Read* 1 chars (0 existing, 7 more expected). 55
135.727 First reply char received at 135.727. Response 26.19msec
135.735 *Read* 1 chars (1 existing, 6 more expected). FF
135.743 *Read* 2 chars (2 existing, 5 more expected). 00 EF
135.743 Discarded 3 char preamble -- Standard '55 FF 00'
135.751 *Read* 2 chars (1 existing, 3 more expected). 10 EF
135.759 *Read* 1 chars (3 existing, 1 more expected). 10
135.759 Reply message **<Reply to <Alive>>** bytes EF
Summarizing the results from the above two traces.
Serial USB
33 32 Time to transmit message from PC
9.68 26.19 Delay between end of xmit and rcv first reply byte
27 32 Time to receive remaining reply byte
======= =====
70 90 msec
The following are two traces for speed optimized messaging for both
the Serial and USB Towers. Transmission speed has been set to 4800
baud, preamble bytes (55, FF, 00) have been disabled and so has the
"complement" bytes. Serial tower took 13 msec for send/reply sequence
and USB tower took 27 msec.
115.847 Send Message **<Alive>** 1 bytes, Complement OFF 4800. 18(10)
115.848 Write 2 bytes: 18 18
115.850 Buffer add: inter-time 2.70; added 18
115.853 Buffer add: inter-time 2.27; added 18
115.858 Buffer add: inter-time 5.16; added E7
115.858 First reply char received at 115.858. Response 5.16 msec
115.858 Discarded 0 char preamble -- ***Ignored short preamble
sequence***
115.860 Buffer add: inter-time 2.31; added E7
115.860 Reply message **<Reply to <Alive>>** bytes E7
105.033 Send Message **<Alive>** 1 bytes, Complement OFF 4800. 18(10)
105.033 Write 2 bytes: 18 18
105.052 *Read* 1 chars (0 existing, 2 more expected). E7
105.052 First rreply char received at 105.052. Response 14.37 msec
105.052 Discarded 0 char preamble -- ***Ignored short preamble
sequence***
105.060 *Read* 1 chars (1 existing, 1 more expected). E7
105.060 Reply message **<Reply to <Alive>>** bytes E7
|
|
Message has 4 Replies:
 | | RE: USB vs Serial Tower Response Time
|
| (...) <snipped long post> Dick, This is a remarkably detailed analysis of the difference between the USB and serial towers. It also contains many useful hints about the preamble bytes and other esoteric things about the LEGO protocol. I have an dea (...) (21 years ago, 21-Aug-03, to lugnet.robotics.rcx)
| | | Re: USB vs Serial Tower Response Time
|
| Wow, that answers a lot of questions, all but one: why is the USB's 'long range' shorter than the Serial's distance? Was my speculation of the available power true? (500mA vs 9v ... not sure if these two measurements can be compared) (...) <snipped> (...) (21 years ago, 21-Aug-03, to lugnet.robotics.rcx)
| | | Re: USB vs Serial Tower Response Time
|
| (...) Dick If, by chance, BricxCC (or NQC) happened to be the popular program to which you refer I'd love to hear more details about your software tests and the code you use for communicating with the RCX via the USB tower. I'm not particularly (...) (21 years ago, 22-Aug-03, to lugnet.robotics.rcx)
|
5 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
