GetQueue Anomaly

[pdubinsky]

I've been testing the following code to see if I can move data between queues quickly. With the following code, if I try to move date from InQueue to TestQueue using GetQueue(InQueue, TestQueue, 100, 1.0, timeOut) it appears that only 67 bytes arrive in TestQueue. However, if I move the data a byte at a time using:

call GetQueue(InQueue, k, SizeOf(k), 1.0, timeOut)
call PutQueue(TestQueue, k, SizeOf(k))

all 100 bytes arrive.

I thought at first that there might be a speed advantage to moving 100 bytes as a block but now I don't know.

Any ideas?

Thx,
Paul

[dkinzer]

[dkinzer]

If you want to experiment with this concept, here is some test code that relies on internal implementation details:

[pdubinsky]

This is an interesting idea because the point of this was to speed up
moving the data out of a receive queue that was receiving data from a
source that the program could not control - in this case a GPS
receiver. The GPS rcvr sends 2 NMEA sentences every second which at
4800 baud doesn't take very long but processing the first sentence
causes problems receiving the second sentence. The idea is to receive
both sentences into a large receive queue (aprrox 120 bytes), move
that data to a processing queue and continue receiving data into the
now empty receive queue while the data in the process queue is "processed


The standard approach would eat up a lot of time spinning in the
GetQueue loop and not help much. I tried BlockMove which seemed to
work. But if it did actually work without clobbering the system, it
didn't empty the receive queue which would still have to be emptied in a loop.


I'll try this. and see how it works.


Thx,
Paul

[dkinzer]

The other approach that may yield the performance you're seeking is to do a GetQueue() to an ordinary byte array and process the data from there.

[spamiam]

[pdubinsky]

Tony,

The real problems started when I started converting from knots to mph and meters to feet. The increased speed of the ZX-24 and its additional ram made a big difference. But I was still spending a lot of time tossing out NMEA sentences that I didn't want. Occasionally, I'd just toss the whole queue out to catch up.

That all changed with a little research. Now I send the GPS a series of msgs that stop the GPS from automatically sending the default NMEA sentences. That gets the GPS to stop sending anything though it's awaiting instructions. Then I poll for the sentences that I want when I want.

I'm interested in the GGA sentence and the RMC sentence. When I poll for the GGA sentence, the GPS responds with the same data that it was originally spewing but now it only sends it once. I parse the sentence, do my conversions and display the data. Then I get the other sentence and do the same. Loop continuously. Even the BX-24 could keep up this way since the conversion time overhead doesn't matter.

Paul

[spamiam]

[pdubinsky]

I do the same but I have two complicating factors.

1. The rcvr I'm using defaults to sending 6 different sentences per second and just dumping the excess is time consuming and

2. I have to send about 70 serial bytes to a display at 19200. Not a lot of data but slow and ...

By changing the parameters of the rcvr to just 2 sentences, polling them and changing the rcvr xmit baudrate to 38400, things have changed remarkably. At least the data stream is under my program's control - not the rcvr's control.